How to use llvm toolchain on Linux always by default - c++

I'm trying to build linux docker image, that will use clang and llvm libs (compiler-rt, libunwind, libc++, ...) for build always by default. I've seen this question, but it uses CMake variables. I want to not have to make any edits to the projects themselves, so that llvm is always used by default. How can I achieve this?

You have to build llvm with special flags (full info):
-DLIBCXX_USE_COMPILER_RT=YES # compiler-rt in libc++
-DLIBCXXABI_USE_LLVM_UNWINDER=YES # libunwind in libc++
-DCLANG_DEFAULT_CXX_STDLIB=libc++ # libc++ as std lib in clang by default
-DCLANG_DEFAULT_RTLIB=compiler-rt # compiler-rt in clang by default
And update cc/c++ links:
update-alternatives --install /usr/bin/cc cc /usr/bin/clang 800 \
--slave /usr/bin/c++ c++ /usr/bin/clang++

Related

How to force clang to use some library by default?

I build clang by clang against libc++, libc++abi, compiler-rt in the following steps:
To download (and update) llvm and sub-projects I use the following script:
svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
cd llvm/tools
svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
svn co http://llvm.org/svn/llvm-project/clang-tools-extra/trunk clang/tools/extra
svn co http://llvm.org/svn/llvm-project/lldb/trunk lldb
svn co http://llvm.org/svn/llvm-project/lld/trunk lld
svn co http://llvm.org/svn/llvm-project/polly/trunk polly
cd ../projects/
svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt
svn co http://llvm.org/svn/llvm-project/libunwind/trunk libunwind
svn co http://llvm.org/svn/llvm-project/openmp/trunk openmp
svn co http://llvm.org/svn/llvm-project/libcxxabi/trunk libcxxabi
svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx
First of all I build llvm, clang, libunwind against libgcc and libstdc++ using gcc and install them in /usr/local. In all the following steps except the last one I use this fresh clang/clang++.
Then I separately build libunwind, both the 32-bit and 64-bit versions (they are essential, as will be further, because asan needs the 32-bit versions of some libraries during the final compilation of the whole project tree) and install it in /usr/local/lib and /usr/local/lib32 correspondingly (also I update LD_LIBRARY_PATH respectively).
Build libcxxrt ABI library both 32-bit and 64-bit versions and install them properly.
Build libcxx against libcxxrt both 32-bit and 64-bit versions and install them properly.
Then build libc++abi against libc++ both 32-bit and 64-bit versions and install them properly.
Then build libc++ against libc++abi both 32-bit and 64-bit versions and install them properly over the previous version linked to libcxxrt.
After all I build the whole project tree against libc++, libc++abi, libunwind, compiler-rt and install it over old clang in /usr/local.
(I am almost sure that no step is redundant here.)
At the final step I have a problem: I have to add extra parameters to the linker (I add them to CMAKE_EXE_LINKER_FLAGS and CMAKE_SHARED_LINKER_FLAGS) -lunwind and -lc++abi. Moreover, every time I use the resulting clang++ with -stdlib=libc++ and compiler-rt (or, equally, CLANG_DEFAULT_CXX_STDLIB=libc++ and CLANG_DEFAULT_RTLIB=compiler-rt) in my projects I have to do it over and over. It annoying. Say Qt Creator generated project's CMakeLists.txt should be corrected by hand or by cmake-gui.
How to make clang driver to automatically specify these options to ld at runtime? Is there something similar to RPATH mechanism? Or is there some specific CMake variable (specified before llvm building process) to achieve desired behaviour?
Can I use RPATH for my purposes?
Surely I don't want to make some bash-script like wrappers (similar to clang++-libc++) to specify additional parameters. I want the libraries to be hardcoded somewhere in the clang binary itself.
There are a couple of workarounds have been suggested. I ended up with the following workaround:
mkdir build
cd build
# backup:
cp -vaf /usr/local/lib/libc++.{a,so.1.0} /usr/local/lib/libc++abi.{a,so.1.0} /usr/local/lib/libunwind.{a,so.1.0} .
clang -shared -fPIC -pthread -o fuse.so -Wl,--whole-archive libc++.a libc++abi.a libunwind.a -Wl,--no-whole-archive -ldl -lm
ar x libc++.a
ar x libc++abi.a
ar x libunwind.a
ar rc fuse.a *.o
sudo chown root:root fuse.*
sudo cp -vaf fuse.so /usr/local/lib/
sudo ln -svf /usr/local/lib/libc++.so.1 /usr/local/lib/fuse.so
sudo cp -vaf fuse.a /usr/local/lib/
sudo mv -vf /usr/local/lib/libc++.a /usr/local/lib/libc++.a.bak
sudo ln -svf /usr/local/lib/libc++.a /usr/local/lib/fuse.a
It merges all the libraries used (libc++, libc++abi and libunwind) into the one single *.a or *.so file. Then libc++.a and libc++.so are replaced with (links to) resulting assemblied files, saving a previous versions for possible backup.
It works perfectly for me.
But this is not the answer. Maybe someday clang will not have such a problem right from the box.

Macports on OSX 10.11 - compile "older" ports with -stdlib=libstdc++ [duplicate]

In OSX 10.9 the default -stdlib option for clang++ is libc++, so that's what Macport uses when building packages.
Is there any way to tell Macports to use libstdc++ instead?
In particular I would like to build OpenCV through Macports so it's using libstdc++, but I imagine I'll run into a need to do so for other packages as well
The option is simply: -stdlib=libstdc++
If you need finer control over the build process for various ports, you can always set variables like:
CXX = "clang -std=c++11 -stdlib=libc++, CXXFLAGS = "-Wall -O2 -march=core2", etc.
And build <port> from source:
sudo port -s install <port> -universal \
configure.cc="${CC}" configure.cxx="${CXX}" \
configure.cflags="${CFLAGS}" configure.cxxflags="${CXXFLAGS}"
The other alternative, is to install the gcc48 (or above) port, and use it as the compiler. Don't use the old gcc-4.2.1 installed with older versions of Xcode. It's rubbish.
One way to accomplish this appears to be to build opencv from source, and use the configure.cxx_stdlib variable to specify libstdc++ as your C++ runtime.
Try out the following:
sudo port install -s opencv configure.cxx_stdlib="libstdc++"

How to make clang search for gcc's headers?

I want to replace gcc with clang (3.3) to build my C++11 code, so I should use clang's option -stdlib=libstdc++ (to make it see STL headers). The option works: clang see headers like string, but can't find c++11 headers (type_traits) because clang searches in 4.2 directories:
clang++ -stdlib=libstdc++ -E -x c++ - -v < /dev/null
...
/usr/include/c++/4.2
/usr/include/c++/4.2/backward
/usr/include/clang/3.3
/usr/include
...
How to make it look at never versions of GCC's headers?
As far as I understand, only libc++ (not libstdc++) is supported by clang for C++11 so the only way it so install libc++?
Either uninstall gcc 4.2 or use the --gcc-toolchain=<value> option.
--gcc-toolchain=<value> Use the gcc toolchain at the given directory
For example: clang++ --gcc-toolchain=/usr/local/... -stdlib=libstdc++ ...
As far as I understand, only libc++ (not libstdc++) is supported by clang for C++11 so the only way it so install libc++?
Both C++ standard libraries are supported.

clang++ can not locate c++ header and library

My OS is OS X 10.10.2 and the default compiler for C is clang.
But this version of clang does not support ubsan (undefined sanitizer) which comes in the 3.4 release of clang. I also want to use KLEE to do some analysis. AFAIK KLEE works well with LLVM-<=3.4. I decided to install
llvm-3.4 and clang-3.4 in my laptop.
After installing clang-3.4 in my system, I encountered a issue that the compiler can not locate the c++ header file. I installed clang-3.4 in /usr/local and I can find the c++ header file in /usr/local/include/c++/4.8.4. How can I add this directory to the search path of clang-3.4 and also the c++ library?
for the following demo code:
#include <iostream>
using namespace std;
int main(){
cout<<"Hellow World\n";
return 0;
}
When I compile it using command clang++ test.cpp, I got the error
test1.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
^
1 error generated.
Below is the version of clang I used
clang version 3.4 (tags/RELEASE_34/final)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
I used the following shell command to install llvm-3.4 and clang-3.4:
wget http://llvm.org/releases/3.4/llvm-3.4.src.tar.gz \
http://llvm.org/releases/3.4/clang-3.4.src.tar.gz \
http://llvm.org/releases/3.4/clang-tools-extra-3.4.src.tar.gz \
http://llvm.org/releases/3.4/compiler-rt-3.4.src.tar.gz
tar zxf llvm-3.4.src.tar.gz
tar zxf clang-3.4.src.tar.gz -C llvm-3.4/tools
mv llvm-3.4/tools/clang{-3.4,}
tar zxf clang-tools-extra-3.4.src.tar.gz -C llvm-3.4/tools/clang/tools
mv llvm-3.4/tools/clang/tools/{clang-tools-extra-3.4,extra}
tar zxf compiler-rt-3.4.src.tar.gz -C llvm-3.4/projects
mv llvm-3.4/projects/compiler-rt{-3.4,}
cd llvm-3.4
./configure --enable-cxx11 \
--enable-bindings=none --enable-shared \
--enable-debug-symbols --enable-optimized
make
make install
Now I have two versions of clang in my OS, one is the default one shipped with OSX located in /usr/bin and the other is clang-3.4 located in /usr/local/bin. The previous one can find the C++ header file while the latter can not.
Did you read the user documentation of clang notably the section on command line options ? BTW, current (march 2015) version of clang is 3.6!
For C++ code you should use the clang++ command, not the clang command.
You might pass -I and -L options to clang++ but you might perhaps have misinstalled your clang compiler.
You should be aware of the -v and -H options of clang or clang++ ; they could be useful, at least to understand more your issue.
addenda
BTW, a program reported to work with Clang 3.4 is extremely likely to work with a more modern version, like Clang 3.5 or 3.6
You probably have a PATH issue; you should have configure -d your Clang-3.4 & LLvm-3.4 programs with --program-suffix=-my-3.4 (if you do that, repeat your entire compiler build and installation) and you probably should run /usr/local/bin/clang++-my-3.4 ; maybe you also need some --with-gcc-toolchain additional configure option.
I'm pretty sure that you should be able to try to compile or use your mysterious software requiring Clang-3.4 with a more modern version like 3.5 or 3.6 ; your MacOSX 10.10.2 is rumored to have a Clang-3.5 based system compiler, it very probably is able to compile and work with your mysterious software.

Macports on OSX 10.9 - compile with -stdlib=libstdc++

In OSX 10.9 the default -stdlib option for clang++ is libc++, so that's what Macport uses when building packages.
Is there any way to tell Macports to use libstdc++ instead?
In particular I would like to build OpenCV through Macports so it's using libstdc++, but I imagine I'll run into a need to do so for other packages as well
The option is simply: -stdlib=libstdc++
If you need finer control over the build process for various ports, you can always set variables like:
CXX = "clang -std=c++11 -stdlib=libc++, CXXFLAGS = "-Wall -O2 -march=core2", etc.
And build <port> from source:
sudo port -s install <port> -universal \
configure.cc="${CC}" configure.cxx="${CXX}" \
configure.cflags="${CFLAGS}" configure.cxxflags="${CXXFLAGS}"
The other alternative, is to install the gcc48 (or above) port, and use it as the compiler. Don't use the old gcc-4.2.1 installed with older versions of Xcode. It's rubbish.
One way to accomplish this appears to be to build opencv from source, and use the configure.cxx_stdlib variable to specify libstdc++ as your C++ runtime.
Try out the following:
sudo port install -s opencv configure.cxx_stdlib="libstdc++"