Date: Fri, 11 May 2018 12:05:44 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: undefined reference to `raise' with musl static toolchain 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.