Re: autoconf 2.61 incompatibility?

> So you're building from a "dist" tarball, and not a cvs/git/svn > checkout? If that's the case then the version of autotools that you > have installed (as well as any version requirements of the package) > should not matter at all, as nothing should need to be regenerated. The > dist tarball i

autoconf 2.61 incompatibility?

I'm trying to build a software package that requires AUTOMAKE_OPTIONS = foreign 1.7 and AC_PREREQ(2.54) on a machine that has automake-1.10 and autoconf-2.60 installed. configure finishes successfully, but make fails: $ make cd . && /bin/sh /tmp/pkg-x.y.z/config/missing --run autoheader

Re: Error with Makefile

sam wun writes: > Hi, > > I don't know how to build a proper Makefile for a C++ project. > Here is the Makefile I m currently use: [...] Wrong mailing list, buddy. > : undefined reference to `pcre_compile' You forgot to link against libpcre. ___ A

Re: coreutils-5.1.3 released: bug-fix-only, candidate for stable 5.2.0

> Does any Tru64 expert know whether this bug has been fixed in later > versions, (e.g., Tru64 5.1A) and/or whether it was present in earlier > versions (e.g., Tru64 5.0A or 4.0G)? Is a patch available for Tru64 > 5.1? On Tru64 4.0F (OSF1 V4.0 1229 alpha), I get two slashes. The machine has o

autocsan failure

Trying to auto* a project. $ autoscan --version autoscan (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FI

Re: solaris and -lintl problems

> I think you're getting the wrong libintl. Those look like the library > interface to GNU libintl that gets set up in its header files. I've > encountered exactly those error messages before on Tru64 when the system > libintl was built dynamically and the GNU libintl was built statically and >

Re: -lsocket -lsnl on solaris 9

> > Have you checked config.log? Maybe the order of the checks is important. > > I've been using the following for ages, and it continues to work on > > Solaris 9: > > > > AC_CHECK_FUNCS(gethostbyname,,[AC_CHECK_LIB(nsl,gethostbyname,,[AC_CHECK_LIB(socket,gethostbyname)])]) > > AC_CHECK_FUNCS(

Re: -lsocket -lsnl on solaris 9

Jeff Fulmer writes: > Hello, > > I'm at wit's end here. I used to be able to link to the socket libs on > Solaris using the following directives in configure.in > > AC_CHECK_FUNCS(socket, , AC_CHECK_LIB(socket, socket)) > AC_CHECK_FUNCS(gethostbyname, , AC_CHECK_LIB(nsl, gethostbyname)) > > AC_

[META] List owner?

Does anyone here know the person behind autoconf-owner? I have sent email to autoconf-owner (and probably automake-owner, too) a number of times and never received a reply. The amount of spam coming from these two lists is appalling, and in fact accounted for more than 50% of all spam that m

Re: creating and using separate src and obj trees

> I have a source tree which is built using automake[1]. The application is > large > and being written in C++ and when built the tree ocupies over 1GB. I > therefore > want to separate the source tree from the build tree in a similar way that > FreeBSD uses /usr/src and /usr/obj when building the

Re: Library path with AC_CHECK_LIB

[EMAIL PROTECTED] writes: > Hi, I'd like to ask about this again, as I'm waiting to release on this > problem. > > The problem is that configure[1] is finding[2] libz and adding it to my > link line[3] but when linking libz is not found. > > libz is in /usr/local/lib, but that is not a compiled

Re: library version

Bob Lockie writes: > Is there a way to check for a specific library version rather than a > function in that library? I'm afraid not - there is no standard method for it. What kind of version info are you looking for? Some libraries have version info in the corresponding header files, e.g. fo

Re: Bug report

Chris Schuit @ Euronet writes: > configure: WARNING: net/if.h: present but cannot be compiled > configure: WARNING: net/if.h: check for missing prerequisite headers? > configure: WARNING: net/if.h: proceeding with the preprocessor's result > configure: WARNING: ## --

Re: autoconf on Solaris 8

ti chi writes: > > nm libsresolv.so | grep hstrerror reveals Note: libresolv. > [1622]| 155404| 92|FUNC |GLOB |0|9 |hstrerror > > - Ti > ti chi <[EMAIL PROTECTED]> wrote: > I ran autoconf on Solaris 8 with the AC_CHECK_FUNCS(... hstrerror ...) and it says >that hstrerror is not su

Re: trouble with a check for funktion in library ...

Lars Segerlund writes: > > Hi, > > The following is part of a configure.in file I'm trying to write, > however the AC_CHECK_LIB always fails, what are the requirements for it > to run ? > > I've been at this for a week or two now, and I just don't get it, even > if I have been rtfm'ing ..

Re: AC_CHECK_FUNCS difference between 2.54 and 2.56

Albert Chin writes: > There seem to be problems with AC_CHECK_FUNCS on AIX with the IBM C > compiler (5.0.2.6). With autoconf 2.54, AC_CHECK_FUNCS(chflags) > outputs (b.c): [...] > The problem is that chflags doesn't exist on AIX yet the test passes > because the IBM linker seems to optimize the ca

Re: Checking for function s in libs.

Lars Segerlund writes: > > Hi, > > I am packaging an old program with autoconf/make and I have a check > that fails without any explanation I can think of. > > AC_CHECK_LIB(X11,XOpenDisplay) > > fails, however the program uses X11 and I just don't understand whats > going on ? > > also I

Re: Setting deafult value

Yannick writes: > Hi, > > Is there a way to set the default value for an "--enable-X" argument? > > I am using the acinclude.m4 template from kdevelop and I want to > check for QT multithreaded. I added KDE_USE_QT to autodetect qt > but I also want to add the multi-threaded support. This opti

Abusing libtool for library checks?

Similar questions may have been asked before, but not always with a satisfatory answer IMHO. I want to check for a certain library. E.g. I would use something like AC_ARC_WITH(foo, [ --with-foo[=PREFIX] ] ...) where PREFIX is used to search for libfoo in PREFIX/lib, and related hea

Re: Libtool 1.4.3

Bob Friesenhahn writes: > On 8 Oct 2002, Akim Demaille wrote: > > > > There is one big question which must be answered first: will it have > > to be Autoconf 2.13 compatible? > > > > I *strongly* suggest that it must not. It should AC_PREREQ 2.54 > > immediately. Then, I'm fine with checking the

Re: checking for C compiler default output...

vincent blondel writes: > Hi all, > > I am trying to compile all packages for a Linux from Scratch installation > but I encounter problem with the compilation. > I am using Mandrake 8.2 on a AMD Athlon Xp1600+ and I got following > messages. > > checking build system type... i686-pc-linux-gnu >

Re: Autoconf, config.in and configure in fileutils 4.1

[...] > I don't know why autoconf put this line in my configure script. > > Anyone can help me ? Post relevant information. You didn't say which files you modified, and how you modified them. This looks like a coding error on your part, and you might save us some time by finding it yourself.

Re: Threading support

John Poltorak writes: > > Does autoconf check for threading support, and if so how does it do it? > > On OS/2 support for threading is native and built into the operating > system. How would autoconf handle such a situation? Would I need to > install the pthreads library? I use ACX_PTHREAD f

Re: daemon pid file location

Ionutz Borcoman writes: > Hi, > > For a daemon, how do I code the location of the pidfile ? Normaly it in > /var/run, but some systems, like our old SCO, don't have this directory. > So where should I put this pidfile, by default ? The arguably easiest way is to create /var/run where it doesn

Backwards compatibility: time_t test

With the impending release of autoconf 2.54, I am now very close to a configure.in that works with both 2.13 and 2.5x. However, one problem remains, and it is quite similar to the one reported by Andreas Bauer a few days ago (Subject: Different versions of autoconf cause problems here...)

Why 2.53 is broken (Re: making a 2.52 macro backward compatible)

Akim Demaille writes: > Seriously, I don't want to start useless long threads about this > issue, but it is really an error to stick to 2.13. It is dead and > will no longer be maintained. What a pity. As long as autoconf 2.5x remains as broken as it is now, I will certainly stick with 2.13.

Re: AC_CHECK_HEADERS long list error

Lars Hecking writes: > > > AC_CHECK_HEADERS( file.h file1.h ... file6.h \ > > file7.h file8.h ... file12.h \ > > file13.h) > > > > However, the code produced by the macro doesn't copy the '\' so it > > sees the newline and obviously breaks

Re: AC_CHECK_HEADERS long list error

> AC_CHECK_HEADERS( file.h file1.h ... file6.h \ > file7.h file8.h ... file12.h \ > file13.h) > > However, the code produced by the macro doesn't copy the '\' so it > sees the newline and obviously breaks. Is there anyway around this > other than to write a bunch of AC_CHECK_HEADERS (thus exp

How to debug configure scripts with 2.53?

I have a configure(.in) that breaks all over the place with autoconf 2.53. How can I debug this? I used to just $ sh -x ./configure >log 2>&1 and then take a look at log, but this doesn't work anymore. config.log is no help either. One thing I'm trying to find out is why the PATH arg is i

Re: Code obfuscation

John Poltorak writes: > > Can anyone explain what this code in autoupdate does? :- > > > my $macros = new Autom4te::XFile ("$autoconf" >. " --trace AU_DEFUN:'AU:\$f:\$1'" >. " --trace define:'AC:\$f:\$1'" >. " --melt /dev/null |"); This is just

Re: How to use cache variables

John D. Burger writes: > I have what I think is a style question: > > If I want to do something with the results of autoconf tests in my > configure script, what's the best way to check these results? For > instance, say I'd like to do this: > > AC_CHECK_LIB(norman, snStackPush) > AC_CHECK_

Re: Auto update of config.[guess|sub]

> Yes, I know where they are, what I was getting at was whether there was > some way of being able to automatically replace old ones included in an > archive... Well, cron and wget are your friends :) > Can autoconf check a specific location for these files and use the newer > version, by

Re: Auto update of config.[guess|sub]

John Poltorak writes: > Is there any way of automatically refreshing config.[guess|sub] if the > ones supplied in an archive are out of date? Get them from ftp://ftp.gnu.org/gnu/config/ or GNU mirrors.

Re: FHS

Richard B. Kreckel writes: > On Sat, 5 Jan 2002, Peter Eisentraut wrote: > > > When upgrading some packages to AutoConf-2.52 I noticed that given > > > --prefix=/usr, manpages go straight into /usr/man/. Hmm, but we got a > > > filesystem hierarchy standard ! > > >

Re: Checking `gpp' as executable for C++ compiler in 2.52

Tim Van Holder writes: > > Why was `gpp' chosen as a possible executable name for a C++ compiler > > in AC_PROG_CXX (Autoconf 2.52)? This clashes with: > > http://www.math.polytechnique.fr/cmat/auroux/prog/gpp.html > > Because gpp is the name for g++ on DOS (where '+' is illegal in filenames).

Re: Autoconf 2.52 is released

> Could you please be more specific here? Perhaps we can suggest ways > for you to make the changes so that they'll work with both 2.13 and 2.52. Some hints on how to have configure.in compatible with both versions would be more than welcome. One problem now is that 2.5x creates configure

Re: Config.status on OS X

[Please take me out of the loop on replies. I'm reading both lists :)] Werner Koch writes: > || On Tue, 19 Jun 2001 19:52:06 +0200 > || Sebastian Hagedorn <[EMAIL PROTECTED]> wrote: > > sh> takes minutes between tests), but it is successful. Then, when I try > sh> to run autoconf 2.50 wit

MacOS X and zsh

This came up on the gnupg-user mailing list. While it is not per se an autoconf problem, I should think that autoconf must provide some workarounds to work under MacOS X. Or is it a matter of configuring zsh differently? The failing line of code quote below is quite common. > >>The line > >>

Re: how to force options be default to "no"?

Masao Uebayashi writes: > Hello, > > Whether a option found by "configure"'s test is used (enabled) by > default is decided by the auther of the "configure" script, but I want > to override it as "no", that is, I want to use options which I > explicitly specify by "--enable-*". grep the autocon

Re: AmigaOS fork()

Rüdiger Kuhlmann writes: > [Rüdiger Kuhlmann, please stop mangling the Subject: line. This is highly annoying.]

Re: autoconf-2.50 docs: Common Behavior/Default Includes

Thanks Paul and Russ! > C99 stdint.h exists only for freestanding environments -- > i.e. environments without a C library, where the only available > headers are float.h, iso646.h, limits.h, stdarg.h, stdbool.h, > stddef.h, and stdint.h. In effect, stdint.h is the freestanding part > of intty

autoconf-2.50 docs: Common Behavior/Default Includes

The docs read: ... Most generic macros provide the following default set of includes: ... and the list includes inttypes.h. What's the rationale behind using inttypes.h, and not stdint.h?

Re: how to use libraries in /usr/local

> > See my followup message. That doesn't take care of shared libraries > > across multiple platforms, for one. (That's the really major thing that > > it doesn't take care of, but there are others.) > > I would argue that if a shared library has been properly installed, the > runtime linker

Re: AmigaOS fork()

> vfork() is normally a very different function than fork(), with > significantly different and much more dangerous behavior if it is not > immediately followed by an exec(). Is that the case on Amiga, or is it > just a misnamed fork()? AmigaOS cannot have fork() due to lack of virtual memory

Re: Problems during make (v2.13)

> I have installed the following packages prior to autoconf: > make-3.79.1 > flex-2.5.4 > bison-1.28 > m4-1.4 GNU m4, ... [...] > flemming# ./configure > creating cache ./config.cache > checking for gm4... no > checking for gnum4... no > checking for m4... /usr/ccs/bin/m4 ... but it's not pi

Re: How to omit files from AC_OUTPUT?

> In autoconf 2.13, you might get away with: > > if test x$ac_cv_prog_BISON = xbison; then > extra_makefiles="test-bison1/Makefile test-bison2/Makefile" > fi > AC_OUTPUT(Makefile test-1/Makefile test-2/Makefile $extra_makefiles) IIRC one cannot use variables in AC_OUTPUT. You could do some

Re: tabs in configure.in?

> Err, maybe I was not answering on the spaces you were referring to. > > If you refer to the spaces in the case argument and in the patterns, > it's nothing but protection against collisions such as > topo/Makefile.in. So they want spaces in the patterns, as a > separator, but then they need

Re: tabs in configure.in?

> M4 is insensitive to it, and autoconf.sh does not try to smash them. > Nonetheless, trailing spaces are smashed. > > What problem do you face? The current version of GNU gettext's m4/gettext.4 contains the following | [case " "$CONFIG_FILES" " in *" po/Makefile.in "* | *" po/Makefile.in:"*

tabs in configure.in?

I couldn't find this in the manual, or with a quick glance through my list archive: are there any rules about the usage of tabs in configure.in? I just came across some configure.in code that fails if used with tabs. Personally, I'd consider it best practice to avoid tabs, but are there any

Testing autoconf-cvs

I finally got around to do some testing with real-world software. So far, I haven't seen any major problems, but there are a few little things I'd like to have explained, as I didn't follow the discussions here too closely. Consider the following configure.in fragment. It checks whether the

Re: Release next week?

> Well, just in a quick check of some of the stuff that I've compiled > recently and just judging by whether or not there are Makefile.am files > (so I could miss some automake projects that don't distribute those files > or call them something different), grace, xlispstat, gnuplot, vim, and > xe

Re: gcc -nologo?

specific? > > Might be. I can't find any occurrences of -nologo in the CVS > autoconf. Hmm... But, indeed, it's there in autoconf 2.13. Oops :-) Check out the ChangeLog: 2000-09-14 Pavel Roskin <[EMAIL PROTECTED]> * acgeneral.m4 (_AC_TRY_CPP): Don't filter out conftest.$ac_ext

Re: Status of 2.50

Lars J. Aas writes: > On Mon, Mar 19, 2001 at 07:36:11PM +0100, Akim Demaille wrote: > : There is something which is extremely important, and I think Lars can > : help us on this issue: compatibility with Libtool. > > Lars Hecking, I presume? I don't think so ;-)

Re: installation instructions on OpenBSD and FreeBSD

Bruno Haible writes: > Marc Espie writes: > > > which would tend to indicate to me that even knowledgeable people don't > > find this obvious... > > Yup. Also, on HP-UX my first attempt was "cc", my second was "cc -Aa", > my third was "cc -Aa -D_HPUX_SOURCE", and only with some help by Jim > or

Re: Checking libraries in multiple places -- frusturated by the cache

and silent versions of the resp. autoconf macros. See attached. I think I wrote this stuff before AC_SEARCH_LIBS became part of autoconf. ## ----- ## ## Search several directories for header file. ## ## Built around a non-caching and silent version ## ##

[OT] waitpid()

Sorry for this OTish post, but I figured the list has excellent expertise in this area ... I need to implement a configure check for waitpid(). While this by itself is trivial, are there any known abnormalities/non-POSIXisms I need to consider? Also, are there any concrete examples of opera

Re: Moving to Automake 1.4a

> I think it is important that automake-using distributions use an > actual release and not the cvs automake. I think that some of the free Unix/Linux distros use their own patched version of automake which in turn is based on cvs automake at some more or less random point in time. For my ow

autoconf, sendmail, and pthreads

Hi all, Before I start hacking, has anyone written a set of autoconf tests, or possibly a macro, to find all files required for sendmail filters that use libmilter? This stuff requires threading libraries (pthreads - POSIX?), so there may be some hidden nastiness wrt different implementatio

Re: AC_OBJEXT revisited

> How portable is `ls -U conftest.exe conftest'? $ /bin/ls -U /bin/ls: illegal option -- U $ This covers Solaris, DU 4.0, IRIX 6.3, HP-UX 10.20. Want more?

Re: OpenBSD 2.7

Argh! Please stop CC'ing me in this thread! I am subscribed to this list!! Pavel Roskin writes: > Hello, Akim! > > > Pavel> So let's remove the explicit rule. It's only helpful to > > Pavel> maintainers, but they are supposed to clean up the working > > Pavel> directory from time to time

Re: Call for testing CVS Autoconf

> > Pavel> AC_FUNC_MKTIME > > > > Lars, could you > > > > cd ~tests > > ./testsuite -v 80 >debug.log 2>&1 > > Here's the result: Sorry for sending another follow-up ... 0. SunOS localhost 4.1.4 2 sun4c unknown 1. there is no man page for mktime() 2. there is no prototy

Re: Call for testing CVS Autoconf

Akim Demaille writes: > > "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: > > >> 67. ./syntax.at:27 FAILED near `syntax.at:27' > > Pavel> AC_F77_WRAPPERS > > I suppose you have a Fortran compiler on this machine, but not GNU. > Autoconf has indeed weaknesses wrt Fortran support. I ju

Re: Call for testing CVS Autoconf

Akim Demaille writes: > > I think we addressed the most serious bugs. I propose we plan 2.49b > this Friday. Let's work on the remaining serious bugs, but even if > there are some left, let's snapshot, too many people are waiting for a > better snapshot than 2.49a. > > So please, if you happen

Re: configure options

> I'm working on a project with a pretty large (and increasing) > number of configure parameters, so I look for ways to store sets > of parameters externally, such that they be used much like config.cache, > if desired. Since all possible arguments could be known from the macros > used in config

AC_SUBST question

Are AC_SUBST/AC_SUBST_FILE recursive? I have a case where a file inserted with AC_SUBST_FILE contains @variable@, to be substituted by AC_SUBST, but it doesn't seem to work. This is with autoconf 2.13. _But_: someone else tells me that it works for him! Ideas? Could it be that it's depend

Re: OpenBSD 2.7

> I've just installed OpenBSD 2.7. > > Good news: the testsuite passes with one test ignored (due to lack of > /lib/cpp) and 160 tests passed! The only additional GNU packages were > m4-1.4, sed-2.05 and make-3.78.1 Have you tried the native m4, too? See http://sources.redhat.com/ml/autocon

Re: Meta list issue: subject prefixes

> * Here is a small procmail receipt to ignore duplicate emails. Because of > this I did not get multiple copies: > > :0 Wh: $PMDIR/msgid.lock > | /usr/local/bin/formail -D 8192 $PMDIR/msgid.cache This recipe is *dangerous* and can lead to loss of mail. Re-read the procmailrc man page and

Re: Meta list issue: subject prefixes

> > I third that. It made it really easy to scan my inbox and see what went where. > > ;-( > > There are many many better ways to sort one's mail than to depend on > some broken mailing list manager corrupting subject headers. Indeed. Check out the Subject lines of eg. http://sources.

Re: [Autoconf] FREE CD RATESERVICE OPENS ON THE INTERNET

Can the autoconf and automake lists please be configured to *not* add [listname] to the Subject line? Subject: [Autoconf] FREE CD RATESERVICE OPENS ON THE INTERNET Subject: [Automake] FREE CD RATESERVICE OPENS ON THE INTERNET ^^ My spam filters are greatly complicated by

Re: grep -E ? (Was: Compilation problem solved)

Alexandre Oliva writes: > On Aug 29, 2000, Earnie Boyd <[EMAIL PROTECTED]> wrote: > > > AFAIK '^ *+' is a regular expression and not an extended regular > > expression. > > `+' after `*' isn't portable, IIRC. In fact, I don't understand what > we're trying to accomplish with that construct. It

Re: grep -E ? (Was: Compilation problem solved)

> After that, I have tried to identify what was wrong. I found that in the > configure script: > > --- configure.origSat Aug 26 18:20:16 2000 > +++ configure Sat Aug 26 18:20:39 2000 > @@ -1349,7 +1349,7 @@ > EOF > ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" > { (eval ech

Re: Should gcc use the -pipe option by default?

>I have noticed that there are a number of packages that >include extra code to test for and enable the -pipe >option to gcc. I think it might be a good idea to add >the -pipe option to the default CFLAGS if gcc is detected and >the -pipe option is supported. What do you think

Re: Should gcc use the -pipe option by default?

Akim Demaille writes: > > "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: [...] > Alexandre> I think this should not be done by default. -pipe is more > Alexandre> CPU-intensive than regular builds, so it should be up to > Alexandre> the builder to decide whether to use it or not.

Re: setting shell variables at the command line

Assar Westerlund writes: > Lars Hecking <[EMAIL PROTECTED]> writes: > > > env MYVAR="value of myvar" configure > > > > That's C shell syntax, which is quite limited. > > Not really. I used env to make the example shell-independent. You >

Re: setting shell variables at the command line

Assar Westerlund writes: > "John A. Crow" <[EMAIL PROTECTED]> writes: > > I would like to know what is the standard or preferred way of setting > > a variable at the configure command line. > > In the CVS version of autconf you can do: > > configure MYVAR="value of myvar" > > In autoconf 2.13,

Re: rfc: new libgcc build mechanism

> Absolutely right! You got it! > > System V and Pure BSD are just like the USA and USSR during the Cold War. We, Last time I checked, the Cold War was kinda over ... > the Pure BSD camp, will never have anything from Missed'em-five. That's why we > are *pure* BSD. Being SysVile-free is what

Re: rfc: new libgcc build mechanism

> to make that happen. "We don't care about 4.3BSD" is not an excuse. You have > to in order to be able to say that you really work as GNU intended. Nobody even implied this. Your response is way over the top, IMHO.

Re: Defining headers

Mo DeJong writes: > I think you have run into a bug in autoheader. The problem seemes > to be that a call to: There is no bug in autoheader. autoheader itself is a bloody bug, and I'm wondering whether it's been eliminated from the current cvs.

Re: autoheader question

> The problem was that Lars was AC_DEFINE($var), which unfortunately > is not extensible in 2.13. It is now, and autoheader, IMHO, achieves > that end for both the maintainer, *and* the end user. I personally > consider it is a requirement that all the #undef templates be > documented/described

Re: autoheader question

> Hm, I might be over picky, but I would have answered no. autoheader > 2.13 is including all the paragraphs which are related to something > which is AC_DEFINE'd, which is not necessarily all the content of > acconfig.h. What about AC_DEFINE_UNQUOTED? And, shouldn't autoheader check aclocal.m

autoheader question

$ autoheader --version Autoconf version 2.13 One thing I can't seem to figure out: if acconfig.h exists, is autoheader supposed to add all its contents to config.h.in? And if this doesn't happen, is there a way to find out why?

Re: AC_PROG_CC_STDC patch

Peter Eisentraut writes: > I've written about it before, here's the patch. It changes AC_PROG_CC_STDC > to try the `-std' flag rather than `-std1' (for OSF or Ultrix) because the > latter is kind of like 'gcc -ansi' (i.e., terminally strict). I've been wondering about this for a while. And I co

Re: warnings are errors?

> You need to tell us what tests you are doing in your configure.in for > us to figure out why this is happening. > > IMHO, whatever programs has installed jconfig.h is in the wrong here, > you should not install configure-generated header files. It's jpeglib - currently ftp://ftp.uu.net/graph

Re: Absolute srcdir

Lars J. Aas writes: > BTW, is anyone cataloguing these kinds of bourne shell bugs/anomalies > somewhere? Seems like something like that would be a *very* useful resource > for portable shell script programmers... > > Lars J There is a Unix shell FAQ out there, but the document I have here i

Re: Absolute srcdir

Akim Demaille writes: > Ralf Corsepius sent me this morning a detailed PR with about the same > behavior. I'm highly tempted to consider this a bash bug, unless > someone can demonstrate the usefulness of the following feature... I tend to agree. I ran your little script with /bin/sh and /bin/k

Re: sys/stat.h

Akim Demaille writes: > > Portable or not? Some acspecific tests check its existence, others > don't. Which is right? (Should definitely be documented). According Stevens, sys/stat.h is not in ANSI/ISO C in POSIX.1 and XPG3 (which I assume makes it xpg4, too) implemented in SVR4 and 4.

Re: config.cache considered harmful

Pavel Roskin writes: > Hello, Martin! > > > Let's think about when you would ever want to reuse a cache within a > > simple single GNU package. I claim you _never_ want to reuse that > > config.cache file sitting in your foo-1.9 directory. Why are you > > re-running configure, anyways, instead

Re: config.cache considered harmful

> Martin> I think I used `unset'. And XEmacs' configure uses `unset' > Martin> today, and no one I know of has hit this non-portability. > > I claim that machines without Bourne shells supporting unset and > functions are no longer to be considered. No single guy could name me > such a broken

Re: autoconf is broken in various ways

Tom Tromey writes: > > "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes: > > Martin> Did you know that Linux Mandrake 7.0's autoconf claims to be > Martin> version 2.14.1? > > That's really losing. > > Martin> (XEmacs redefines AC_DEFINE) > > Wow, why? XEmacs configure is heavily c

Re: A problem on anoncvs

It was only posted here _yesterday_. http://sourceware.cygnus.com/ml/autoconf/2000-02/msg00187.html OKUJI Yoshinori writes: > I got the following report: > > From: "jyllyj" <[EMAIL PROTECTED]> > Subject: Re: GNU grub CVS > Date: Wed, 23 Feb 2000 23:55:00 +0800 > > > thank's for your reply