ben:~/development/test$ cat abi.cpp
#include <cxxabi.h>
int main() {}
ben:~/development/test$ clang++-3.4 -stdlib=libc++ abi.cpp
ben:~/development/test$ clang++-3.5 -stdlib=libc++ abi.cpp
abi.cpp:1:10: fatal error: 'cxxabi.h' file not found
#include <cxxabi.h>
^
1 error generated.
clang-3.5.0-rc2 is trying to use the libc++ from its binary_directory/../include/c++/v1 but there doesn't seem to be a libc++ being built anywhere, and there doesn't seem to be an abi layer in use.
Does anybody know if ./llvm.src/utils/release/test-release.sh is supposed to build a working libc++? I thought I read recently that libc++abi was made the default when building libc++ in-tree, but perhaps that's for clang-3.6.
What's the intended behaviour? Is this a problem for the release? Should I be building or installing a libc++ separately? (I do, but it doesn't get picked up)
When I build libc++ from trunk against libc++abi, cxxabi.h is installed into include/c++/v1/
I feel this would be much better if test-release would build libc++ against libc++abi and produce shared libraries and put them in the lib dir.
At least then:
clang++ -stdlib=libc++ file.cpp
would have a chance of working, instead of being stuck with libstdc++.
Ben
I've had more luck with cmake, I've used this hack with trunk:
Well, again with Clang-3.6, the nightlies run fine*, I run them like this:
CXXFLAGS="-stdlib=libc++" LDFLAGS="-lc++ -lc++abi" sandbox/bin/lnt runtest --submit perfdb nt --sandbox sandbox --cc trunk/build/release/Phase3/install/bin/clang --test-suite llvm-test-suite
This builds the tests with libc++ and libc++abi.
Since the LDFLAGS are prepended instead of appended, I have to specify -lc++ before -lc++abi.
I'm yet to backport or fudge the cmake build for Clang-3.5.
I'm currently thinking of adding
-enable-libcpp Use libc++ if available. [default: disable]
-use-cmake Use cmake build system instead of make.
To test-release.sh
* Regressions are thus:
FAIL: MultiSource/Applications/kimwitu++/kc.compile_time (1 of 992)
FAIL: MultiSource/Benchmarks/Prolangs-C++/city/city.compile_time (2 of 992)
FAIL: MultiSource/Benchmarks/Prolangs-C++/deriv1/deriv1.compile_time (3 of 992)
FAIL: MultiSource/Benchmarks/Prolangs-C++/deriv2/deriv2.compile_time (4 of 992)
FAIL: MultiSource/Benchmarks/Prolangs-C++/employ/employ.compile_time (5 of 992)
FAIL: MultiSource/Benchmarks/Prolangs-C++/office/office.compile_time (6 of 992)
FAIL: MultiSource/Benchmarks/Prolangs-C++/shapes/shapes.compile_time (7 of 992)
FAIL: MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4.compile_time (8 of 992)
FAIL: MultiSource/Applications/kimwitu++/kc.execution_time (497 of 992)
FAIL: MultiSource/Benchmarks/MiBench/telecomm-CRC32/telecomm-CRC32.execution_time (498 of 992)
FAIL: MultiSource/Benchmarks/Prolangs-C++/city/city.execution_time (499 of 992)
FAIL: MultiSource/Benchmarks/Prolangs-C++/deriv1/deriv1.execution_time (500 of 992)
FAIL: MultiSource/Benchmarks/Prolangs-C++/deriv2/deriv2.execution_time (501 of 992)
FAIL: MultiSource/Benchmarks/Prolangs-C++/employ/employ.execution_time (502 of 992)
FAIL: MultiSource/Benchmarks/Prolangs-C++/office/office.execution_time (503 of 992)
FAIL: MultiSource/Benchmarks/Prolangs-C++/shapes/shapes.execution_time (504 of 992)
FAIL: MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4.execution_time (505 of 992)
Ben
Hi Ben,
I can't really help you, since I'm not yet at the stage where I care
much about libc++ on ARM Linux, since I'm still fighting with
compiler-rt and CMake builds on buildbots, but I will very soon care
about it very seriously.
I'd love to see such flags to test-release, and others that would make
sure compiler-rt is properly compiled (using CMake) and put on the
right path, and that libc++abi (which is required for unwinding) is
correctly placed on a lib dir.
For compiler-rt I had to fudge Clang to also add libgcc_s and
libgcc_eh for now, but if we also have libc++abi we really can't be
adding them. That's not done and will probably break. Could this be
what's giving you trouble?
Anyway, keep me in the loop of your CMake/libc++ adventures, as I'll
be checking it soon.
cheers,
--renato
Hi Ben,
libc++abi only has a cmake build system at this point (and lib/buildit, but I like to pretend that doesn’t exist), so it won’t work with the ./configure build system (which test-release.sh uses). In addition, any changes to the libc++ build system have been happening only in cmake (the makefile in there is apple specific).
I didn’t actually know test-release.sh existed before you started sending mail about it, but if I had to guess I’d say it isn’t used on Linux (not with libc++, anyway).
Adapting test-release.sh to be able to use cmake is probably the right way to go.
It is used for most release testing, but I don't think people use it
for libc++ on Linux (I don't, on ARM).
I'd love to, though.
Also, Ben, remember that, if we build and test it, it'd be good to
make sure it gets installed and goes on the final tar ball
(Phase3/llvmCore-M.m-install), but not if we don't build it.
cheers,
--renato