Hi
I can't find a help mailing list so here is my message on the dev one.
I built llvm/clang SVN trunk without any problem under my Linux box. But building libc++ is not so easy. I try
1. Run lib/buildit
It ends up with a:
+ case $TRIPLE in
+ clang algorithm.o bind.o chrono.o condition_variable.o debug.o exception.o future.o hash.o ios.o iostream.o locale.o memory.o mutex.o new.o random.o regex.o stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o utility.o valarray.o -fPIC -o libc++.so.1.0 -shared -nodefaultlibs -Wl,-soname,libc++.so.1 -lpthread -lrt -lc -lstdc++ -std=c++0x -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wnewline-eof -Wpadded -Wmissing-prototypes -Wstrict-aliasing=2 -Wstrict-overflow=4
/usr/bin/ld: cannot find crtbeginS.o: No such file or directory
clang-3: error: linker command failed with exit code 1 (use -v to see invocation)
2. Put libcxx within llvm/tools
Like must be done for clang. It has no effect when building llvm.
3. Use cmake
I have created a build-libcxx folder next to ibcxx and call
cmake ../libcxx
from it. The result is:
-- Looking for __gcc_personality_v0 in gcc_s
-- Looking for __gcc_personality_v0 in gcc_s - found
CMake Error at lib/CMakeLists.txt:34 (add_dependencies):
add_dependencies called with incorrect number of arguments
-- Found PythonInterp: /usr/bin/python2.7
-- Configuring incomplete, errors occurred!
So I am stuck, can someone help ?
Thank you
François
There is a new one called cfe-users which is just getting going.
John
Francois,
The latest I know is that libc++ is not ready for prime time on Linux.
Hi,
This is the procedure I'm working on, and which seems to work.
I've had to apply two patches. The Clang patch adds support for the Ubuntu Raring Ringtail (13.04) Alpha release and links libsupc++ when linking with -stdlib=libc++. The libc++ patch avoids forceinline on functions with varargs, as that doesn't actually work.
Some (very) light testing shows that this all works, but it feels rather hackish. You mileage will very likely vary.
Patches attached and basic compilation procedure below. Adjust as needed for your installation.
(My next steps after verifying all of this is to get Clang built as C++11 against libc++).
Michael
clang-toolchains-bits.patch (2.56 KB)
libcxx-locale-linux-inline-varargs.patch (960 Bytes)
I don't know what "prime time" is, but I do agree in some cases it's not production ready.
What I can say in defense of libc++ is that PathScale is using it for our c++11 STL. For us the winning combo is
https://github.com/llvm-mirror/libcxx
https://github.com/pathscale/libcxxrt
https://github.com/pathscale/libunwind
https://github.com/pathscale/compiler-rt
Hi
I can't find a help mailing list so here is my message on the dev one.
I built llvm/clang SVN trunk without any problem under my Linux box. But
building libc++ is not so easy. I try
1. Run lib/buildit
It ends up with a:
+ case $TRIPLE in
+ clang algorithm.o bind.o chrono.o condition_variable.o debug.o exception.o
future.o hash.o ios.o iostream.o locale.o memory.o mutex.o new.o random.o
regex.o stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o
utility.o valarray.o -fPIC -o libc++.so.1.0 -shared -nodefaultlibs
-Wl,-soname,libc++.so.1 -lpthread -lrt -lc -lstdc++ -std=c++0x
-fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wnewline-eof -Wpadded
-Wmissing-prototypes -Wstrict-aliasing=2 -Wstrict-overflow=4
/usr/bin/ld: cannot find crtbeginS.o: No such file or directory
clang-3: error: linker command failed with exit code 1 (use -v to see
invocation)
2. Put libcxx within llvm/tools
Like must be done for clang. It has no effect when building llvm.
3. Use cmake
I have created a build-libcxx folder next to ibcxx and call
cmake ../libcxx
from it. The result is:
-- Looking for __gcc_personality_v0 in gcc_s
-- Looking for __gcc_personality_v0 in gcc_s - found
CMake Error at lib/CMakeLists.txt:34 (add_dependencies):
add_dependencies called with incorrect number of arguments
-- Found PythonInterp: /usr/bin/python2.7
-- Configuring incomplete, errors occurred!
I have a fix for this that I will commit sometime soon. However
currently you can do it via:
1) Configure libc++ with CMAKE_INSTALL_PREFIX=/usr (clang only looks
for libc++ here on Linux)
2) Set LIBCXX_CXX_ABI to libsupc++ and reconfigure.
3) Set LIBCXX_LIBSUPCXX_INCLUDE_PATHS to a ; separated list of paths
to the libsupc++ headers. On my linux machine this is
"usr/include/c++/4.6;/usr/include/c++/4.6/x86_64-linux-gnu"
4) Reconfigure
5) Generate, build, install
I have been using libc++ with clang on Linux for over a year now and
I've only found one bug (that was fixed in less than 24 hours).
- Michael Spencer
Michael Spencer <bigcheesegs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
writes:
[...]
1) Configure libc++ with CMAKE_INSTALL_PREFIX=/usr (clang only looks
for libc++ here on Linux)
2) Set LIBCXX_CXX_ABI to libsupc++ and reconfigure.
3) Set LIBCXX_LIBSUPCXX_INCLUDE_PATHS to a ; separated list of paths
to the libsupc++ headers. On my linux machine this is
"usr/include/c++/4.6;/usr/include/c++/4.6/x86_64-linux-gnu"
4) Reconfigure
5) Generate, build, install
I have been using libc++ with clang on Linux for over a year now and
I've only found one bug (that was fixed in less than 24 hours).
That still crashes if you output to std::cerr, doesn't it? (Presumably
there are other crashes, but that's the one that I noticed first.)
[...]
No, it works fine here (x86-64 Linux Kubuntu 12.10 clang trunk + libc++ trunk).
Also there are updated install docs on http://libcxx.llvm.org/
- Michael Spencer
Michael Spencer <bigcheesegs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
writes:
[...]
That still crashes if you output to std::cerr, doesn't it? (Presumably
there are other crashes, but that's the one that I noticed first.)
No, it works fine here (x86-64 Linux Kubuntu 12.10 clang trunk + libc++ trunk).
Also there are updated install docs on http://libcxx.llvm.org/
OK, with the docs there I can confirm it works fine for me, too. (I
thought I'd done all the right things, but obviously I missed something
out.)
(It ends up linking against libstdc++, whereas (IIRC, anyway) using
libcxxrt does not. So I'm not sure which I prefer. Likely it doesn't
make that much difference either way; primarily I want to be able to
build against another standard library (to try to catch errors), and
either build will work fine for that.)
Linking against libsupc++ currently requires actually linking against
libstdc++ because libsupc++ defines a different set of type info than
libc++ expects. It could be fixed by conditionally adding that type
info to libc++.
You are correct that linking against libcxxrt does not require this.
The intent of the CMake build is to allow linking against both
libcxxabi and libcxxrt, but I have yet to add support for them.
- Michael Spencer
Michael Spencer <bigcheesegs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
writes:
[...]
Linking against libsupc++ currently requires actually linking against
libstdc++ because libsupc++ defines a different set of type info than
libc++ expects. It could be fixed by conditionally adding that type
info to libc++.
By the looks of it libc++ now links against libsupc++, and as you
suggest, that gives undefined symbol errors for some dynamic type info
symbols.
However changing clang so (when linking against libc++) it also links
with -lsupc++ works for me. It seems quite possible that the code I'm
working with doesn't actually use dynamic type information and would
crash if it did, but it does seem to link and work.
I tried linking libc++.so.1.0 wrapping -Wl,--whole-archive and
-Wl,--no-whole-archive around -lsupc++ but that gives duplicate
symbols. (libsupc++ is a static library.)
[...]