From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4467 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: libgcc --disable-shared test case Date: Sat, 11 Jan 2014 17:23:54 -0500 Message-ID: <20140111222354.GW24286@brightrain.aerifal.cx> References: <20131017060913.GA1957@brightrain.aerifal.cx> <1389462032.1176.18@driftwood> <20140111215106.GV24286@brightrain.aerifal.cx> <52D1BFE9.6040703@landley.net> 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 1389479038 17997 80.91.229.3 (11 Jan 2014 22:23:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jan 2014 22:23:58 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4471-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jan 11 23:24:07 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 1W26yM-0000Gf-Pv for gllmg-musl@plane.gmane.org; Sat, 11 Jan 2014 23:24:06 +0100 Original-Received: (qmail 5430 invoked by uid 550); 11 Jan 2014 22:24:06 -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 5422 invoked from network); 11 Jan 2014 22:24:06 -0000 Content-Disposition: inline In-Reply-To: <52D1BFE9.6040703@landley.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4467 Archived-At: On Sat, Jan 11, 2014 at 04:04:25PM -0600, Rob Landley wrote: > >If you could share the two versions of libfoo.so, a.out, and maybe > >even libgcc.a, I can probably figure out what's going on. > > Tarball of the newly built stuff attached, the other stuff should be > at http://landley.net/simple-root-filesystem-i686.tar.bz2 (which > isn't the release version because I made sure this one _wasn't_ > built from a stage 2 cross compiler. This is from an aboriginal > build that didn't do a stage 2 cross compiler, but built everything > with the "simple" cross compiler.) OK, here's my analysis. a.out does not contain __divdi3, which it should, but instead contains an undefined reference to it. libfoo1.so contains a definition for __divdi3, and libfoo2.so does not. So far, this is all exactly how I expected the linking against a broken libgcc.a to manifest. So, why does it "work"? Because your uclibc was also built against this broken libgcc.a, and thus exports __divdi3 and whatever subset of the libgcc symbols *happened* to get used by code in libc. If you replace it with a properly built uclibc libc.so.0 (i.e. one built with a gcc toolchain that was not using --disable-shared), your a.out will definitely stop working. If this weren't troubling enough, it could in principle just stop working as a result of internal changes to uclibc. (This is unlikely with __divdi3, whose use is extremely common, but it could easily happen with the other weird libgcc functions used for dispatching switch statements on long long, floating point to long long conversions, etc.) If you want to see the issue manifest without replacing uclibc, the easiest way would be to check *which* libgcc symbols got pulled into libc.so.0, then modify the test code for libfoo.so to use a feature that will pull in one of the libgcc symbols not in libc. Rich