From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8875 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: some odd library loading errors Date: Tue, 17 Nov 2015 10:55:45 -0500 Message-ID: <20151117155545.GZ3818@brightrain.aerifal.cx> References: <20151117121429.GI26951@example.net> <20151117152355.GF18372@port70.net> <20151117152728.GX3818@brightrain.aerifal.cx> <20151117154515.GG18372@port70.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 1447775778 10844 80.91.229.3 (17 Nov 2015 15:56:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 15:56:18 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8888-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 17 16:56:04 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 1Zyibv-0004PE-JL for gllmg-musl@m.gmane.org; Tue, 17 Nov 2015 16:55:59 +0100 Original-Received: (qmail 11341 invoked by uid 550); 17 Nov 2015 15:55:57 -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 11323 invoked from network); 17 Nov 2015 15:55:57 -0000 Content-Disposition: inline In-Reply-To: <20151117154515.GG18372@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8875 Archived-At: On Tue, Nov 17, 2015 at 04:45:16PM +0100, Szabolcs Nagy wrote: > * Rich Felker [2015-11-17 10:27:28 -0500]: > > On Tue, Nov 17, 2015 at 04:23:56PM +0100, Szabolcs Nagy wrote: > > > * u-uy74@aetey.se [2015-11-17 13:14:29 +0100]: > > > > The environment: > > > > Linux 3.# on x#86 > > > > binutils 2.24 > > > > musl 1.1.8 compiled for i486 > > > > gcc 5.2.0 > > > > > > > > (the gcc has arch=i486 as the default) > > > > > > > > No oddities were observed with the above until trying to use libatomic > > > > which is provided by gcc-5.2.0. > > > > > > > > The test case: > > > > > > > > $ cat >a.c <<____ > > > > int main(){ return 0; } > > > > ____ > > > > > > > > $ gcc -o a a.c -L -latomic > > > > > > > > $ LD_LIBRARY_PATH= ./a > > > > Error relocating /libatomic.so.1: __atomic_store_8: symbol not found > > > > Error relocating /libatomic.so.1: __atomic_exchange_8: symbol not found > > > > Error relocating /libatomic.so.1: __atomic_load_8: symbol not found > > > > Error relocating /libatomic.so.1: __atomic_compare_exchange_8: symbol not found > > > > > > > > > > this is a known issue, they use the gnu ifunc extension of > > > elf to dispatch between different implementations based on > > > the machine at library loadtime. > > > > Is there something we need to add to the musl patches to disable this? > > I would like to make sure both that it's going upstream and that I > > have a patch in my toolchain build repo. > > > > i guess --disable-gnu-indirect-function could be the default when > gcc targets musl (assuming musl will not implement ifuncs anytime soon). I think that's a reasonable assumption. Based on what I've seen lately, rather than finding solutions to the problems we knew about already, the rabbit hole keeps going deeper... If you have reason to believe otherwise could you explain how we might reasonably support ifunc? Rich