From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4566 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: How to build libc.a with -fPIC for all archive members? Date: Mon, 10 Feb 2014 14:43:34 -0500 Message-ID: <20140210194334.GU15627@brightrain.aerifal.cx> 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 1392061422 21780 80.91.229.3 (10 Feb 2014 19:43:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Feb 2014 19:43:42 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4570-gllmg-musl=m.gmane.org@lists.openwall.com Mon Feb 10 20:43:50 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 1WCwlg-0004dy-Qy for gllmg-musl@plane.gmane.org; Mon, 10 Feb 2014 20:43:48 +0100 Original-Received: (qmail 28460 invoked by uid 550); 10 Feb 2014 19:43:47 -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 28449 invoked from network); 10 Feb 2014 19:43:46 -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:4566 Archived-At: 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