emerge sys-devel/gcc-14.2.0 fails with this error: /usr/lib/gcc/armv7a-unknown-linux-musleabihf/14/../../../../armv7a-unknown-linux-musleabihf/bin/ld: ../libbacktrace/.libs/libbacktrace.a(backtrace.o): in function `unwind': backtrace.c:(.text+0x1c): undefined reference to `_Unwind_GetIP' collect2: error: ld returned 1 exit status Thank you. Reproducible: Always
Created attachment 899274 [details] emerge --info
Please include gcc-build-logs.tar.xz.
Created attachment 899275 [details] build log
I did more tests: - emerge sys-devel/gcc:13 fails with the same error - after installing gcc:13 binpkg and activating it in eselect gcc, emerge sys-devel/gcc:14 fails with the same error. I don't know if it's important or not, but I'm using kernel v6.10 from github/torvalds and linux-headers v6.9 from portage. I couldn't find a guide how to install headers from an external kernel source. Running make headers_install in the kernel source dir made a mess in /usr/include.
(In reply to Marius Dinu from comment #4) > Running make headers_install in the kernel source dir made a mess in /usr/include. Yeah, definitely DO NOT run make headers_install. I've seen this error before but I can't remember what my conclusion was...
Adelie does https://git.adelielinux.org/adelie/packages/-/blob/93cf7fc8b05fe3003b6f16b766622544cdf3830b/system/gcc/206-arm-unwind-functionise.patch but I'd like to better understand when it's needed and why.
The original reason we made the _Unwind_{Get,Set}IP macros into functions in the Adélie toolchain was to solve a build error in BIND with GCC 8.5.0 on armv7: https://git.adelielinux.org/adelie/packages/-/issues/866 This is because libgcc_s provides those functions, via libgcc/unwind-dw2.c, on every platform - except Arm! Arm systems get the implementation at libgcc/config/arm/unwind-arm.c. The upstream issue (not filed by us) was originally https://gitlab.isc.org/isc-projects/bind9/-/issues/2828 and they just gave up and went with --disable-backtrace. The Ada bits of that patch is because the first gnat1 would break since it is (correctly) assuming that those functions won't exist on Arm and therefore isn't linking to the object on Arm in stage1. By using the #defines, stage1 can build without that undeclared dependency, and then stage2 builds against the normal _Unwind_Foo symbols since it pulls in all of libgcc_s. This is only necessary because musl doesn't have its own backtrace stuff and relies on GCC's built-in one, afaik. Never seen GCC need this patch itself, but then we've had this patch since GCC 8, so I guess I wouldn't have. Still, the 32-bit Arm stuff I've done *outside* of Adélie hasn't run into this particular issue either, but I can't say I regularly test 32-bit Arm with bleeding-edge GCC of which 14 only recently stopped being.
