Re: How to build libc.a with -fPIC for all archive members?

[Szabolcs Nagy <nsz@port70.net>]

* Oliver Schneider <musl-mailinglist@f-prot.com> [2014-02-10 12:35:14 +0000]:
> how can I build the static library from the musl source, but compiling
> with -fPIC?
> 
> I tried the obvious:
> 
> CFLAGS=-fPIC ./configure --enable-gcc-wrapper --disable-shared

this should work

> and then built. But I am getting the following linker error still
> (albeit for a different member function and object file than before):
> 
> /usr/local/musl/lib/libc.a(memmove.o): relocation R_X86_64_PC32 against
> symbol `memcpy' can not be used when making a shared object; recompile
> with -fPIC
> final link failed: Bad value

i think you miss -Bsymbolic-functions linker flags when you link the .so

this avoids relocations of all .so internal function calls

(which should be always on when building any library unless you explicitly
document that a sepecific function may be hijacked (interposed) through
ldpreloading otherwise the mismatch between the library internal and
library external abi can break semantics)

> The reason I want to do this, is to have a statically linked .so. I.e.
> an .so that has no external dependency other than the system calls. Or
> is this known to conflict with the ever-present glibc in some way?

how would you use that? somehow it will need to be loaded but
the loader must not interfere with the static linked libc

or would you use the .so as the loader?

(klibc does something like that: they put all libc code in a .so, they don't
use -fPIC because they load the .so at fixed address and all binaries that
are dynlinked to it are compiled against a fixed .so that has its sha1 checksum
in its name, that way you can have something that looks like dynamic linking
but actually it's more like a set of split static binaries that happens to
share one half of their code that contains all of libc)