8
votes

My question is not the same as this question.

I'm working on a project with a standalone binary that has no dynamic/external linkage, and runs in a *nix environment.

I'm attempting to move to a newer toolset to build with, but some of the static libraries that are available with the older toolset aren't available now -- for example, the crt libraries that provided _start aren't provided in this toolset.

I've been digging through the files provided with the vendor's toolset and found some shared objects with the symbols I needed from the crt libraries (eg, _start, _fini, etc) but I'm unsure whether there's a straightforward way to statically link a shared object into a binary, and further have that binary be executable.

Short version: Can a non-shared-object binary be statically linked with a shared object without the result becoming another shared object?

2
Is your original standalone binary an executable that has been statically linked? Can you maybe give some more details on what you actually have, and what you need to achieve?Kerrek SB
In the original project, with the old toolset, there were a few provided (static) libraries that, when linked in, made it a standalone runnable binary. In the newer toolset, some of those things are missing as static libs, but there are a few shared objects that provide those symbols. Essentially what I'm wondering is, can a shared object be statically linked into a standalone binary.Brian Vandenberg
The definitive answer to that last question is, "No". When you create a shared library, information is irretrievably lost that would be required for static linking.Kerrek SB
If that's the case ... if you wanna write that up, I'll accept that answer, kudos for providing some info on what is lost.Brian Vandenberg

2 Answers

9
votes

There's a fundamental difference between a shared library and a static library. First off, do search this site for previous discussions, and check out this question too (and the answers therein).

Basically, a static library is just a collection of objects, and the linker resolves the symbol names into fixed addresses -- this is required for static linking. On the other hand, a shared library is much more like an independent executable, which is loaded into memory by the loader and has entry point addresses to which the program jumps. However, relocation tables that static libraries have are generally not preserved when a shared library is being linked, so it's in general not possible to extract linkable object code from inside a linked shared library.

5
votes

Yeah, I know this is an 6 year-old question. I was told that it was possible to statically link against a shared-object library, but I've also discovered that it is not.

To actually demonstrate that statically linking a shared-object library is not possible with ld (gcc's linker), use the following gcc command:

gcc -o executablename objectname.o -Wl,-Bstatic -l:libnamespec.so

(Of course you'll have to compile objectname.o from sourcename.c, and you should probably make up your own shared-object library as well. If you do, use -Wl,--library-path,. so that ld can find your library in the local directory.)

The actual error you receive is:

/usr/bin/ld: attempted static link of dynamic object `libnamespec.so'
collect2: error: ld returned 1 exit status

Clearly, attempting to pull the object out of the shared-object library is something about which ld will balk.

There were some suggestions made here, but my interest in this question was merely academic.

Hope that helps.