Re: Second (non-fPIC) pass messages being suppressed on failure

2007-11-22 Thread Peter Rosin
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

2007-08-17 Thread Peter Rosin
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

2007-08-15 Thread Peter Rosin
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