Re: aclocal7.test fail only
thanks for the help that was it Navillus
Re: depcomp deficiency [was: m4-1.4.7 build feedback]
Hello Nelson, Eric, Thanks for the bug report. * Eric Blake wrote on Wed, Sep 27, 2006 at 04:21:27AM CEST: According to Nelson H. F. Beebe on 9/26/2006 8:51 AM: Machinetype:Sun W40z (4 CPUs, 2400 MHz AMD64 Opteron, 8GB RAM); FreeBSD 6.1-RELEASE #0 Configure environment: CC=/usr/bin/c89 CFLAGS=-I/usr/local/include CXX=/usr/bin/g++ if /usr/bin/c89 -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../lib -I/usr/local/include -MT m4.o -MD -MP -MF .deps/m4.Tpo -c -o m4.o m4.c; \ then mv -f .deps/m4.Tpo .deps/m4.Po; else rm -f .deps/m4.Tpo; exit 1; fi c89: illegal option -- M usage: c89 [-cEgOs] [-D name[=value]] ... [-I directory] ... [-L directory] ... [-o outfile] [-U name] ... operand ... where operand is one or more of file.c, file.o, file.a or -llibrary make[2]: *** [m4.o] Error 1 What a wimpy compiler wrapper. If they're going to wrap gcc, they might as well recognize options that are pure POSIX extensions rather than crashing on them. Hehe, the compiler wrapper is interesting in that it depends upon the order of the arguments whether it crashes or not. It is probably not worth trying to fix this, although doing so would likely enhance portability to a wider range of c89 and c99 compilers on other systems. It's certainly worth fixing this, but it will probably not affect other systems, IMVHO. In short, the problem here is that the depcomp algorithm for determining what dependency checking to request is being fooled by the fact that your compiler claims to be gcc thanks to its definition of __GNUC__, No, that is not the issue in this case. The Automake dependency tests are pure functionality tests (unlike, say, some of Libtool's tests). then fails to recognize -M options for dependency checking. A fix would have to come from automake, which maintains depcomp, to gracefully try whether -M actually works before deciding that a compiler is really gcc3 compatible. Yes. The bug in Automake is that the _AM_DEPENDENCIES test uses a different argument order than what is used later, during compilation: | $ c89 -MT sub/conftest.o -MD -MP -MF sub/conftest.TPo -c -o sub/conftest.o sub/conftest.c | c89: illegal option -- M | usage: c89 [-c] [-D name[=value]] [...] [-E] [-g] [-I directory ...] |[-L directory ...] [-o outfile] [-O] [-s] [-U name ...] operand ... | |where operand is one or more of file.c, file.o, file.a |or -llibrary | $ c89 -c -o sub/conftest.o sub/conftest.c -MT sub/conftest.o -MD -MP -MF sub/conftest.TPo | sub/conftest.c:7: warning: ISO C forbids an empty source file | $ echo $? | 0 I'll look into a fix. (I suspect that when it comes to argument ordering, there are more potential problem areas lingering in the autotools.) The FreeBSD folks may want to know about this bug in their wrapper; but come to think of it, I'm not even sure that it is a bug, or maybe intended behavior. Cheers, Ralf
Re: depcomp deficiency [was: m4-1.4.7 build feedback]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Nelson H. F. Beebe on 9/27/2006 7:23 AM: Thanks for the comments on the automake testing in the depcomp code. Here is what POSIX (IEEE Std 1003.1-2001: Revision of IEEE Std 1003.1-1996 and IEEE Std 1003.2-1992) has to say: ... As far as I can see, POSIX-2001's requirements for compiler options are met by the BSD c89 and c99. In particular, there are no provisions for generation of dependencies, like gcc's -M option family offers. Yes, we are aware that -M is not standardized. That is why depcomp knows several flavors of how to generate dependency tracking, including a method that involves no compiler support (by looking at preprocessor output in a separate process instead). By default, automake projects turn on dependency tracking for compilers that can do something like -M, where the dependency tracking is a side-effect of compilation with minimal overhead, and leaves it off for compilers that require a separate process. The problem that you reported is that you have a compiler that fooled automake's depcomp into thinking it supported side-effect dependency when it really didn't. I've never understood why some packages feel the need to generate dependencies at build time at every end-user site, rather than at a single developer site. In my own packages, I maintain the Makefile dependencies myself, and don't require their generation during builds. Then you should use './configure --disable-dependency-tracking' - this is exactly what it was invented for. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGn7Z84KuGfSFAYARAqzaAJ9b5cSpx5s0R4Ygida/llAlKPPJfgCeIjFq SOcgSHb1dmp6XoBzhZ8yR0g= =izMx -END PGP SIGNATURE-
Re: depcomp deficiency [was: m4-1.4.7 build feedback]
Hello Nelson, * Nelson H. F. Beebe wrote on Wed, Sep 27, 2006 at 03:23:45PM CEST: The BSD folks are a different religion from the GNU folks, so conflicts in software interfaces are to be expected. Not really. The Automake dependency tracking code tries quite hard to work with any compiler (or compiler wrapper) thrown at it. And certainly there is a bug in it currently, and we're going to fix it. As far as I can see, POSIX-2001's requirements for compiler options are met by the BSD c89 and c99. In particular, there are no provisions for generation of dependencies, like gcc's -M option family offers. Which is just fine. And the dependency tracking code works fine with compilers that have no way of generating dependencies. The issue is much more special in this case: the FreeBSD compiler wrapper c89 accepts the options -MP -MD -MF -MT if they appear _after_ all the other command line arguments, esp. the source files; and in that case, it even produces correct dependency output. (Well, this to be expected: under the hood, there's a GCC doing its work.) c89 only fails to accept the command line if the above options appear _before_ the source file. The bug in Automake is that, for testing at configure time, a different order is used as at compile time. (I am going to propose a patch, but I need to check some consistency cases first, so that this does not happen again.) And, to repeat, while I don't think it may strictly be called a bug in the FreeBSD /usr/bin/c89 program to accept undocumented command line arguments in some places but not in others (as both are undefined behavior wrt. to what the standard has to say), it is certainly a quality of implementation issue that c89 behaves this way, instead of failing with both orderings. I've never understood why some packages feel the need to generate dependencies at build time at every end-user site, rather than at a single developer site. In my own packages, I maintain the Makefile dependencies myself, and don't require their generation during builds. Well, first, it is very simple for the end-user to turn this mechanism off: ./configure --disable-dependency-tracking Then, it is only turned on by default if the dependency tracking mechanism is fast in the sense that it can be done as a side-effect of compilation. To also turn on slow tracking mechanisms, you explicitly have to write ./configure --enable-dependency-tracking As a final comment, let me state that allowing to generate dependencies at the end-user site is just a logic consequence of the general theme that every user is a potential developer: that's why autotooled packages ship with configure.in/configure.ac, and aclocal.m4, and possibly more files that would not be strictly necessary for an end-user, but that serve as input files to generated files shipped with the package. Hope this helps a bit, and thanks again. Cheers, Ralf
how to turn off shared library notice in output of make install?
Howdy all! I am using autoconf/automake/libtool to build a popular freeware climate science data package (netCDF). I have shared libraries turned off by default, by having this in my configure.ac: AM_DISABLE_SHARED Of course, when the user wants shared libraries, he gets them, by using --enable-shared. But most of my users will not do this. When I build and do a make install, with or without shared libraries, I get the following notice in the output: -- Libraries have been installed in: /shecky/n3_new/install/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- This is all well and good for shared libraries, but can I somehow turn off this notice in the case of static libraries only? Otherwise it will confuse many users... Thanks, and thanks for the fine freeware too! Ed -- Ed Hartnett -- [EMAIL PROTECTED]
Re: depcomp deficiency [was: m4-1.4.7 build feedback]
Ralf Wildenhues [EMAIL PROTECTED] writes: The issue is much more special in this case: the FreeBSD compiler wrapper c89 accepts the options -MP -MD -MF -MT if they appear _after_ all the other command line arguments, The wrapper probably just stops parsing options at the first non-option, and passes all remaining arguments unchanged. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: how to turn off shared library notice in output of make install?
[ Cc:ing bug-libtool ] Hello Ed, Thanks for the bug report. * Ed Hartnett wrote on Wed, Sep 27, 2006 at 03:54:00PM CEST: I have shared libraries turned off by default, by having this in my configure.ac: AM_DISABLE_SHARED When I build and do a make install, with or without shared libraries, I get the following notice in the output: -- Libraries have been installed in: /shecky/n3_new/install/lib If you ever happen to want to link against installed libraries [...] See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- This is all well and good for shared libraries, but can I somehow turn off this notice in the case of static libraries only? Several comments: first, this comment is not written if libtool gets the option --silent. With the next Automake release, the user will be able to use configure LIBTOOLFLAGS=--silent or make LIBTOOLFLAGS=--silent to avoid much of libtool's blabla, and the developer will be able to set AM_LIBTOOLFLAGS=--silent in his Makefile.am. But I agree that in the static case, the notice is wrong. It's not completely superfluous, but maybe only something like this would suffice: | -- | Libraries have been installed in: |/shecky/n3_new/install/lib | | If you ever happen to want to link against installed libraries | in a given directory, LIBDIR, you can use libtool, and specify | the full pathname of the library, or use the `-LLIBDIR' | flag during linking. | -- Or would people prefer that nothing be output in this case? Somewhat independently though, I also think that, when a package has many directories and many makefiles from which libraries are installed, then it would be neater to only output this blurb once, or at most once per installation directory. Or aggregated, as in: | -- | Libraries have been installed in: |/shecky/n3_new/install/lib |/shecky/n3_new/install/lib64 | | Modules have been installed in: |/shecky/n3_new/install/lib/foopkg/ [...] I don't see a trivial way to do this in Automake/Libtool yet, but I suppose it could be solved at the same time as the inter-makefile library-installation-order issue is solved. Cheers, Ralf
Re: depcomp deficiency [was: m4-1.4.7 build feedback]
Thanks for the comments on the automake testing in the depcomp code. The BSD folks are a different religion from the GNU folks, so conflicts in software interfaces are to be expected. Here is the synopsis of the c89 compiler in FreeBSD 5.0: NAME c89 - POSIX.2 C language compiler SYNOPSIS c89 [-c] [-D name[=value]] ... [-E] [-g] [-I directory ...] [-L directory ...] [-o outfile] [-O] [-s] [-U name ...] operand ... DESCRIPTION This is the name of the C language compiler as required by the IEEE Std 1003.2 (``POSIX.2'') standard. In FreeBSD 6.1, we have NAME c89 -- POSIX.2 C language compiler SYNOPSIS c89 [-cEgOs] [-D name[=value]] ... [-I directory] ... [-L directory] ... [-o outfile] [-U name] ... operand ... In NetBSD 1.6 and 3.0, we have SYNOPSIS c89 [-pedantic] [-pedantic-errors] [-D_ANSI_SOURCE] [options ...] DESCRIPTION Calls the C compiler (cc) with the given options, using a C language environment compatible with the ANSI X3.159-1989 (``ANSI C89'') specifi- cation. STANDARDS c89 conforms to IEEE Std 1003.2-1992 (``POSIX.2''). HISTORY c89 appeared in NetBSD 1.4. OpenBSD 3.5 and 3.9 are Western Orthodox, and thus don't provide either c89 or c99. Here is what POSIX (IEEE Std 1003.1-2001: Revision of IEEE Std 1003.1-1996 and IEEE Std 1003.2-1992) has to say: 8176 NAME 8177 c99 -- compile standard C programs 8178 SYNOPSIS 8179 CD c99 [-c] [-D name[=value]]...[-E] [-g] [-I directory] ... [-L directory] 8180 ... [-o outfile] [-Ooptlevel] [-s] [-U name]... operand ... 8181 8182 DESCRIPTION 8183 The c99 utility is an interface to the standard C compilation system; it shall accept source code 8184 conforming to the ISO C standard. The system conceptually consists of a compiler and link 8185 editor. The files referenced by operands shall be compiled and linked to produce an executable 8186 file. (It is unspecified whether the linking occurs entirely within the operation of c99; some 8187 implementations may produce objects that are not fully resolved until the file is executed.) ... 8518 The c99 utility is based on the c89 utility originally introduced in the ISO POSIX-2: 1993 standard. ... 9065 The c99 utility is added as a replacement for c89, which is withdrawn in this issue. As far as I can see, POSIX-2001's requirements for compiler options are met by the BSD c89 and c99. In particular, there are no provisions for generation of dependencies, like gcc's -M option family offers. I've never understood why some packages feel the need to generate dependencies at build time at every end-user site, rather than at a single developer site. In my own packages, I maintain the Makefile dependencies myself, and don't require their generation during builds. --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: [EMAIL PROTECTED] - - 155 S 1400 E RM 233 [EMAIL PROTECTED] [EMAIL PROTECTED] - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Re: how to turn off shared library notice in output of make install?
Ralf Wildenhues [EMAIL PROTECTED] writes: [ Cc:ing bug-libtool ] Hello Ed, Howdy Ralf! Several comments: first, this comment is not written if libtool gets the option --silent. With the next Automake release, the user will be able to use configure LIBTOOLFLAGS=--silent or make LIBTOOLFLAGS=--silent to avoid much of libtool's blabla, and the developer will be able to set AM_LIBTOOLFLAGS=--silent But can this be done now? That is, can I somehow send the --silent to libtool now? in his Makefile.am. But I agree that in the static case, the notice is wrong. It's not completely superfluous, but maybe only something like this would suffice: | -- | Libraries have been installed in: |/shecky/n3_new/install/lib | | If you ever happen to want to link against installed libraries | in a given directory, LIBDIR, you can use libtool, and specify | the full pathname of the library, or use the `-LLIBDIR' | flag during linking. | -- Or would people prefer that nothing be output in this case? Either way would be fine by me. Somewhat independently though, I also think that, when a package has many directories and many makefiles from which libraries are installed, then it would be neater to only output this blurb once, or at most once per installation directory. Or aggregated, as in: | -- | Libraries have been installed in: |/shecky/n3_new/install/lib |/shecky/n3_new/install/lib64 | | Modules have been installed in: |/shecky/n3_new/install/lib/foopkg/ [...] I don't see a trivial way to do this in Automake/Libtool yet, but I suppose it could be solved at the same time as the inter-makefile library-installation-order issue is solved. Well, no need to get too fancy. Ed -- Ed Hartnett -- [EMAIL PROTECTED]
Re: how to turn off shared library notice in output of make install?
* Ed Hartnett wrote on Wed, Sep 27, 2006 at 04:59:01PM CEST: Ralf Wildenhues [EMAIL PROTECTED] writes: to avoid much of libtool's blabla, and the developer will be able to set AM_LIBTOOLFLAGS=--silent But can this be done now? That is, can I somehow send the --silent to libtool now? Not easily I think, no. Sorry. Cheers, Ralf
Re: depcomp deficiency [was: m4-1.4.7 build feedback]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Andreas Schwab on 9/27/2006 8:00 AM: Ralf Wildenhues [EMAIL PROTECTED] writes: The issue is much more special in this case: the FreeBSD compiler wrapper c89 accepts the options -MP -MD -MF -MT if they appear _after_ all the other command line arguments, The wrapper probably just stops parsing options at the first non-option, and passes all remaining arguments unchanged. Which sounds like a bug in the wrapper to me (like the one that was just fixed in the post coreutils 6.2 groups script). If they really want to stop parsing options, and pass all remaining arguments to gcc, then they should be using -- between the options they give gcc and the remaining arguments that they pass unchanged. But as long as that bug in the wrapper is still present, we might as well exploit it in depcomp :) - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGxns84KuGfSFAYARAppXAKCOBXg3JyqwuAhcvV4+uJpL4sFJowCfQLEc CM6NSC8wavF/lnzvoENwu5Q= =oJBv -END PGP SIGNATURE-
Re: how to turn off shared library notice in output of make install?
Ralf Wildenhues [EMAIL PROTECTED] writes: snip | -- | Libraries have been installed in: |/shecky/n3_new/install/lib | | If you ever happen to want to link against installed libraries | in a given directory, LIBDIR, you can use libtool, and specify | the full pathname of the library, or use the `-LLIBDIR' | flag during linking. | -- Or would people prefer that nothing be output in this case? I would prefer very short warnings with a link to a section in an appendix in the manual that in depth explain what the warning really means, in a language even I can understand ;-) I think the GNU autotools are such great stuff, but as it is attacking a hard problem it needs lots of documentation. The amount of flexibility given enable you to shoot yourself in the foot in so many ways. And there is a difference between what you can do, and what you should do, knowledge hard to gain even if googling a lot. I have been toying with an idea to create a wiki or something that is a GNU autotools cookbook. Not a tutorial, but more like the Perl cookbook. Unfortunately I still know way too little about the GNU autotools to fill in enough material for it to be useful. Just for fun I include below a very fast written down Q/A sketch. Not the real thing and the few answers I put in are likely not right. Don't consider it real questions and answers, I just try show the idea and what kind of style it could be in. Maybe there is such a thing already and I just failed to find it. * General questions Q: When do I want to use aufoconf? When automake? When libtool? What combinations? Is there ever an idea to use libtool without the other tools? To use automake without libtool? Q: The auto in the name of automake and autoconf, does this mean I can create the build environment on one platform and the build will work on all Unix/Linux platforms? A: Unfortunately not. Libtool is kind of a script with collectively built in knowledge built up over time, so yes it will in most cases solve the problem how to link and create executables and libraries on all platforms. It knows things, as it has its own (a bit unstructured) database over what to do. But for a new platform it might be lost. Autoconf threoretically will find out what is right by doing tests instead of relying on any built in knowledge. Tests to try find out things about your compiler, linker and operating system. And there is a library of macros you can use to customize what tests you want it to perform. Still, in most cases this is not enough. You will find yourself writing new tests for things not covered, and for each new platform you start building on, find yourself doing tweaks. If you google around you will find most configure.in scripts to be quite messy and many of them buggy. So this is not easy and definitely not automatic. Automake is more like a toolbox where someone else has written many tests saving you time. Automake will from a simplified make file, Makefile.am, that try to look like a specification, create portable make files Makefile.in. When the user unpack he runs the configure script it will fill in the last parts to create the actual Makefile. Automake works well in most cases. But it is easy to write unmaintainable Makefile.am files as well. Q: If I run into problems and need to call for help, what is the rule of thumb for what is to send to automake@gnu.org, autoconf@gnu.org and libtool@gnu.org? A: See the diagram at the page ., but in general (I'm sure the maintainers doesn't agree, but for me they are really one package and I would be happy if they were distributed as one package ;-) ) * Cookbook (should be more structured of course) Q: How do I make sure make dist copies the source I want to be included? A: All files listed in the varaibles below will be included prog_SOURCES . . Those in BUILT_SOURCES will Other files in your original source tree that you want to be part of the dist package, you list in YYY. Q: How do I include almost all in a directory without listing all files? A: You can give a directory to EXTRA_DIST, and then remove what was too much using as an example dist-hook: rm -rf `find $(distdir) -type d -name CVS -print` Q: What will automatically be cleaned with make distclean, make clean, and how do I add more things to clean away? A: There should be no more things if you have specified right... But you can Q: What are the different install locations and do they differ between different flavors of Unix, like Linux and Solaris? Q: How do I specify what to install? (built, generated, static...) Q: What are the rules of thumb
