From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12822 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: undefined reference to `raise' with musl static toolchain Date: Fri, 11 May 2018 12:05:44 -0400 Message-ID: <20180511160544.GT1392@brightrain.aerifal.cx> References: <20180508144417.216cefa5@windsurf.home> <20180508162226.GA30163@voyager> <20180508163423.GM1392@brightrain.aerifal.cx> <20180509112932.1a3176b0@windsurf.home> <20180509154407.1164eb41@windsurf.home> <20180509152437.GY4418@port70.net> <20180511175901.7f17085a@windsurf.home> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1526054632 15135 195.159.176.226 (11 May 2018 16:03:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 11 May 2018 16:03:52 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12838-gllmg-musl=m.gmane.org@lists.openwall.com Fri May 11 18:03:48 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fHAWK-0003qO-FN for gllmg-musl@m.gmane.org; Fri, 11 May 2018 18:03:48 +0200 Original-Received: (qmail 23736 invoked by uid 550); 11 May 2018 16:05:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 23718 invoked from network); 11 May 2018 16:05:56 -0000 Content-Disposition: inline In-Reply-To: <20180511175901.7f17085a@windsurf.home> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12822 Archived-At: On Fri, May 11, 2018 at 05:59:01PM +0200, Thomas Petazzoni wrote: > Hello, > > Thanks for your feedback. > > On Wed, 9 May 2018 17:24:37 +0200, Szabolcs Nagy wrote: > > > there can be many reasons.. > > > > e.g. if mktime in uclibc-ng happens to reference raise then it > > would get linked in independently of libgcc. > > In the static binary linked against uClibc, there are two references to > __GI_raise: > > __GI_abort > __aeabi_idiv0 > > __GI_abort is reference from _start, so I guess this means that > __GI_abort is always pulled in, therefore __GI_raise is always pulled > in, and __aeabi_idiv0 is happy. > > Now my question remains: do you consider it normal that -static is > required, or do you consider it a bug of the musl/gcc integration that > -static is required even when the only variant available of the library > is the static one ? I don't think gcc is intended to work right in configurations where it supports dynamic linking but the only libc available is static, unless you pass -static, and I don't see a good way to make it work in that case. You've only hit the tip of the iceberg; there's more stuff that could break subtly when gcc is passing ld options that were intended for dynamic linking, but ld actually ends up performing static linking. It "working" with uClibc is just "getting lucky" (or "unlucky" depending on your perspective about ignoring vs catching unsafe things). If gcc doesn't have any option to tell it you're building a static-only toolchain and make static linking the default, I see that as something of an omission, and maybe we should try to get that added to gcc. Rich