This is the mail archive of the
mailing list for the binutils project.
Re: archive of archives
- From: NightStrike <nightstrike at gmail dot com>
- To: nick clifton <nickc at redhat dot com>
- Cc: Cary Coutant <ccoutant at google dot com>, Binutils <binutils at sourceware dot org>
- Date: Tue, 30 Apr 2013 07:06:03 -1000
- Subject: Re: archive of archives
- References: <CAF1jjLtCm9Nuua4hytxsvgE1tSnypLUan=R1L6o0BCNjSd437g at mail dot gmail dot com> <CAHACq4qM+2ZziXdncX-VZibHmJ6NArR0fg9yAFy=jFQTN1Z8uw at mail dot gmail dot com> <CAF1jjLv3-9-tvQh0z-=FzjfGFVm4HywFT3DKm19qGA1ZUfWUXQ at mail dot gmail dot com> <CAF1jjLuqcgvWOuo6j_iX_CGjkSZBJJKDwS4prKVX=NH-3e=tQw at mail dot gmail dot com> <517FD619 dot 7020304 at redhat dot com>
On Tue, Apr 30, 2013 at 10:32 AM, nick clifton <email@example.com> wrote:
> Hi NightStrike,
>>>>> $ x86_64-w64-mingw32-ar cru liba.a libb.a
>>>>> $ x86_64-w64-mingw32-ranlib liba.a
>>>>> The resulting liba.a doesn't work too well:
>>>>> $ x86_64-w64-mingw32-nm liba.a
>>>>> x86_64-w64-mingw32-nm: liba.a: File format not recognized
>>>> No, it's not supposed to work.
>> We use an MRI linker script to combine 3 libX.a files into a single
>> libZ.a file. It seems to work.
> This is because you can put any file you like into an archive, including
> other archives. BUT - you cannot construct a symbol index for this sort of
> nested archive and it will not be recognised by other tools that are
> expecting an archive consisting solely of object files.
> For example:
> % echo "first" > f1
> % echo "second" > f2
> % ar cr libfoo.a f1 f2
> You can print and extract files from this non-object-file archive:
> % ar t libfoo.a
> % mv f1 f1.saved
> % ar x libfoo.a f1
> % cmp f1 f1.saved
> But try to run a binary tool on it and:
> % nm libfoo.a
> nm: f1: File format not recognized
> nm: f2: File format not recognized
>> Based on what you are saying, are we
>> doing something that will not be supported in the future?
> I know of no plans to add support for this kind of feature. If you want to
> merge multiple libraries into a single big library, either make the new
> library a thin library or else extract and add the contents of each input
> library one by one. This is free software however, so if you feel the need,
> please do create a patch to handle nested archives and submit it for
> review... :-)
What I was trying to express in this email was that I found a method
that does in fact work. The MRI script that I mentioned produces a
library that other tools, like nm or dlltool --identify can handle.
And in fact, even ld likes it.
Is it possible that the MRI script that I provided does what you
suggest -- unpacks each library and adds the original objects into the
new library, effectively flattening it? That makes naming conflicts
an issue, but should otherwise be effective. Is that what is
>  Actually you can use the 's' option to ar or run ranlib, and it will
> appear to work, but nothing will happen. No symbol table will be
> constructed. This could be considered to be a bug.