Using "ar" to combine .o and .a files (Linux)

Question

I'm trying to create a single static library which contains object files and existing static libraries which have all been compiled earlier in the build process. Is there an easy way to do this using "ar", or will I need to unpack (ar x library_name) each library and add its object files to my unified library?

Depalma

If you control the build process, this pattern seems like a clean solution: https://mcmap.net/q/664556/-ar-on-an-existing-a-file – Khz

You need to deal with the case where two .a files both contain the file foo.o. With two different .a files, that's fine - the name of the .o is unimportant, only it's contents matter. If you blindly merge those two .a files, though, you'll end up with only one foo.o. – Stet

Answer 1

If you want to create a shared library you can use this:

You can use the --whole-archive flag from ld:

--whole-archive
For each archive mentioned on the command line after the --whole-archive option, include every object file in the archive in the link, rather than searching the archive for the required object files. This is normally used to turn an archive file into a shared library, forcing every object to be included in the resulting shared library. This option may be used more than once.

Two notes when using this option from gcc: First, gcc doesn't know about this option, so you have to use -Wl,-whole-archive. Second, don't forget to use -Wl,-no-whole-archive after your list of archives, because gcc will add its own list of archives to your link and you may not want this flag to affect those as well.

For static libraries you may have to extract the objects first.

I found the following for ar

gnu ar can optionally create a thin archive, which contains a symbol index and references to the original copies of the member files of the archives. Such an archive is useful for building libraries for use within a local build, where the relocatable objects are expected to remain available, and copying the contents of each object would only waste time and space. Thin archives are also flattened, so that adding one or more archives to a thin archive will add the elements of the nested archive individually. The paths to the elements of the archive are stored relative to the archive itself.

Maybe you can use such a thin archive.

Fetlock

The thin archive option is a (relatively) recent one. It is not available on Fedora 8 for instance (ar 2.17.50). – Draw

+1 by the way for an interesting option (--whole-archive) that just saved my life ! – Draw

I just found this when trying to solve this exact problem, and I can confirm that adding "-T" to "ar" for a thin archive worked for me! – Draggletailed

Answer 2

Archiving the archives is always possible . I didnot test if it works when the actual API is being called from the implementation.

Ex: ar rc lib1.a obj1.o ar rc lib2.a obj2.o ar rc lib3.a lib1.a lib2.a

 you can check the contents of lib3.a by trying out.

   ar x lib3.a which would extract lib1.a and lib2.a

But you need to build calling the API from obj1.o and obj2.o. Then there is no need to extract the object files from individual archives.

Hope it helps!

Embellishment

Answer 3

You will need to extract the object files from the other libraries and bundle the extracted object files into your composite library.

Also consider incremental loading: ld -r

Reimpression

Answer 4

I'm not sure if it has any side effects, but the following command works fine for me.

ar -r libExisting.a objectFile1.o objectFile2.o

It adds the given object files into an existing archive file. My ar version is 2.34.

Mutant