Re: Second (non-fPIC) pass messages being suppressed on failure
On Thu, Nov 22, 2007 at 08:19:56AM +0100, Ralf Wildenhues wrote: +AT_DATA([nopicfail.c], +[[ +#ifndef PIC +choke me +#endif +int ans = 42; +]]) + +AT_DATA([picfail.c], +[[ +#ifndef PIC +choke me +#endif +int ans = 42; +]]) Shouldn't one of them (the latter?) be #ifdef PIC? Cheers, Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: ar(1) issue building coreutils on 64-bit AIX
On Fri, Aug 17, 2007 at 08:56:38PM +0200, Ralf Wildenhues wrote: Hello Eric, * Eric Blake wrote on Fri, Aug 17, 2007 at 05:33:31AM CEST: We ought to be consistent across all of the autotools. I personally prefer ARFLAGS over AR_FLAGS, since it is CFLAGS and not C_FLAGS. Yes, if the variable in question fulfills the same semantics. Here, it definitely does not: Automake uses already ARFLAGS = cru albeit as Makefile macro; but distinguishing between that and environment variables can only lead to trouble. So we cannot really change without breaking backward compatibility. So AR_FLAGS would come as a natural second choice for flags to ar that are independent of the action to be taken. But really autotools have always usesd the scheme that program variables may contain options, so AR='ar -X32_64' seems like the most natural choice to me. (Of course, AR_FLAGS should still be used consistently.) Just pointing out that for libtool the archiver is never invoked as either of: $AR $AR_FLAGS cru ... $AR $AR_FLAGS x ... $AR $AR_FLAGS t ... it is always one of these instead: $AR $AR_FLAGS ... $AR x ... $AR t ... That usage of $AR_FLAGS seems consistent with your description of $ARFLAGS in automake. Cheers, Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Libtool issue with ar(1) on 64-bit AIX
On Wed, Aug 15, 2007 at 01:14:58PM -0400, Daniel Richard G. wrote: I have a software project that builds using Libtool 1.5.24. At one point, it produces a gigantic static archive library, that is composed of several smaller static convenience libraries. Libtool extracts each of the smaller libraries, and assembles the object files into a new archive library, using ar(1) on both counts. Libtool parameterizes the ar(1) invocation to create a new library, in the AR and AR_FLAGS variables. On 64-bit AIX, AR_FLAGS has to be set to -X64 cru, as ar(1) only accepts 32-bit objects by default. This much works fine. The problem occurs when Libtool extracts the smaller libraries: it uses $AR x /path/to/libfoo.a (in the func_extract_an_archive() function). The command _name_ is parameterized, but not the _flags_---it uses x unconditionally. On this system, if you don't pass in the -X64 flag, ar(1) thinks that you want to extract only the 32-bit objects in the archive. If you're doing a 64-bit build, there of course won't be any. The end result being that what was supposed to be a gigantic static archive library ends up completely empty, save for the archive file header. The flags passed to ar(1) in the extraction step need to be parameterized. 64-bit AIX is a scenario where ar x alone doesn't work. This issue is (by accident) solved by the lib-as-archiver patch [1] in the MSVC series. But that is for head, so it doesn't apply cleanly to the problem at hand... Cheers, Peter [1] http://lists.gnu.org/archive/html/libtool-patches/2007-07/msg00036.html ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
