Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 592326 - sys-libs/libcxx-3.8.1[libunwind] on x86 - undefined reference to `__divdi3'
Summary: sys-libs/libcxx-3.8.1[libunwind] on x86 - undefined reference to `__divdi3'
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Alexis Ballier
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-28 15:13 UTC by Bertrand Jacquin
Modified: 2019-11-27 23:08 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,27.56 KB, text/x-log)
2016-08-28 15:14 UTC, Bertrand Jacquin
Details
emerge --info (info.log,15.26 KB, text/x-log)
2016-08-28 15:14 UTC, Bertrand Jacquin
Details
build.log (sys-libs:libcxx-3.8.1:20160913-002621.log,27.21 KB, text/x-log)
2016-09-13 00:38 UTC, Timothy
Details
zzlei's 3.9.0 ebuild (libcxx-3.9.0.ebuild,5.63 KB, text/plain)
2016-09-25 09:47 UTC, Timothy
Details
Patch for current in tree libcxx-6.0.1.ebuild (ebuild-6.0.1.patch,685 bytes, patch)
2018-08-08 16:43 UTC, David Carlos Manuelda
Details | Diff
Cleaned and working ebuild (libcxx-7.0.0.ebuild,6.70 KB, text/plain)
2018-10-26 19:24 UTC, David Carlos Manuelda
Details
Fix compiler-rt arch detection (fix-compiler-rt-detection.patch,667 bytes, patch)
2018-10-26 19:25 UTC, David Carlos Manuelda
Details | Diff
Patch for fixing compiler-rt detection and linkage (0001-Fix-compiler-rt-detection-and-linkage-as-of-bug-5923.patch,3.07 KB, patch)
2018-10-26 19:41 UTC, David Carlos Manuelda
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bertrand Jacquin 2016-08-28 15:13:36 UTC
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
Comment 1 Bertrand Jacquin 2016-08-28 15:14:30 UTC
Created attachment 444338 [details]
build.log
Comment 2 Bertrand Jacquin 2016-08-28 15:14:47 UTC
Created attachment 444340 [details]
emerge --info
Comment 3 Timothy 2016-09-13 00:38:38 UTC
Created attachment 445554 [details]
build.log

same here
Comment 4 Yuta SATOH 2016-09-16 10:04:09 UTC
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
Comment 5 Timothy 2016-09-25 09:47:52 UTC
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.
Comment 6 zhanglei.april 2016-09-27 02:41:30 UTC
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.
Comment 7 zhanglei.april 2016-09-27 02:49:10 UTC
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.
Comment 8 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-10-06 13:50:13 UTC
(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.
Comment 9 David Carlos Manuelda 2018-08-08 15:44:06 UTC
Happens also in sys-libs/libcxx-6.0.1
Comment 10 David Carlos Manuelda 2018-08-08 16:43:01 UTC
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.
Comment 11 David Carlos Manuelda 2018-08-08 16:43:56 UTC
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
Comment 12 Larry the Git Cow gentoo-dev 2018-08-09 10:32:39 UTC
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(-)
Comment 13 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-08-09 11:50:37 UTC
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.
Comment 14 David Carlos Manuelda 2018-10-26 12:57:50 UTC
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.
Comment 15 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-10-26 13:02:41 UTC
Yes, that's what I meant in my comment ;-).
Comment 16 David Carlos Manuelda 2018-10-26 19:23:55 UTC
@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
Comment 17 David Carlos Manuelda 2018-10-26 19:24:51 UTC
Created attachment 553224 [details]
Cleaned and working ebuild
Comment 18 David Carlos Manuelda 2018-10-26 19:25:30 UTC
Created attachment 553226 [details, diff]
Fix compiler-rt arch detection
Comment 19 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-10-26 19:30:53 UTC
Could you make this into git format-patch, and add a Signed-off-by?
Comment 20 David Carlos Manuelda 2018-10-26 19:31:46 UTC
(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
Comment 21 David Carlos Manuelda 2018-10-26 19:41:05 UTC
Created attachment 553228 [details, diff]
Patch for fixing compiler-rt detection and linkage
Comment 22 David Carlos Manuelda 2018-10-26 19:43:18 UTC
(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 :)
Comment 23 Yang Yang 2019-11-27 23:08:41 UTC
This should have been fixed by https://github.com/gentoo/gentoo/commit/708fe7d2e647a6cf6257e04ed6c99639a1444e18 since libcxx-9.0.0.