dynamic linker dependenciy info embedded in an archive

Question

Dynamic libraries are nice. The have embedded information in then that help the runtime linker figure what other libraries the final executable needs to load. It also tells the executable what symbols will be loaded

Static libraries, however, are a pain in the neck. The linker won't automatically link an archive's dependencies. This get heinous when statically linking a library that is moderately complicated or has a deep dependency graph.

So why can't archives just include their dependency information. I tried to do just that. The key to my idea is /usr/lib/libc.so. This file is not a shared object file but a linker script.

Linker scripts give you a lot of control over the final linker output, but all I want is to specify dependencies which you can with:

INPUT( -ldependency -ldependecy2 )

Here are my questions.

• This seems pretty simple, why hasn't this been done before? I can't be the first person who thought of this. This seems easier and more intuitive than pkg-config or libtool (especially libtool ugh).
• I tried to embed the linker script in the archive, it doesn't work. Why not? Can it be made to work? I suspect some clever use of ranlib might do the trick, but it is beyond me.

My current solution is create a linker script called libMyLibrary.a. It contains

INPUT( -lMyRealLibrary -ldependency1 -ldependency2 )

I have to put in the dependencies by hand, it would be nice if ld could for me, but that is problem for another day.

Answer 1

To answer the second part of your question, ar p ARCHIVE SCRIPT will cat the contents of SCRIPT contained in ARCHIVE. Or ar x ARCHIVE SCRIPT to extract the file and then pass it to the linker like ld blah blah -TSCRIPT.

Answer 2

Linker scripts of this form are supported only by GNU-ld (the new Gold ELF linker has limited support as well). If you have any portability requirements, you better not depend on linker script support.

libtool is written specifically to help with portability in creating shared libraries (details of which vary greatly between platforms).

If you don't need portability, then of course you don't need libtool and its complexity.