archive of archives

[nick clifton]

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... :-)

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.