From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4565 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: How to build libc.a with -fPIC for all archive members? Date: Mon, 10 Feb 2014 15:07:21 +0100 Message-ID: <20140210140721.GK1685@port70.net> References: <52F8C782.4060308@f-prot.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1392041245 23486 80.91.229.3 (10 Feb 2014 14:07:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Feb 2014 14:07:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4569-gllmg-musl=m.gmane.org@lists.openwall.com Mon Feb 10 15:07:33 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WCrWH-0001LI-Ez for gllmg-musl@plane.gmane.org; Mon, 10 Feb 2014 15:07:33 +0100 Original-Received: (qmail 1354 invoked by uid 550); 10 Feb 2014 14:07:32 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1346 invoked from network); 10 Feb 2014 14:07:32 -0000 Content-Disposition: inline In-Reply-To: <52F8C782.4060308@f-prot.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4565 Archived-At: * Oliver Schneider [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)