Re: undefined reference to `raise' with musl static toolchain

[Rich Felker <dalias@libc.org>]

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