* How to build libc.a with -fPIC for all archive members? @ 2014-02-10 12:35 Oliver Schneider 2014-02-10 13:27 ` Oliver Schneider ` (2 more replies) 0 siblings, 3 replies; 5+ messages in thread From: Oliver Schneider @ 2014-02-10 12:35 UTC (permalink / raw) To: musl Hi, 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 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 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? Thanks for any insight into how to resolve this, // Oliver ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: How to build libc.a with -fPIC for all archive members? 2014-02-10 12:35 How to build libc.a with -fPIC for all archive members? Oliver Schneider @ 2014-02-10 13:27 ` Oliver Schneider 2014-02-10 14:04 ` Oliver Schneider 2014-02-10 14:07 ` Szabolcs Nagy 2014-02-10 19:43 ` Rich Felker 2 siblings, 1 reply; 5+ messages in thread From: Oliver Schneider @ 2014-02-10 13:27 UTC (permalink / raw) To: musl So I piped the output of the compilation into a text file and then used "grep -v fPIC" to see only lines that don't contain -fPIC (well fPIC), but that yields a list where the "ar" command and a few auxiliary commands are the only ones left. So it appears all calls to the compiler (I use GCC) pass the -fPIC from the ./configure invocation. Still looking, but if someone has any input, that would be appreciated. // Oliver ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: How to build libc.a with -fPIC for all archive members? 2014-02-10 13:27 ` Oliver Schneider @ 2014-02-10 14:04 ` Oliver Schneider 0 siblings, 0 replies; 5+ messages in thread From: Oliver Schneider @ 2014-02-10 14:04 UTC (permalink / raw) To: musl Okay, so the probable reason is that the assembly code isn't relocatable or not marked as such. Looking into this further. // Oliver ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: How to build libc.a with -fPIC for all archive members? 2014-02-10 12:35 How to build libc.a with -fPIC for all archive members? Oliver Schneider 2014-02-10 13:27 ` Oliver Schneider @ 2014-02-10 14:07 ` Szabolcs Nagy 2014-02-10 19:43 ` Rich Felker 2 siblings, 0 replies; 5+ messages in thread From: Szabolcs Nagy @ 2014-02-10 14:07 UTC (permalink / raw) To: musl * 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) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: How to build libc.a with -fPIC for all archive members? 2014-02-10 12:35 How to build libc.a with -fPIC for all archive members? Oliver Schneider 2014-02-10 13:27 ` Oliver Schneider 2014-02-10 14:07 ` Szabolcs Nagy @ 2014-02-10 19:43 ` Rich Felker 2 siblings, 0 replies; 5+ messages in thread From: Rich Felker @ 2014-02-10 19:43 UTC (permalink / raw) To: musl On Mon, Feb 10, 2014 at 12:35:14PM +0000, Oliver Schneider wrote: > Hi, > > 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 > > 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 > > 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? This is not intended to be possible, and there are many things that would break. Among them: - __libc_start_main would never have been called so some necessary initialization might not have taken place. At present that's minimal and the goal is to keep it minimal so this might have no practical consequence, but it's still something that can't be officially supported without locking in aspects of the implementation. - malloc does not support sharing the brk with anything else, in particular, whatever malloc implementation is using it in the rest of the program outside your DSO. It really _can't_ because there's no way it could synchronize use of the brk (since it wouldn't be sharing locks with the outside program. - Anything that touches threads will either expect the thread pointer to be setup to point to musl's thread structure, or will attempt to set it up. This will conflict with whatever thread structure the outside program/glibc/different-version-of-musl is using. In general, it's only safe to have a single version/copy of any given library linked into a program. There are some exceptions like libgcc that use hidden visibility to make it work, but they're the exception, not the norm. This issue is not unique to libc, but libc probably has the most ways it's affected. With that said, building libc.a as PIC _is_ intended to be supported, not for what you're doing, but for the sake of making static-linked PIE executables. This is not doable with the official gcc toolchain but I have a system to make it work without invasive changes, so I would like to find and fix whatever issue is PIC-incompatible... Rich ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-02-10 19:43 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-02-10 12:35 How to build libc.a with -fPIC for all archive members? Oliver Schneider 2014-02-10 13:27 ` Oliver Schneider 2014-02-10 14:04 ` Oliver Schneider 2014-02-10 14:07 ` Szabolcs Nagy 2014-02-10 19:43 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).