On a full LLVM system (incl. libc++) llvm-libunwind-18.1.0_rc2 breaks *everything* linked against libc++ at runtime. Not entirely sure why this happens because there is no such issue with 17.0.6. As far as I understand __deregister_frame_info is an external function from libc so maybe there's a linking issue somewhere. Reproducible: Always Steps to Reproduce: I tested builds with an ENV of *FLAGS="-O2 -march=native -pipe" with both a known working LLVM 17.0.6 stack and a full 18.1.0_rc2 stack. (LD_PRELOAD was used because fully merging the package breaks *everything* using libc++ for me which makes recovery *very* annoying if you don't have a working binpkg or snapshot.) 1. ebuild /var/db/repos/gentoo/sys-libs/llvm-libunwind/llvm-libunwind-18.1.0_rc2.ebuild clean install 2. LD_PRELOAD=/var/tmp/portage/sys-libs/llvm-libunwind-18.1.0_rc2/image/usr/lib64/libunwind.so.1.0 clang --version Actual Results: clang: symbol lookup error: /usr/lib64/libc++abi.so.1: undefined symbol: __deregister_frame_info Expected Results: Normal clang --version output Running toolchain as selected by "default/linux/amd64/17.1/systemd/clang/merged-usr" profile. I will provide the build log in an attachment. I will skip emerge --info for now as all (interesting) flags are changed by the aforementioned package.env anyways.
Created attachment 885478 [details] build.log
This is a symbol that the libc should have. I have a llvm-18 machine and I havent encountered this issue. $ objdump -T --demangle /lib/libc.so.6 | grep __deregister_frame_info 0016db70 g DF .text 0000013d GCC_3.0 __deregister_frame_info_bases 0016dcb0 g DF .text 00000005 GLIBC_2.0 __deregister_frame_info ================================================================= Package Settings ================================================================= sys-devel/clang-common-18.1.0_rc2::gentoo was built with the following: USE="(default-compiler-rt) (default-libcxx) (default-lld) hardened (llvm-libunwind) -bootstrap-prefix -verify-sig" ABI_X86="(64)" sys-libs/llvm-libunwind-18.1.0_rc2::gentoo was built with the following: USE="(clang) debug static-libs -test -verify-sig" ABI_X86="32 (64) (-x32)" CFLAGS="-O2 -pipe -ggdb3" CXXFLAGS="-O2 -pipe -ggdb3" FEATURES="binpkg-docompress qa-unresolved-soname-deps ebuild-locks splitdebug userfetch binpkg-logs pid-sandbox preserve-libs split-elog network-sandbox protect-owned sfperms warn-on-large-env unmerge-orphans usersync parallel-fetch binpkg-multi-instance binpkg-dostrip pkgdir-index-trusted strict news assume-digests buildpkg-live compress-build-logs distlocks xattr userpriv usersandbox candy split-log unmerge-logs config-protect-if-modified merge-sync strict-keepdir sandbox fixlafiles parallel-install multilib-strict clean-logs unknown-features-warn ipc-sandbox compressdebug" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -ggdb3" sys-libs/libcxx-18.1.0_rc2::gentoo was built with the following: USE="(clang) (libcxxabi) static-libs -test -verify-sig" ABI_X86="32 (64) (-x32)" CFLAGS="-O2 -pipe -ggdb3" CXXFLAGS="-O2 -pipe -ggdb3" FEATURES="binpkg-docompress qa-unresolved-soname-deps ebuild-locks splitdebug userfetch binpkg-logs pid-sandbox preserve-libs split-elog network-sandbox protect-owned sfperms warn-on-large-env unmerge-orphans usersync parallel-fetch binpkg-multi-instance binpkg-dostrip pkgdir-index-trusted strict news assume-digests buildpkg-live compress-build-logs distlocks xattr userpriv usersandbox candy split-log unmerge-logs config-protect-if-modified merge-sync strict-keepdir sandbox fixlafiles parallel-install multilib-strict clean-logs unknown-features-warn ipc-sandbox compressdebug" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -ggdb3" sys-libs/libcxxabi-18.1.0_rc2::gentoo was built with the following: USE="(clang) static-libs -test -verify-sig" ABI_X86="32 (64) (-x32)" CFLAGS="-O2 -pipe -ggdb3" CXXFLAGS="-O2 -pipe -ggdb3" FEATURES="binpkg-docompress qa-unresolved-soname-deps ebuild-locks splitdebug userfetch binpkg-logs pid-sandbox preserve-libs split-elog network-sandbox protect-owned sfperms warn-on-large-env unmerge-orphans usersync parallel-fetch binpkg-multi-instance binpkg-dostrip pkgdir-index-trusted strict news assume-digests buildpkg-live compress-build-logs distlocks xattr userpriv usersandbox candy split-log unmerge-logs config-protect-if-modified merge-sync strict-keepdir sandbox fixlafiles parallel-install multilib-strict clean-logs unknown-features-warn ipc-sandbox compressdebug" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -ggdb3"
(In reply to Alfred Wingate from comment #2) > I have a llvm-18 machine and I havent encountered this issue. Hm, weird. I can consistently reproduce this issue on 2 different machines. > $ objdump -T --demangle /lib/libc.so.6 | grep __deregister_frame_info > 0016db70 g DF .text 0000013d GCC_3.0 __deregister_frame_info_bases > 0016dcb0 g DF .text 00000005 GLIBC_2.0 __deregister_frame_info For me this returns: 001734d0 g DF .text 00000150 GCC_3.0 __deregister_frame_info_bases 00173620 g DF .text 00000005 GLIBC_2.0 __deregister_frame_info ...which should be fine (?). Not entirely sure how to interpret the different numbers. I'm assuming they're just memory offsets to where the symbols are in the .so. A little more info on what versions are broken for me: - 16.0.6 (just for experimenting) same as 17.0.6 - 17.0.6 works no matter what flags I give clang (within reason of course) - 18.1.0_rc2 is broken, even with very basic (-O2 -pipe) or no flags at all - 19.0.0_pre20240218 (just for experimenting) same as 18.1.0_rc2 The fact that I can rebuild <=17.0.6 any way I want and it works as expected leads me to believe that it's not an issue with my toolchain/glibc and rather something introduced from 17 to 18.
Did a little more testing and the whole thing works when also preloading libgcc_s. Tested the same way as previously but with libgcc_s this time: LD_PRELOAD=/usr/lib/gcc/x86_64-pc-linux-gnu/13/libgcc_s.so.1:/var/tmp/portage/sys-libs/llvm-libunwind-18.1.0_rc3/image/usr/lib64/libunwind.so.1.0 clang --version Does that mean ld.so just doesn't load / libunwind.so.1.0 doesn't set all needed libraries?
Finally tracked this whole thing down to https://github.com/llvm/llvm-project/commit/5eb44df1b64dbd1a86b099128092a7fd2001c0ba Building llvm-libunwind with MYCMAKEARGS="-DLIBUNWIND_ENABLE_FRAME_APIS=ON" makes all the symbols found. Not sure if this should just be set unconditionally as the commit itself says: > Default this to on, so as not to remove the apis from > environments that already have them. ...and then has the actual default set to OFF. Maybe I'm just misunderstanding the commit message but could be bug.
I haven't looked at it in detail, but given you're hitting a problem that is related to the commit, and the inconsistency b/t commit msg + what it does, I think it's fine if you file a bug upstream & CC the author/reviewer. Normally I'd just comment on the review for something like this first but it was on Phab which is now archived.
Created an upstream issue here: https://github.com/llvm/llvm-project/issues/83080
Thanks!
Turned out to be mold issue fixed in https://github.com/rui314/mold/commit/50bdf39ba57e29386de28bd0c303035e626fa29c Marking this as resolved upstream.
