Summary: | sys-libs/llvm-libunwind-18.1.0_rc2: /usr/lib64/libc++abi.so.1: undefined symbol: __deregister_frame_info | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jonas Rakebrandt <xarblu> |
Component: | Current packages | Assignee: | LLVM support project <llvm> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | parona, xarblu |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
See Also: | https://github.com/llvm/llvm-project/issues/83080 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 830404 | ||
Attachments: | build.log |
Description
Jonas Rakebrandt
2024-02-20 00:40:55 UTC
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. |