Linking a shared library against a static library: must the static library be compiled differently than if an application were linking it?

Question

At least on Linux and Solaris, static libraries are really just a bunch of compiled .o's tossed into one big file. When compiling a static library, usually the -fpic flag is ommited, so the generated code is position dependent.

Now say my static library is B. I've built it and have the resulting .a file which is really just a glob of all of the position dependent .o files. Now I have a shared library I'd like to build, A, and I want it to statically link B. When I build A, naturally I'll use the -fpic flag to make the generated code position independent. But if I link against B, aren't I mixing position dependent and position independent object files?

I'm getting a lot of text relocation errors unless I also specify -mimpure-text, and I think this maybe the cause. It seems when I compile a library, I really need to compile it 3 times, a shared version, a static version, and a static-that-can-be-used-by-shared-libs version. Am I right? I could just keep using -mimpure-text but the g++ man page says that if you do that the object doesn't actually end up being shared (it's unclear if it's all unshared or just the statically linked parts though, does anyone know?).

Stigmasterol

The question is stated correctly, he 'omits' -fpic in the first paragraph, leading to position-dependent code, then uses it in the second paragraph, leading to position-independent code. – Sustentacular

Answer 1

You do not have to use PIC code in shared objects (as you have discovered you can use the -mimpure-text option to allow that).

That said, non-PIC code in shared objects are more heavyweight. With PIC code, the text pages in memory are just direct memory mappings of the text pages on disk. This means that if multiple processes are using the shared object, they can share the memory page.

But if you do not have PIC code, when the runtime linker loads the shared object, it will have to apply fixups to the text pages. This means that every processes that uses the shared object will have it's own unique version of any text page that has a fixup on it (even if the shared object is loaded at the same address as copy-on-write only notices that the page was modified and not that it was modified in the same way).

To me, the important issue is whether you will simultaneously have multiple processes running that each load the shared object. If you do, it is definitely worth making sure all the code within the SO is PIC.

But if that is not the case and only a single process has the shared object loaded, it's not nearly as critical.

Stome

Actually, if you know only one process is going to load it, can't it be a performance benefit to compile without pic? Because of saving a register. – Stigmasterol

@JosephGarvin PIC consumes a register in 32 bit x86 code, but not in 64 bit code. The x64 instruction set supports program counter relative addressing - load data that is NNNN bytes offset from the memory address of the (next instruction following the) currently executing instruction. PIC code in x64 requires no GOT pointer register. – Ursula

Answer 2

I do the following in the link stage for the shared object library version of a static library: g++ -shared -o libshared.so -Wl,--whole-archive -fPIC -lstatic -Wl,--no-whole-archive. Since --whole-archive links every object in a (list of) static libs (of the form libstatic.a) I believe preceding that (list) with -fPIC is all the OP need do.

Abshier

Answer 3

As an alternative approach, ship two libraries: your shared one and the static you're linking against alongside. They should link into the final executable correctly.

Fulminate