failed test: multlib
Hi, On my new macbook running OS X 10.5.5, I downloaded automake 1.10.1, and the multlib test failed. Attached, please find the verbose output of the test and my config.log. Let me know if you need any more information. - Nick config.log Description: Binary data multlib.out Description: Binary data
Re: Incorrect information in the manual about the tar-v7 option
[ http://thread.gmane.org/gmane.comp.sysutils.automake.bugs/4315 ] Hello Vincent, all, Thanks for the report. * Vincent Lefevre wrote on Wed, Sep 17, 2008 at 06:09:43PM CEST: The automake manual (several versions) says about the tar-v7 option: `tar-v7' selects the old V7 tar format. This is the historical default. This antiquated format is understood by all tar implementations and supports file names with up to 99 characters. This is incorrect. Well, I think at the time the sentence was written in 2004: http://thread.gmane.org/gmane.comp.gnu.tar.bugs/433/focus=464 it was likely correct. It only became incorrect when BusyBox entered the scene, grew to be widely used, but with limited functionality. (The whole thread is quite informative.) Old versions of BusyBox (such as v1.6.1, currently used on Nokia's Internet tablets) don't support this format. See: https://bugs.maemo.org/show_bug.cgi?id=3033 Interesting. :-/ Shouldn't tar-ustar be the default instead of tar-v7? I'm not an expert on tar implementations and their issues, and what would be a good default nowadays. Help? I Cc:ed a couple of people knowledgeable about tar history, and the automake list. The question how far autotools should cater to limitations of new and open source software like BusyBox is quite a difficult one to answer in general, to me. Should autotools add even more workarounds, or should rather simply BusyBox be fixed? Do added workarounds here remove the incentive to fix the buggy software there? How much should the fact that BusyBox is actively developed be taken into account (unlike, say, pdksh, with its quite stable set of bugs)? Thanks, and sorry for the wide distribution, Ralf
Re: Incorrect information in the manual about the tar-v7 option
Ralf Wildenhues [EMAIL PROTECTED] writes: * Vincent Lefevre wrote on Wed, Sep 17, 2008 at 06:09:43PM CEST: The automake manual (several versions) says about the tar-v7 option: `tar-v7' selects the old V7 tar format. This is the historical default. This antiquated format is understood by all tar implementations and supports file names with up to 99 characters. [...] Old versions of BusyBox (such as v1.6.1, currently used on Nokia's Internet tablets) don't support this format. See: [...] Should autotools add even more workarounds, or should rather simply BusyBox be fixed? If only old versions of BusyBox do not support v7 tar format, as Vincent implies, then BusyBox has already been fixed, and Nokia just needs to upgrade to a current version. -- Ben Pfaff http://benpfaff.org
Re: MAINTAINERCLEANFILES for autotools
* Behdad Esfahbod wrote on Wed, Sep 17, 2008 at 12:23:16AM CEST: Ralf Wildenhues wrote: One problem is that it is surprisingly difficult to remove all files correctly in all the different setups that autotools support, in such a way that 'make' both finishes cleanly, and doesn't cause any autotools reruns on the way. I fully understand how tricky it gets. Re maintainer-clean vs bootstrap-clean, the most common understanding I've seen (and have personally always assumed is): - clean removes all files generated by make but not by configure - distclean removes all files not in the tarball - maintainer-clean removes all files not in cvs/svn/git, which includes all bootstrap-generated files as well as any generated-distributed files. Now if you add bootstrap-clean I easily get what I want by a simple: maintainer-clean: bootstrap-clean Or that can be done by default. Well, if it cannot be done by default, then chances are that your simple addition will cause some dependency rebuild issue, too. But discussing code that doesn't exist yet is moot, really. What I'm saying is, when automake generates Makefile.in from Makefile.am, it's clear that that Makefile.in will be processed by configure to generate Makefile. Right? At least I don't know of useful exceptions; hmm, maybe someone having a toplevel Makefile.am file only for ACLOCAL_AMFLAGS, and otherwise using a hand-written GNUmakefile. Hmm. Or is there any useful scenario that doesn't do that? Automake should automatically AC_CONFIG_FILES() those Makefile's. For other Makefile.in's, it's up to the user to list them. One issue here is that automake is not necessarily run before autoconf. There is not really a way to pass information from automake to autoconf. Cheers, Ralf
Re: failed test: multlib
On Wed, Sep 17, 2008 at 3:20 PM, Ralf Wildenhues [EMAIL PROTECTED] wrote: This particular failure is due to your compiler leaving behind lots of *.dSYM directories. Autoconf 2.62 and newer should have measures put in place to remove them I think. I'm not sure if that is sufficient to fix this Automake test failure though. Can you try to install 2.62, or even better 2.63, and use that with Automake 1.10.1, and report back? With Autoconf 2.63 and Automake 1.10.1, the multlib test worked fine. In fact, I had 2.63 installed already; it was just that my PATH didn't point to it. Sorry for the trouble. - Nick
Re: aclocal flags are a pain
* Behdad Esfahbod wrote on Wed, Sep 17, 2008 at 08:40:31AM CEST: Ralf Wildenhues wrote: Not sure what you're after here. The tools themselves will bail out anyway if they are too old (discounting automake 1.4 here). What's the gain of having autoreconf bail out? Right. May have been old cruft for automake 1.4. I also see that libtoolize doesn't do the check. Then again, the AC_PROG_LIBTOOL does not take a version either, but for some reason we needed to add a check. I just pass [1.4] to my AC_PROG_LIBTOOL and use the same shell function to extract and enforce that version in autogen.sh. Please get accustomed to not being in 2006 any more, and use LT_INIT and LT_PREREQ from Libtool 2.2.x. Do NOT pass arguments to AC_PROG_LIBTOOL: the API did not define them, which pretty much amounts to: we can extend the API later to have them have some meaning. In fact, that has already happened. Cheers, Ralf
Re: aclocal flags are a pain
* Behdad Esfahbod wrote on Wed, Sep 17, 2008 at 06:11:15AM CEST: Behdad Esfahbod wrote: Reading autoreconf source right now. I may just switch to it if my testers tell me it works on OS X and msys. Ok, I see the following things that I like to be able to do but autoreconf does not do currently: Most of which can be had, or at least worked around, by using the overriding environment variables AUTOCONF, LIBTOOLIZE, ACLOCAL, AUTOMAKE, no? * Many autogen.sh scripts I've seen try each of automake, automake-1.10, automake-1.9 automake-1.8 automake-1.7 in that order to pick the first one available. I'm sure there's good reason for them doing that. Perhaps because of some stupid packaging by some distro at some time... Which distro doesn't set plain 'automake' to be the latest version, at least by default? My autogen.sh also checks for glibtoolize before libtoolize as I mentioned before. Hmm, this is one thing that strikes me as a sensible change. * My autogen.sh also checks the version of the available tools against those requested in configure.ac. Would be trivial to do in autoreconf as it already traces configure.ac. Not sure what you're after here. The tools themselves will bail out anyway if they are too old (discounting automake 1.4 here). What's the gain of having autoreconf bail out? * GNOME packages also need to run intltoolize and gtkdocize. Would be nice to add them in autoreconf. I can cook a patch if there is interest. No principled objections. Is there a simple way to detect whether these need to be run? * Not sure about this one, but I think autoreconf options --force and --install kinda take my flexibility away to apply those to some of the tools but not others. For example we have a hand written INSTALL file in cairo. Running autoreconf --install --force overrides my INSTALL file. But I need those options for the libtoolize call. Again, use environment variables to add --force on a case-by-case basis. Or save and restore INSTALL. (INSTALL is a debatable point. There are good arguments for overriding it, and good ones for keeping it, with --force. How to detect whether it was modified by the package author?) Cheers, Ralf
Re: aclocal flags are a pain
Ralf Wildenhues wrote: * Behdad Esfahbod wrote on Wed, Sep 17, 2008 at 06:11:15AM CEST: Behdad Esfahbod wrote: Reading autoreconf source right now. I may just switch to it if my testers tell me it works on OS X and msys. Ok, I see the following things that I like to be able to do but autoreconf does not do currently: Most of which can be had, or at least worked around, by using the overriding environment variables AUTOCONF, LIBTOOLIZE, ACLOCAL, AUTOMAKE, no? Yes, but at that point it will be easier to just call them. * Many autogen.sh scripts I've seen try each of automake, automake-1.10, automake-1.9 automake-1.8 automake-1.7 in that order to pick the first one available. I'm sure there's good reason for them doing that. Perhaps because of some stupid packaging by some distro at some time... Which distro doesn't set plain 'automake' to be the latest version, at least by default? Prolly no modern ones. I know Debian (and maybe Ubuntu) at some point used 1.7 as automake, but had 1.8 available too. That still was a problem anyway. My autogen.sh also checks for glibtoolize before libtoolize as I mentioned before. Hmm, this is one thing that strikes me as a sensible change. * My autogen.sh also checks the version of the available tools against those requested in configure.ac. Would be trivial to do in autoreconf as it already traces configure.ac. Not sure what you're after here. The tools themselves will bail out anyway if they are too old (discounting automake 1.4 here). What's the gain of having autoreconf bail out? Right. May have been old cruft for automake 1.4. I also see that libtoolize doesn't do the check. Then again, the AC_PROG_LIBTOOL does not take a version either, but for some reason we needed to add a check. I just pass [1.4] to my AC_PROG_LIBTOOL and use the same shell function to extract and enforce that version in autogen.sh. * GNOME packages also need to run intltoolize and gtkdocize. Would be nice to add them in autoreconf. I can cook a patch if there is interest. No principled objections. Is there a simple way to detect whether these need to be run? Sure. GTK_DOC_CHECK([1.6]) and IT_PROG_INTLTOOL([0.40.0]) for example. Now that I checked, there are even more programs that the higher level components of GNOME use. So, maybe keeping them in gnome-autogen.sh is the right way. * Not sure about this one, but I think autoreconf options --force and --install kinda take my flexibility away to apply those to some of the tools but not others. For example we have a hand written INSTALL file in cairo. Running autoreconf --install --force overrides my INSTALL file. But I need those options for the libtoolize call. Again, use environment variables to add --force on a case-by-case basis. Or save and restore INSTALL. (INSTALL is a debatable point. There are good arguments for overriding it, and good ones for keeping it, with --force. How to detect whether it was modified by the package author?) I remember in one project save/restoring INSTALL and COPYING. In the case for cairo the INSTALL file is totally different from the one automake installs. Maybe add a line like Generated by automake. Do not edit. or something now, and at some later point only override if that is found. Cheers, Ralf Anyway, no big deal. You asked why we don't plain use autoreconf and these are the immediate answers I found. Cheers, behdad
Re: Question about automatic generation of GPLv3 COPYING file
* Brian Cameron wrote on Wed, Sep 17, 2008 at 06:05:57AM CEST: Indeed, it isn't uncommon for a module to have differing licenses. That is pretty normal. However, I would think that the authors of the source code should be the people deciding how their code should be licensed, rather than an artifact of the build tools being used. It seems hard to ensure that such differing licenses are indeed compatible in any sort of automatic fashion. Certainly. Ralf Wildenhues wrote: You can use 'automake --foreign' or AM_INIT_AUTOMAKE([foreign]) to avoid installing GNU-related files. Without the 'foreign' option, automake by default installs GNU defaults. Not just for the COPYING file, but several other things as well. One of Automake's expressed goals is to create packages that match GNU's rules. Thanks for the pointer. I hadn't ever read the GNU Coding Standards document until you highlighted this point, and I found the document via Google. If automake's goal is to enforce GNU coding standards, then I could understand if it failed to work unless the file is present. Thus forcing the authors to create the file or use the 'foreign' option (or not use automake). Yes. However, just populating the file with an arbitrary license seems an error-prone way to enforce the standard. It's not arbitrary. Actually, until the switch to GPLv3, I cannot remember anyone complaining about this feature of Automake. I don't think anybody ever complained that automake did not cater to BSD- licensed projects here by default, for example. This issue really is about setting the defaults in the presence of a license that is not universally accepted. It seems a very unfriendly way to propagate a viral style license, and a way that could be really damaging to some users, and could generate bad feelings about the free software community. That to me really sounds a bit over the top. Given there are very easy ways to avoid this, and given that the current mode of operation is documented very clearly, While I do agree that it is documented reasonably, many people do not always read all related documentation. The question is: do we need to cater for people who both don't read the documentation and don't take care of writing a COPYING file themselves? (Yes, this is a bit pointed.) People who might decide to use autotools to build non-GNU programs might not be familiar with the GNU Coding Standard or be aware that automake silently enforces a license. But it doesn't enforce it! It merely adds a sensible default COPYING file (and what we're discussing is whether that sensible is good). It doesn't scribble in your README This package is licensed under GPLv3, see the COPYING file, neither does it put copyright notices at the top of your source files. Really the presence of some license in the COPYING file is not sufficient to declare the project's license fully, I think we've already agreed to that. and a COPYING file has forever been installed in the default mode, it would be confusing to many users if automake would stop doing this now. There might be some confusion. However, as I already explained there is already clearly some confusion about the way it currently works. Note the following bug reports. Clearly the authors of these modules were not aware of the ramifications of automake changing its default license to GPLv3: Were any of them aware of the feature at all? I.e., that COPYING was added, but in prior automake versions is contained the GPLv2 text? To me, this sort of confusion is really more serious than any confusion like where did my autogenerated COPYING file go. None of the bug reports were about COPYING files that were gone or overwritten. That would be really bad style. Putting incorrect and unintended licenses in a module is more confusing than putting no license. As you probably noticed, I work for Sun. Nobody at Sun has yet made any decisions about how automake on Solaris should behave. I was just curious about whether disabling the feature by default might be possible so all options can be considered. Sure. I would ask you not to change Automake's mode of operation from the default one, though. Currently Sun does not allow GPLv3 code to integrate into Solaris, which is why this is a particular issue at Sun. So, until this issue is resolved, I guess Sun will probably have to avoid updating to the latest versions of automake which generate a GPLv3 license. Though, disabling the feature by making 'foreign' the default might also be an option. Hopefully, Sun will approve of the GPLv3 license soon, so this issue just goes away. Ah, so this is the heart of the matter: Sun hasn't approved of GPLv3 code, and Automake might, if the developer was not diligent enough to take care of the license, add a GPLv3 file. Look, I'm really the wrong person to discuss license matters with. I hate the topic, I generally try to stay out of these
Re: Question about automatic generation of GPLv3 COPYING file
Ralf: However, just populating the file with an arbitrary license seems an error-prone way to enforce the standard. It's not arbitrary. Actually, until the switch to GPLv3, I cannot remember anyone complaining about this feature of Automake. I don't think anybody ever complained that automake did not cater to BSD- licensed projects here by default, for example. This issue really is about setting the defaults in the presence of a license that is not universally accepted. I think it is more than that. Although people may not have noticed this issue before, I think it is good to discuss and consider how automake should best work. The question is: do we need to cater for people who both don't read the documentation and don't take care of writing a COPYING file themselves? (Yes, this is a bit pointed.) Basically, I agree that is the question. However I would probably word it differently and say something like should automake error on the side of caution when making decisions about how code should be licensed. When I read technical documentation, I find I often need to read it a few times before I fully understand and grasp all the implications. So I think to suggest that only people who don't read the documentation could be unaware of a specific feature isn't really fair. People who might decide to use autotools to build non-GNU programs might not be familiar with the GNU Coding Standard or be aware that automake silently enforces a license. But it doesn't enforce it! It merely adds a sensible default COPYING file (and what we're discussing is whether that sensible is good). It doesn't scribble in your README This package is licensed under GPLv3, see the COPYING file, neither does it put copyright notices at the top of your source files. Really the presence of some license in the COPYING file is not sufficient to declare the project's license fully, I think we've already agreed to that. Yes, I agree enforce was a bad word choice. Obviously there is no enforcing going on. I should have said something like ...silently adds a license if a COPYING file doesn't exist. There might be some confusion. However, as I already explained there is already clearly some confusion about the way it currently works. Note the following bug reports. Clearly the authors of these modules were not aware of the ramifications of automake changing its default license to GPLv3: Were any of them aware of the feature at all? I.e., that COPYING was added, but in prior automake versions is contained the GPLv2 text? I am not sure. Perhaps some of those module owners were depending on that feature. If so, then the default license changing to GPLv3 may have caught them unawares. I am not sure how well the automake community communicated to users that they might need to consider the implications of their modules moving to GPLv3 if they were depending on this feature. I am a module maintainer (of the GDM module), and I wasn't made aware of this change by any announcement from the automake or any other free software community. But perhaps I didn't read the right docs or mailing lists. To me, this sort of confusion is really more serious than any confusion like where did my autogenerated COPYING file go. None of the bug reports were about COPYING files that were gone or overwritten. That would be really bad style. I was just trying to say that bad style (not following the GNU Coding Standard) is probably better than incorrect or confusing licensing information. But that's just my opinion. Currently Sun does not allow GPLv3 code to integrate into Solaris, which is why this is a particular issue at Sun. So, until this issue is resolved, I guess Sun will probably have to avoid updating to the latest versions of automake which generate a GPLv3 license. Though, disabling the feature by making 'foreign' the default might also be an option. Hopefully, Sun will approve of the GPLv3 license soon, so this issue just goes away. Ah, so this is the heart of the matter: Sun hasn't approved of GPLv3 code, and Automake might, if the developer was not diligent enough to take care of the license, add a GPLv3 file. This is what raised the issue to my attention. However, I was not previously aware that automake created a COPYING file for you if one was missing. Once I became aware of this feature, I didn't really like the idea of module license information ever being generated automatically. You say taking care of the license when I think you mean knowing to create a COPYING file or knowing you have to follow the GNU Style Guide if you use automake. Some users might think they have taken care of the license but also might not be following this style guide. Look, I'm really the wrong person to discuss license matters with. I hate the topic, I generally try to stay out of these discussions, and could personally care less about the default mode of operation of Automake. I'd prefer a poll of all users,
Re: Incorrect information in the manual about the tar-v7 option
[ http://thread.gmane.org/gmane.comp.sysutils.automake.bugs/4315 ] Hello Vincent, all, Thanks for the report. * Vincent Lefevre wrote on Wed, Sep 17, 2008 at 06:09:43PM CEST: The automake manual (several versions) says about the tar-v7 option: `tar-v7' selects the old V7 tar format. This is the historical default. This antiquated format is understood by all tar implementations and supports file names with up to 99 characters. This is incorrect. Well, I think at the time the sentence was written in 2004: http://thread.gmane.org/gmane.comp.gnu.tar.bugs/433/focus=464 it was likely correct. It only became incorrect when BusyBox entered the scene, grew to be widely used, but with limited functionality. (The whole thread is quite informative.) Old versions of BusyBox (such as v1.6.1, currently used on Nokia's Internet tablets) don't support this format. See: https://bugs.maemo.org/show_bug.cgi?id=3033 Interesting. :-/ Shouldn't tar-ustar be the default instead of tar-v7? I'm not an expert on tar implementations and their issues, and what would be a good default nowadays. Help? I Cc:ed a couple of people knowledgeable about tar history, and the automake list. The question how far autotools should cater to limitations of new and open source software like BusyBox is quite a difficult one to answer in general, to me. Should autotools add even more workarounds, or should rather simply BusyBox be fixed? Do added workarounds here remove the incentive to fix the buggy software there? How much should the fact that BusyBox is actively developed be taken into account (unlike, say, pdksh, with its quite stable set of bugs)? Thanks, and sorry for the wide distribution, Ralf
Re: Incorrect information in the manual about the tar-v7 option
Ralf Wildenhues [EMAIL PROTECTED] writes: * Vincent Lefevre wrote on Wed, Sep 17, 2008 at 06:09:43PM CEST: The automake manual (several versions) says about the tar-v7 option: `tar-v7' selects the old V7 tar format. This is the historical default. This antiquated format is understood by all tar implementations and supports file names with up to 99 characters. [...] Old versions of BusyBox (such as v1.6.1, currently used on Nokia's Internet tablets) don't support this format. See: [...] Should autotools add even more workarounds, or should rather simply BusyBox be fixed? If only old versions of BusyBox do not support v7 tar format, as Vincent implies, then BusyBox has already been fixed, and Nokia just needs to upgrade to a current version. -- Ben Pfaff http://benpfaff.org
Re: Issue with static linking?
Hello Micheal, * Micheal Smith wrote on Mon, Sep 15, 2008 at 11:23:57PM CEST: I'm not sure if this is more of a libtool issue, or an automake issue. Probably neither. I have some code that relies on libresolv to do mx lookups. This code uses functions within that library that are not exported unless compiled with the -static flag. I think the problem is that you shouldn't use these functions. Find out why you think you need them. Then get rid of that need. :-) One workaround would be to link the program completely static (-all-static), but I'm guessing it still won't give you the functionality you need (some of glibc's networking stuff only works from the shared library). And of course other functionality, which you have already found out. [...] gcc -g -O2 -o program main.o auth.o crypto.o errors.o htable.o interface.o llist.o logging.o smtplib.o socklib.o ./.libs/libmxresolv.a -lssl -lpthread -lpam ./.libs/libmxresolv.a(mxresolver.o): In function `mx_lookup': undefined reference to `__ns_initparse' undefined reference to `__ns_parserr' undefined reference to `__ns_name_uncompress' Cheers, Ralf
Re: Incorrect information in the manual about the tar-v7 option
On 2008-09-17 22:45:15 +0200, Ralf Wildenhues wrote: * Vincent Lefevre wrote on Wed, Sep 17, 2008 at 06:09:43PM CEST: Shouldn't tar-ustar be the default instead of tar-v7? I'm not an expert on tar implementations and their issues, and what would be a good default nowadays. Help? I Cc:ed a couple of people knowledgeable about tar history, and the automake list. The question how far autotools should cater to limitations of new and open source software like BusyBox is quite a difficult one to answer in general, to me. Should autotools add even more workarounds, or should rather simply BusyBox be fixed? Do added workarounds here remove the incentive to fix the buggy software there? I'd say that old, limited, non-standard formats are likely to be less tested than current ones, thus they are more likely to have problems with new tools. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Re: Question about automatic generation of GPLv3 COPYING file
I will discuss the issue with the Automake maintainer. I have never used Automake myself, so I don't know the issues. One fact I can see is that this is just a matter of defaults, and doesn't stop users from doing whatever they want. Please don't exaggerate. Making Automake have different defaults on different platforms is clearly a bad idea. If you are annoyed about one consistent default, inconsistent defaults would be far more annoying. However, some other change might be an improvement.
