Hello!
I’ve recently encountered a bug (https://llvm.org/bugs/show_bug.cgi?id=30919) and I would like an advice on how to approach it.
It seems that right now libc++abi is not handled by Tools.cpp. Normal linking works because:
$ cat ~/out/llvm/default/lib/libc++.so
INPUT(libc++.so.1 -lc++abi)
And if I use -static-libstdc++ then c++abi is not automatically linked in at all.
Is there a similar magic for .a files like for .so? Should Tools.cpp know about lc++abi? Are there any alternatives?
Hello!
I've recently encountered a bug (https://llvm.org/bugs/show_
bug.cgi?id=30919) and I would like an advice on how to approach it.It seems that right now libc++abi is not handled by Tools.cpp. Normal
linking works because:$ cat ~/out/llvm/default/lib/libc++.so
INPUT(libc++.so.1 -lc++abi)And if I use -static-libstdc++ then c++abi is not automatically linked in
at all.Is there a similar magic for .a files like for .so? Should Tools.cpp know
about lc++abi? Are there any alternatives?
First, Tools.cpp shouldn't know about libc++abi/libsupc++/libcxxrt or w/e
C++ ABI library your STL is using.
There are two alternatives to your problem. If you want to use a static
libc++abi you can build libc++ with LIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON
<Building libc++ — libc++ documentation;
.
Alternatively you can define libc++.a as a linker script just like
libc++.so. (Ex INPUT(libc++static.a -lc++abi))
/Eric
Eric,
I initially started from configuration using “-DLIBCXX_ENABLE_SHARED=OFF -DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON”. Clang built with this configuration can not produce binaries at all (see below). Clang with just “-DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON” fails the same way when I use “-static-libstdc++”
clang++ -std=c++11 -stdlib=libc++ -v test.cc
clang version 4.0.0 ([http://llvm.org/git/clang.git](http://llvm.org/git/clang.git) 832a07c9d566c5aad19e1ba5c3c924d8d384499f) ([http://llvm.org/git/llvm.git](http://llvm.org/git/llvm.git) fde9b8bfc220c589f9103b3919d1
07cd3e944cc6)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/usr/local/bin/clang-4.0" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main
-file-name test.cc -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -f
use-init-array -target-cpu x86-64 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir /usr/local/bin/../lib/clang/4.0.0 -internal-isystem /usr/loc
al/bin/../include/c++/v1 -internal-isystem /usr/local/include -internal-isystem /usr/local/bin/../lib/clang/4.0.0/include -internal-externc-isystem /us
r/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-
dir / -ferror-limit 19 -fmessage-length 151 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o /tmp/test-fa0ac9.o -x c++ tes
t.cc
clang -cc1 version 4.0.0 based upon LLVM 4.0.0svn default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/bin/../include/c++/v1
/usr/local/include
/usr/local/bin/../lib/clang/4.0.0/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
test.cc:10:5: warning: expression result unused [-Wunused-value]
dynamic_cast<B*>(v); // well-defined: v of type V*, V base of B, results in B*
^~~~~~~~~~~~~~~~~~~
test.cc:11:5: warning: expression result unused [-Wunused-value]
dynamic_cast<B*>(a); // undefined behavior: a has type A*, A not a base of B
^~~~~~~~~~~~~~~~~~~
2 warnings generated.
I had adding support for static linker scripts somewhere in my TODO.
However, I'm not sure if I will proceed with it anytime soon since
touching anything linking-related turns out being a huge can of worms,
and Eric ends up having to fix my mistakes ;-).
I initially started from configuration using “-DLIBCXX_ENABLE_SHARED=OFF -DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON”. Clang built with this configuration can not produce binaries at all (see below). Clang with just “-DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON” fails the same way when I use “-static-libstdc++”
Ah my mistake. LIBCXX_ENABLE_STATIC_ABI_LIBRARY only works when building a shared libc++ with a static libc++abi. It doesn’t actually combine libc++ and libc++abi archives if they are both static. I guess I need to fix that, or at least document it. It is possible to merge two static archives into one, but
/Eric
Hi Mike,
I think i fixed LIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON. I added a merge_archives.py utility to libc++ and changed LIBCXX_ENABLE_STATIC_ABI_LIBRARY to merge the ABI library into libc++.a.
Could you confirm that this fixes the issue?
/Eric
Yes, this fixes my issue and works splendidly with -DLIBCXX_ENABLE_SHARED=OFF -DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON. Thanks a lot. Closing the issue.