This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: archive of archives


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]