[cfe-dev] -static-libstdc++ & libc++abi
Mike Aizatsky via cfe-dev
cfe-dev at lists.llvm.org
Fri Nov 18 12:56:14 PST 2016
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.
On Fri, Nov 18, 2016 at 12:11 PM Eric Fiselier <eric at efcs.ca> wrote:
> 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
>
> On Thu, Nov 17, 2016 at 9:35 PM, Mike Aizatsky <aizatsky at google.com>
> wrote:
>
> 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 832a07c9d566c5aad19e1ba5c3c924d8d384499f) (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.
>
> "/usr/bin/ld" -z relro --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/lib/gcc/x86_64-linux-gn
> u/5.4.0/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/5.4.0/crtbe
> gin.o -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0 -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/
> usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../.. -L/usr/local/bin/../lib -L/lib -L/usr/lib /tmp/test-fa0ac9.o -lc++ -lm -lgcc_s
> -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/5.4.0/crtend.o /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../x86_64-linux-gnu/crtn.o
> /usr/local/bin/../lib/libc++.a(ios.cpp.o): In function `std::__1::iostream_category()':
> ios.cpp:(.text._ZNSt3__117iostream_categoryEv+0x24): undefined reference to `__cxa_guard_acquire'
> ios.cpp:(.text._ZNSt3__117iostream_categoryEv+0x34): undefined reference to `__cxa_guard_release'
> /usr/local/bin/../lib/libc++.a(ios.cpp.o): In function `std::__1::ios_base::clear(unsigned int)':
> ios.cpp:(.text._ZNSt3__18ios_base5clearEj+0x48): undefined reference to `__cxa_allocate_exception'
> ios.cpp:(.text._ZNSt3__18ios_base5clearEj+0x84): undefined reference to `__cxa_throw'
> ios.cpp:(.text._ZNSt3__18ios_base5clearEj+0x94): undefined reference to `__cxa_free_exception'
>
>
>
>
> On Thu, Nov 17, 2016 at 8:00 PM Eric Fiselier <eric at efcs.ca> wrote:
>
> On Thu, Nov 17, 2016 at 5:20 PM, Mike Aizatsky via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> 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
> <http://libcxx.llvm.org/docs/BuildingLibcxx.html#cmdoption-arg-LIBCXX_ENABLE_STATIC_ABI_LIBRARY>
> .
> Alternatively you can define libc++.a as a linker script just like
> libc++.so. (Ex INPUT(libc++static.a -lc++abi))
>
> /Eric
>
>
>
>
> --
> Mike
> Sent from phone
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> --
> Mike
> Sent from phone
>
>
> --
Mike
Sent from phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161118/b55fbe47/attachment.html>
More information about the cfe-dev
mailing list