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

[Kevin Enderby]

> On Jul 9, 2015, at 12:27 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
>>> My idea was to always pad the name with nulls so that we have members
>>> that are 8 byte aligned and we never modify files put in the archive.
>> 
>> That get the member to start on an 8-byte boundary, but its size is not a multiple of 8 bytes you still have to deal with that.  Again the only way I could think of dealing with this is to change the member size.  If objects always have sizes that are 8-byte multiples it never matters.  If not it makes a mess of things.   That is why we use libtool(1) to create “static libraries” and not ar(1) to create “archive files”.  As we have stricter rules on “static libraries” including no non-object files allowed in them, sized to 8 byte multiples, warns if there are no symbols in the table of contents, etc.
> 
> I am not sure I follow what is the problem with files that are not a
> multiple of 8 bytes.

My goal was to start each archive header on an 8-byte alignment.  But I see what you are saying.  Since the archive header contains only fields of chars it can start on any alignment and then you can make up the lack of the end of the alignment of the previous member with the string name of the next member.

> Lets say we are in the middle of creating an
> archive and we just got a file (foo) that is 5 bytes long. What we
> will have is
> 
> * Stuff before foo.
> * Start of the member header for foo:
>   #1/......
>  This starts at a 2 byte aligned offset.
> * Name of foo ("foo") with nulls added at the end.
> * Start of foo itself. This will be aligned to 8 by the nulls on the name.
> * A single '\n' to align to 2 bytes.
> * Start of the member header for the next file. This starts at a 2
> byte aligned offset.
> 
> I just missed llvm.org going down, but with the attached patch it
> looks like we can bootstrap using llvm-ar+/usr/bin/true instead of
> ar+ranlib.

Nice.

> 
>>> I will also be adding support for thin archives.
>> 
>> 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.

> 
> Cheers,
> Rafael
> <t.patch>