Compile problems on musl/arm32 since 9.16.8

Ed W lists at wildgooses.com
Sun Jul 18 21:19:45 UTC 2021


Hi, I'm building a gentoo based system on arm v7 32bit, using musl as my libc. I am hitting a
compile error, that I have determined happens on 9.16.9 onwards, yet I can build fine with 9.16.8
and earlier


The specific error snippet I see is:

    armv7a-unknown-linux-musleabihf-gcc -O2 -pipe -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard
    -mno-unaligned-access -DDIG_SIGCHASE -pthread -fPIC -Wl,-O1 -Wl,--as-needed -L/usr/lib
    -Wl,--export-dynamic -o sample-async \
    sample-async.o ../dns/libdns.a      ../isccfg/libisccfg.a ../isc/libisc.a -lcrypto     -luv -ldl
    /usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld:
    ../isc/libisc.a(backtrace.o): in function `btcallback':
    backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
    armv7a-unknown-linux-musleabihf-gcc -O2 -pipe -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard
    -mno-unaligned-access -DDIG_SIGCHASE -pthread -fPIC -Wl,-O1 -Wl,--as-needed -L/usr/lib
    -Wl,--export-dynamic -o resolve \
    resolve.o ../irs/libirs.a ../dns/libdns.a      ../isccfg/libisccfg.a ../isc/libisc.a
    -lcrypto     -luv -ldl
    collect2: error: ld returned 1 exit status
    make[1]: *** [Makefile:494: sample-gai] Error 1
    make[1]: *** Waiting for unfinished jobs....
    /usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld:
    ../isc/libisc.a(backtrace.o): in function `btcallback':
    backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
    collect2: error: ld returned 1 exit status
    make[1]: *** [Makefile:502: sample-request] Error 1
    /usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld:
    ../isc/libisc.a(backtrace.o): in function `btcallback':
    backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
    collect2: error: ld returned 1 exit status
    make[1]: *** [Makefile:490: sample-async] Error 1
    /usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld:
    ../isc/libisc.a(backtrace.o): in function `btcallback':
    backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
    collect2: error: ld returned 1 exit status
    make[1]: *** [Makefile:486: resolve] Error 1


I think this is related to this change here:

    --- /var/tmp/portage/net-dns/bind-tools-9.16.9/work/bind-9.16.9/lib/isc/backtrace.c   
    2020-11-16 14:44:37.000000000 +0000
    +++ /var/tmp/portage/net-dns/bind-tools-9.16.8/work/bind-9.16.8/lib/isc/backtrace.c   
    2020-10-13 08:41:40.000000000 +0000
    @@ -40,7 +40,7 @@
      */
     #ifdef HAVE_LIBCTRACE
     #define BACKTRACE_LIBC
    -#elif defined(HAVE_UNWIND_BACKTRACE)
    +#elif defined(__GNUC__) && (defined(__x86_64__) || defined(__ia64__))
     #define BACKTRACE_GCC
     #elif defined(WIN32)
     #define BACKTRACE_WIN32


If I revert this change then my compile succeeds (although it may not be correct?)


I'm not really skilled enough to understand the details of gcc backtrace implementation on arm. I'm
using gcc 10.3.0 to compile this, and I can see that I have a header:

    /usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/include/unwind.h

So I'm assuming that I have gcc compiled with some kind of unwind implementation?

I use a very similar profile to compile near identical code base for both amd64 and x86
architectures and both of those have no issues compiling latest bind-tools (and previous). Also,
near as I can see I have my gcc configured identically across all three systems...


Now I *can* compile bind-tools ok if I install the libunwind library, however, that then breaks
(re)compiling my gcc compiler, so I'm really thinking that's the wrong route to go down?

Temporarily I'm reverting the above change locally, but I wonder if you could either guide me to a
correct solution, or if someone more knowledgeable can revert or write some correct #if test for
this situation please?


I'm sure I have failed to provide enough details at this stage. Please be gentle...

Thanks

Ed W

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210718/020638b2/attachment.htm>


More information about the bind-users mailing list