From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1633 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Building without -Wl,-Bsymbolic-functions Date: Sat, 18 Aug 2012 15:40:35 -0400 Message-ID: <20120818194035.GY27715@brightrain.aerifal.cx> References: <20120818121418.GX27715@brightrain.aerifal.cx> <2774.50.0.229.11.1345306054.squirrel@lavabit.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 1345318766 2361 80.91.229.3 (18 Aug 2012 19:39:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Aug 2012 19:39:26 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1634-gllmg-musl=m.gmane.org@lists.openwall.com Sat Aug 18 21:39:25 2012 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 1T2ori-0007k5-4u for gllmg-musl@plane.gmane.org; Sat, 18 Aug 2012 21:39:22 +0200 Original-Received: (qmail 32408 invoked by uid 550); 18 Aug 2012 19:39:19 -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 32400 invoked from network); 18 Aug 2012 19:39:19 -0000 Content-Disposition: inline In-Reply-To: <2774.50.0.229.11.1345306054.squirrel@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1633 Archived-At: On Sat, Aug 18, 2012 at 12:07:34PM -0400, idunham@lavabit.com wrote: > > On Sat, Aug 18, 2012 at 01:38:23PM +0200, Jens wrote: > >> > >> Hi! > >> > >> Im building musl inside an oldish uclibc environment based on uclibc > >> 0.9.30.1, gcc 4.1.2 and GNU ld version 2.17. > >> > >> The linker does not accept -Bsymbolic-functions. > >> > >> Im now building the shared library despite of this. > >> > >> How broken will the musl libc be without -Bsymbolic-functions ? > > > > If building without it entirely, the shared libc will just crash. > > > > If replacing it with -Bsymbolic, it will run, but global variables in > > libc that are accessed by the application (e.g. environ, optind, ...) > > will actually have separate copies in libc and the application, and > > thus the app won't work as expected. > Last I checked, ISTR it was "Illegal instruction" or segfault (even for > hello world); I forget which was which, but both did not work at all. The first function call in __dynlink will jump to an invalid address, yielding SIGILL or bogus behavior if the address is valid and SIGSEGV if it's not. It might be possible to include a hack to avoid this problem by putting __asm__ (".hidden funcname"); at file scope in dynlink.c for each function that might be used by the dynamic linker, but if any of those functions in turn depend on other functions, it won't be sufficient. I see it as a fairly fragile hack, and I'd rather not go there; requiring -Bsymbolic-functions ensures that everything will work. > > A patch to add -Bsymbolic-functions to old binutils would be very > > welcome... In the mean time, you could compile a new ld and pass the > > -B option to gcc to give it the path for the new ld. > The patch isn't trivial to get right, but 2.17.50 (20070703) is a > significant improvement in many other ways (a few code generation fixes > among them)... > I've built a tarball, but not really posted it publicly (tarballs in git > is really nasty 8-)* ). > > Interestingly, -B is not needed if you just put the desired version first > in your path. (I found that out trying 2.17/2.17.50 on an Ubuntu host > Isaac Dunham Whether this works probably depends on how gcc is configured. For example cross compilers will never get ld, etc. from the path; they'll always use their configured directories. Rich