This is the mail archive of the
binutils@sourceware.org
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 <nickc@redhat.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[1] 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
> f1
> f2
> % 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
happening?
>
> Cheers
> Nick
>
> [1] 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.