[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Libtool issue with ar(1) on 64-bit AIX
From: |
Peter Rosin |
Subject: |
Re: Libtool issue with ar(1) on 64-bit AIX |
Date: |
Wed, 15 Aug 2007 19:51:12 +0200 |
User-agent: |
Mutt/1.5.12-2006-07-14 |
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