[llvm] r241721 - Start adding support for writing archives in BSD format.

[Kevin Enderby]

> On Jul 9, 2015, at 2:19 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
>>>> Not sure what "thin archives” are but I’ll watch for the diffs an help in any way I can.
>>> 
>>> The idea is that they have just the index. The users (liker mostly)
>>> will fetch the members from the original files. This reduces IO during
>>> a build.
>> 
>> OK, just never heard of such a thing.  In the darwin world we often use the terms “fat” and “thin” referring to a “universal file (fat file)” with likely one or more architecture “slices” vs a non-universal file (not a fat file) for one architecture.
> 
> Yes, the term is confusing. BTW, how is a fat archive represented?

The correct representation of anything fat is that there should be an offset and a size into the file that are the same exact bytes as it it was not fat.  So a proper fat static library is a fat file with archives for each architecture.

Which is of course a problem in a traditional UNIX world where one simply adds flags like “-arch x86_64 -arch i386” to one’s CCFLAGS in a Makefile so things get built like:

cc -c -arch x86_64 -arch i386 foo.c
cc -c -arch x86_64 -arch i386 bar.c
ar crS libfoobar.a foo.o bar.o

So at the step above the file libfoobar.a is an archive with fat .o files (note the use of S to not create a symbol table).

With the darwin tools the next traditional UNIX step would be:

ranlib libfoobar.a

which does the magic of talking apart the archive and the fat .o files and building two archives with symbol tables for each and placing them in a fat file.

The thinking some 20 years ago is we wanted to be sure a “make clean” and a “make all” would generally work in this case.  Cases where ar(1) was used to replace individual .o files in a fat file when possibly presented with a new .o file to replace that did not have the same number of architectures was deemed too hard to define the semantics.

So we moved to the darwin libtool(1) that takes any .o files, archives, fat files and builds the proper static library only from scratch every time.  That is there is no ar(1) functionality like replacing an archive member etc. after the library is built.


> One complete .a for each architecture?

Yes.

> If so I guess someday we might see a fat thin archive :-)

Yes, in with the definition of a "thin archive” only containing a symbol table, aka table of contents.  Where each architecture slice contains a different “thin archive”.  Maybe a term of “stub archive” could be used to not over load the word “thin archive” in this case?

> 
> Another question, why is "__.SYMDEF SORTED" not supported when multiple object files define the same symbol?

Because of the old UNIX ld(1) semantics of searching archives for symbols when they encountered in the link line from each archive in the order of their table of contents.  If there are no duplicate symbols in the objects in an archive then the order of the table of contents does not mater, and we can sort the symbols.  If there are, to get the exact old semantics one must produce the table of contents in archive member order.  These semantics go back to the version 7 UNIX and BSD 4.2 days when I started writing linkers.  Today lots of these static archive semantics don’t apply in the world of dynamic libraries.

> 
> Thanks,
> Rafael