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

[Markus Wichmann <nullplan@gmx.net>]

On Tue, May 08, 2018 at 02:44:17PM +0200, Thomas Petazzoni wrote:
> /home/thomas/projets/buildroot/output/host/lib/gcc/arm-buildroot-linux-musleabihf/6.4.0/libgcc.a(_dvmd_lnx.o): In function `__aeabi_idiv0':
> /home/thomas/projets/buildroot/output/build/host-gcc-final-6.4.0/build/arm-buildroot-linux-musleabihf/libgcc/../../../libgcc/config/arm/lib1funcs.S:1354: undefined reference to `raise'
[...]
> 
> Does that ring any bell ?
> 

It would appear that your version of libgcc references libc. Now, with
static linking, the libraries must appear in the correct order to
satisfy all dependencies, but here you have a circular dependency between
libgcc and libc. Since all gcc compiled code depends on libgcc, and libc
is compiled with gcc, there are only two ways to break the cycle:

1. Remove the dependency. No idea how, not unless you basically inline
raise() into __aeabi_idiv0().

2. Add libc again after the command line.

I suspect, once spec files have been taken care of, that the linker
command line will be something like

ld -o a.out crt1.o crtbegin.o crti.o $YOUR_PRJ_OFILES crtend.o crtn.o -lc -lgcc

That would need another "-lc" at the end. Patching the specfile should
do it.

Things like this somewhat highlight the uselessness of collect2, don't
you think? I thought fixing things like this is entirely within its
remit, but no, apparently not.

Another distinct possibility is that your gcc is somehow broken, either
through your action or maybe that version isn't good, but I tend to try
and fix the simple problem first. And patching the spec file is simpler
than debugging gcc.

Ciao,
Markus