Summary: | sys-libs/libcxx-3.8.1[libunwind] on x86 - undefined reference to `__divdi3' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bertrand Jacquin <bertrand> |
Component: | Current packages | Assignee: | Alexis Ballier <aballier> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | bertrand, bsd+disabled, geraint0923, mgorny, nigoro.dev, StormByte, unhappy-ending |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
emerge --info build.log zzlei's 3.9.0 ebuild Patch for current in tree libcxx-6.0.1.ebuild Cleaned and working ebuild Fix compiler-rt arch detection Patch for fixing compiler-rt detection and linkage |
Description
Bertrand Jacquin
2016-08-28 15:13:36 UTC
Created attachment 444338 [details]
build.log
Created attachment 444340 [details]
emerge --info
Created attachment 445554 [details]
build.log
same here
When USE=libunwind is set, this problem occurs. undefined reference to `__divdi3' will be solved by set -lgcc_s on x86. $ grep gcc_s *.ebuild libcxx-3.8.0.ebuild: export LIBS="-lpthread -lrt -lc -lgcc_s" libcxx-3.8.1.ebuild: export LIBS="-lpthread -lrt -lc -l$(usex libunwind unwind gcc_s)" Developers can be reproduced easily. Chrooting x86 stage3. mkdir -p /etc/portage/package.{keywords,use} echo "=sys-libs/libcxx-3.8.1 ~x86" >> /etc/portage/package.keywords/llvm echo "=sys-libs/libcxxrt-0.0_p20150423-r1 ~x86" >> /etc/portage/package.keywords/llvm USE="static-libs libunwind" emerge -a libcxx Created attachment 447836 [details]
zzlei's 3.9.0 ebuild
Lei Zhang's ebuild for libcxx-3.9.1 compiles fine with llvm-libunwind and abi_x86_32. He has one for libcxx-3.8.1 but I have not tested it. I did test his libcxx-3.8.1-r1 libcxxabi based ebuild, which also compiled fine using llvm-libunwind and abi_x86_32 flags enabled.
Confirmed. __divdi3 is the emulation of some x86_64 instruction on a x86 platform, implemented in libgcc. I didn't test libcxx-3.8.1 on x86 and never noticed this problem. The intent of linking libcxx against libunwind is to make it libgcc free, so adding -lgcc_s back is not a good idea. I don't have a better solution for this ATM, other than using compiler-rt to replace libgcc. To do that, simply using clang with option -rtlib=compiler-rt to rebuild libcxx. As a side note, if you build libcxx against libunwind, I guess you just intend to get rid of dependence on libgcc(In reply to Timothy from comment #5) > Created attachment 447836 [details] > zzlei's 3.9.0 ebuild > > Lei Zhang's ebuild for libcxx-3.9.1 compiles fine with llvm-libunwind and > abi_x86_32. He has one for libcxx-3.8.1 but I have not tested it. I did test > his libcxx-3.8.1-r1 libcxxabi based ebuild, which also compiled fine using > llvm-libunwind and abi_x86_32 flags enabled. I did nothing special with the ebuild for libcxx-3.9.0. I guess this issue just happened to be fixed upstream. (In reply to Lei Zhang from comment #7) > > Lei Zhang's ebuild for libcxx-3.9.1 compiles fine with llvm-libunwind and > > abi_x86_32. He has one for libcxx-3.8.1 but I have not tested it. I did test > > his libcxx-3.8.1-r1 libcxxabi based ebuild, which also compiled fine using > > llvm-libunwind and abi_x86_32 flags enabled. > I did nothing special with the ebuild for libcxx-3.9.0. I guess this issue > just happened to be fixed upstream. However, -9999 fails again. And we can expect more failures since those calls are generated by the compiler. That said, -rtlib=compiler-rt does not fix this. And I have no clue how to pass in compiler-rt libraries explicitly. So it's either removing -nodefaultlibs (didn't we have a flag to just skip C++ libraries? or maybe we could try to link using the C compiler?) or -Wl,-z,defs and relying on the final executable to provide the runtime. Happens also in sys-libs/libcxx-6.0.1 Clang has a switch for detecting compiler-rt library in use, which is -print-libgcc-file-name Current 6.0.1 (tested ebuild) produces duplicated results and it leads to misslinking with the mentioning undefined references. I attach a patch to 6.0.1 ebuild which fixes this issue by using correct compiler-rt arguments for linking. Created attachment 542782 [details, diff]
Patch for current in tree libcxx-6.0.1.ebuild
This patch uses -print-libgcc-file-name for detecting compiler-rt library for linking
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b375c11c5cf0467364ff8f217f6de6cc49551d92 commit b375c11c5cf0467364ff8f217f6de6cc49551d92 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2018-08-09 10:31:54 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-08-09 10:31:54 +0000 sys-libs/libcxx: Use -print-libgcc-file-name to get clang_rt path Suggested-by: David Carlos Manuelda Bug: https://bugs.gentoo.org/592326 sys-libs/libcxx/libcxx-5.0.2.ebuild | 16 ++++++---------- sys-libs/libcxx/libcxx-6.0.1.ebuild | 16 ++++++---------- sys-libs/libcxx/libcxx-6.0.9999.ebuild | 16 ++++++---------- sys-libs/libcxx/libcxx-7.0.9999.ebuild | 16 ++++++---------- sys-libs/libcxx/libcxx-9999.ebuild | 16 ++++++---------- 5 files changed, 30 insertions(+), 50 deletions(-) Thanks for the reminder. I've changed the behavior of -print-libgcc-file-name upstream to eventually improve this and make CMake automatically use the correct library. However, the original patch met resistance, and I forgot about it. That said, I've fixed all the syntax mistakes in your patch (including missynced variable names), removed obsolete comment and applied it to all versions 5.0.2+. However, it doesn't fix the issue completely since the libraries are prepended too early on the command-line. I need to figure out a better way of injecting them. I've retried the testing in version 7.0.0, and still fails, I realized that moving rt static library from the start of the command to the end of the command will work, like this (manual test): && /usr/lib/llvm/7/bin/clang++ -m32 -fPIC -march=native -O2 -pipe -lunwind -Wl,-O1 -Wl,--as-needed -Wl,--sort-common -s -Wl,-z,defs -fPIC -nodefaultlibs -shared -Wl,-soname,libc++.so.1 -o lib32/libc++.so.1.0 lib/CMakeFiles/cxx_objects.dir/__/src/algorithm.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/any.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/bind.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/charconv.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/chrono.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/condition_variable.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/debug.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/exception.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/functional.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/future.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/hash.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/ios.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/iostream.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/locale.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/memory.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/mutex.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/new.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/optional.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/random.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/regex.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/shared_mutex.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/stdexcept.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/string.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/strstream.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/system_error.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/thread.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/typeinfo.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/utility.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/valarray.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/variant.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/vector.cpp.o -Wl,-rpath,"\$ORIGIN/../lib64:/usr/lib64/llvm/7/lib64" -lc++abi -lpthread -lc -lm -lrt /usr/lib64/llvm/7/bin/../../../../lib/clang/7.0.0/lib/linux/libclang_rt.builtins-i386.a && : But I have no clue about how to change that parameter order from the ebuild. Yes, that's what I meant in my comment ;-). @Michał Górny I investigated this issue further and (at least in version 7.0.0), I found a fix that I think is better than current suggestions: * want_gcc_s is no longer used as CMAKE_VARIABLE (spotted as a warning) * LIBCXX_USE_COMPILER_RT is a variable substituting the want_gcc_s behavior * patched HandleCompilerRT.cmake to use 32 and 64 bit accordingly * Cleaned ebuild I am attaching the files for testing, but in my testcase it just compiled and lined correctly, Can you take a look to improve it and/or to push it to our tree as a temp fix for the problem? Thanks Created attachment 553224 [details]
Cleaned and working ebuild
Created attachment 553226 [details, diff]
Fix compiler-rt arch detection
Could you make this into git format-patch, and add a Signed-off-by? (In reply to Michał Górny from comment #19) > Could you make this into git format-patch, and add a Signed-off-by? Yes, give me a second :D Created attachment 553228 [details, diff]
Patch for fixing compiler-rt detection and linkage
(In reply to Michał Górny from comment #19) > Could you make this into git format-patch, and add a Signed-off-by? Please tell me if something is missing, never did a Signed-off by, if missing please could you tell how to add it? Thanks :) This should have been fixed by https://github.com/gentoo/gentoo/commit/708fe7d2e647a6cf6257e04ed6c99639a1444e18 since libcxx-9.0.0. |