How to Compile/Link Boost with Clang++/Libc++

How to compile/link Boost with clang++/libc++?

I didn't know how to do this either. But after poking around in here, the getting started, and trial and error:

$ ./bootstrap --with-toolset=clang
$ ./b2 clean
$ ./b2 toolset=clang cxxflags="-stdlib=libc++" linkflags="-stdlib=libc++"

You'll get lots of warnings. And the signals library will fail to build due to LWG 2059. But otherwise I think it works.

Building Boost 1.50.0 with clang++ 3.1

Looks to be a known build issue with clang++ and Boost 1.50 with C++11 turned on

• https://svn.boost.org/trac/boost/ticket/4999
• https://svn.boost.org/trac/boost/ticket/5774

You can get round the issue by not building signals. The following steps worked for me:

$ cd /usr/local/boost_1_50_0
$ sudo ./bootstrap.sh --with-toolset=clang
$ sudo ./b2 toolset=clang cxxflags="-std=c++11 -stdlib=libc++" linkflags="-stdlib=libc++" --without-signals

Why can't clang with libc++ in c++0x mode link this boost::program_options example?

You need to rebuild boost using clang++ -stdlib=libc++.

libc++ is not binary compatible with gcc's libstdc++ (except for some low level stuff such as operator new). For example the std::string in gcc's libstdc++ is refcounted, whereas in libc++ it uses the "short string optimization". If you were to accidentally mix these two strings in the same program (and mistake them for the same data structure), you would inevitably get a run time crash.

This accident is exactly what has occurred in your case.

In order to turn this run time crash into a link time error, libc++ uses a C++11 language feature called inline namespace to change the ABI of std::string without impacting the API of std::string. That is, to you std::string looks the same. But to the linker, std::string is being mangled as if it is in namespace std::__1. Thus the linker knows that std::basic_string and std::__1::basic_string are two different data structures (the former coming from gcc's libstdc++ and the latter coming from libc++).

I want to compile Boost 1.70 with Clang 60 on Centos 7

While compiling Boost with toolset=clang is easily implemented with a PR on the ansible-role https://github.com/dockpack/base_boost/pull/24, the problem really is where to get Clang 6 for Centos 7?

Note: Since the November 2018 release, Red Hat’s Clang/LLVM package
naming convention has changed so that the Red Hat version number now
reflects the upstream version. The llvm-toolset-7packages (without the
dot zero), are based on Clang/LLVM 5.0. The new package name for
Clang/LLVM 7.0 is llvm-toolset-7.0 (seven dot zero). Although this
might seem confusing now, hopefully it will make things easier for
everyone going forward.

I'm interested in llvm-toolset-6.0 which is available for RHEL 7, but can't be found in
CentOS 7.

Springdale Linux usually rebuilds SCL stuff much faster then the CentOS Software Collections SIG.

llvm-toolset-7 contains LLVM 5.0.1.

llvm-toolset-6.0 contains LLVM 6.

llvm-toolset-7.0 contains LLVM 7.

[SCL-core]
name=Springdale SCL Base $releasever - $basearch
mirrorlist=http://springdale.princeton.edu/data/springdale/SCL/$releasever/$basearch/mirrorlist
#baseurl=http://springdale.princeton.edu/data/springdale/SCL/$releasever/$basearch
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-springdale

CrystaX with clang++ and libc++ link error with boost and icu

This happens because LLVM libc++ is not binary compatible with GNU libstdc++, and Boost in CrystaX NDK was built and linked against GNU libstdc++. The only way to fix it is build Boost with LLVM libc++, which shouldn't be too hard, but it's completely non-tested. I've filed ticket to do that in CrystaX NDK, but practically right now the fastest way would be to use GNU libstdc++ as C++ Standard Library implementation (it works with clang).

In other words, your Application.mk should be as below:

NDK_TOOLCHAIN_VERSION := clang3.5
APP_STL := gnustl_static

linking with libc++ compiled boost

I just figured out my problem. it was due to Boost not compiled properly because libiconv is not recognized by bjam in my other machine. I guess the reason that it was not recognized is probably because i installed macport. Immediately after i uninstall all the macport stuff, bjam can recognize libiconv and build boost properly under libc++ except signals, but that's alright.

---

Related Topics