|
Message-ID: <20180508162226.GA30163@voyager> Date: Tue, 8 May 2018 18:22:27 +0200 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Subject: Re: undefined reference to `raise' with musl static toolchain 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
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.