From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8088 Path: news.gmane.org!not-for-mail From: Laurent Bercot Newsgroups: gmane.linux.lib.musl.general Subject: Re: Error relocating libc.so: (...): symbol not found Date: Thu, 02 Jul 2015 19:49:52 +0200 Message-ID: <559579C0.2020107@skarnet.org> References: <559563E7.6080804@skarnet.org> <20150702165431.GH1173@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1435859405 3329 80.91.229.3 (2 Jul 2015 17:50:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jul 2015 17:50:05 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8101-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 02 19:50:00 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 1ZAicZ-0007eB-2R for gllmg-musl@m.gmane.org; Thu, 02 Jul 2015 19:49:59 +0200 Original-Received: (qmail 21728 invoked by uid 550); 2 Jul 2015 17:49: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 21710 invoked from network); 2 Jul 2015 17:49:57 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <20150702165431.GH1173@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:8088 Archived-At: On 02/07/2015 18:54, Rich Felker wrote: > It sounds like a broken libc.so. There should not be dynamic symbol > references or definitions for libgcc symbols in libc.so. Is it > possible that your toolchain is doing something wacky that links > shared libgcc even when we try to do static libgcc? It's very likely, since I'm manually tinkering with musl-gcc.specs to make it work with the Aboriginal Linux toolchain (which normally uses a gcc wrapper to enforce the use of uClibc). I didn't think about it because my setup works flawlessly for application compilation. I suspect my defeat-the-wrappers shenanigans do not play nicely with compiling musl itself. I'll investigate in that direction. Thanks, -- Laurent