[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 May 2018 12:34:23 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: undefined reference to `raise' with musl static toolchain
On Tue, May 08, 2018 at 06:22:27PM +0200, Markus Wichmann wrote:
> 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.
gcc already does this if you pass -static. I suspect the issue is that
Thomas is using a toolchain where gcc doesn't know it's
static-linking, and ld only static-links because there's no libc.so
present. This setup is highly fragile and afaik it's not intended by
the gcc developers to work. I don't know if there's anything like
--enable-default-static for gcc but that would be the right solution
for a static-only toolchain I think.
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.
