Hi, sys-libs/libcxx-3.8.1 fail to build on x86: i686-pc-linux-gnu-g++ -fPIC -nodefaultlibs -march=native -O2 -pipe -fomit-frame-pointer -std=c++11 -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wpadded -Wstrict-aliasing=2 -Wstrict-overflow=4 -Wl,-O1 -Wl,--as-needed -Wl,-z,defs -shared -Wl,-soname,libc++.so.1 -o libc++.so.1.0 algorithm.So optional.So random.So new.So locale.So thread.So future.So regex.So strstream.So string.So shared_mutex.So mutex.So exception.So iostream.So any.So typeinfo.So ios.So bind.So condition_variable.So stdexcept.So valarray.So system_error.So utility.So memory.So hash.So chrono.So debug.So -lcxxrt -lpthread -lrt -lc -lunwind thread.So: In function `std::__1::this_thread::sleep_for(std::__1::chrono::duration<long long, std::__1::ratio<1ll, 1000000000ll> > const&)': thread.cpp:(.text+0x1c0): undefined reference to `__divdi3' condition_variable.So: In function `std::__1::condition_variable::__do_timed_wait(std::__1::unique_lock<std::__1::mutex>&, std::__1::chrono::time_point<std::__1::chrono::system_clock, std::__1::chrono::duration<long long, std::__1::ratio<1ll, 1000000000ll> > >)': condition_variable.cpp:(.text+0x10c): undefined reference to `__divdi3' chrono.So: In function `std::__1::chrono::system_clock::to_time_t(std::__1::chrono::time_point<std::__1::chrono::system_clock, std::__1::chrono::duration<long long, std::__1::ratio<1ll, 1000000ll> > > const&)': chrono.cpp:(.text+0xa0): undefined reference to `__divdi3' collect2: error: ld returned 1 exit status make: *** [Makefile:30: libc++.so.1.0] Error 1 * ERROR: sys-libs/libcxx-3.8.1::gentoo failed (compile phase): * emake failed Full log and emerge --info attached
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.
