From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7551 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: building musl libc.so with gcc -flto Date: Tue, 28 Apr 2015 23:27:25 -0400 Message-ID: <20150429032725.GT17573@brightrain.aerifal.cx> References: <1429742932-6026-1-git-send-email-armccurdy@gmail.com> <20150423022309.GH6817@brightrain.aerifal.cx> <20150423094520.GA17573@brightrain.aerifal.cx> <20150428002402.GJ17573@brightrain.aerifal.cx> <20150428134453.GM17573@brightrain.aerifal.cx> 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 1430278069 27801 80.91.229.3 (29 Apr 2015 03:27:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Apr 2015 03:27:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7564-gllmg-musl=m.gmane.org@lists.openwall.com Wed Apr 29 05:27:44 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YnIez-0001C1-N0 for gllmg-musl@m.gmane.org; Wed, 29 Apr 2015 05:27:41 +0200 Original-Received: (qmail 17588 invoked by uid 550); 29 Apr 2015 03:27:40 -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 17570 invoked from network); 29 Apr 2015 03:27:39 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7551 Archived-At: On Tue, Apr 28, 2015 at 06:42:13PM -0700, Andre McCurdy wrote: > On Tue, Apr 28, 2015 at 6:44 AM, Rich Felker wrote: > > On Mon, Apr 27, 2015 at 11:23:40PM -0700, Andre McCurdy wrote: > >> On Mon, Apr 27, 2015 at 5:24 PM, Rich Felker wrote: > >> > On Mon, Apr 27, 2015 at 05:16:12PM -0700, Andre McCurdy wrote: > >> >> > OK, it looks like the _dlstart_c symbol got removed before linking the > >> >> > asm. What about selectively compiling this file with -fno-lto via > >> >> > something like this in config.mak: > >> >> > > >> >> > src/ldso/dlstart.lo: CFLAGS += -fno-lto > >> >> > >> >> That works. Should I send a patch? > >> > > >> > Yes, but configure would need to detect support for -fno-lto and add > >> > it appropriately. See what's done for CFLAGS_NOSSP. I suspect the crt > >> > files also need -fno-lto in principle even if they're not currently > >> > breaking for lack of it. > >> > >> Patch sent. > >> > >> I think the crt files might be OK as they are, since the _start_c > >> symbol isn't being hidden? > > > > I think you'll find the exact same thing happens if you use a crt1.o > > produced from crt1.c for static linking with LTO. Note that on i386 > > (and x86_64) we still have a crt1.s which overrides crt1.c; I want to > > remove it at some point. Temporarily removing/renaming it yourself > > will allow you to test what happens with LTO on this file. > > Yes, you're right. The same workaround is needed for crt1.c, so my > original patch is incomplete. > > The next issue, as Khem mentioned, is that AR and RANLIB need to be changed to: > > AR = $(CROSS_COMPILE)gcc-ar > RANLIB = $(CROSS_COMPILE)gcc-ranlib > > Is it safe to use these gcc-xx wrappers in all cases (after having > configure test that the toolchain provides them)? Or should they only > be used with LTO? I have no idea. But why can't a normal archive produced with ar be used for LTO? Inability to use standard toolchain components/build scripts sounds like a fairly big problem for LTO deployability. > Beyond that I'm not able to statically link a hello.c test app using > LTO yet, since LTO linking with .a archives requires the gold linker > and I specifically have that disabled (to avoid issues I had seen > previously with musl+gold+dynamic linking). It looks like I need to > enable gold again before continuing. Are there any known issues, or > known success stories, when using musl with gold? I would actually love to see new reports on gold with musl dynamic linking. The new dynamic linker bootstrap design should be a lot more robust against poor choices by the linker, but there could be stupid details that are breaking still which might call for fixes on musl's side. If you have citations for the problems that previously existed with musl+gold, it would be nice to see those again too just to make sure the issues were properly taken care of and not just swept under a rug. Rich