So far my GSoC project for Gentoo this year is soon coming to an end. There are still a few missing pieces, but the goal \u2014 supporting clang as a native compiler \u2014 is almost achieved. There’s nothing preventing you from using clang natively in your system now, and I’ll show you how in this post \ud83d\ude42<\/p>\n
First, you should install a GCC-free C++ runtime stack, composed of libunwind, libcxxrt and libcxx. There’re two versions of libunwind, one from nongnu and the other from LLVM. I encourage you to use the LLVM version, which proved\u00a0more robust in my previous experiments [1]. To explicitly install\u00a0LLVM’s libunwind, type:<\/p>\n
followed by:<\/p>\n libcxxrt will be pulled in automatically by emerge since libcxx depends on it. If we don’t explicitly install llvm-libunwind, the nongnu version will be pulled in instead.<\/p>\n Then it’s time to install clang:<\/p>\n The USE flags Remember to apply keyword Then we are ready to go! Now you can use clang to compile any C\/C++ program and the resulting binary will be GCC-free: no dependence on libgcc or libstdc++. Also put NOTE: there’s one package you should pay attention to: libmnl. It’s pulled in by another package iproute2, and unfortunately is mis-compiled by clang [1]. There’re two solutions: 1) apply keyword\u00a0 At this moment, you may wonder if we can just uninstall GCC once and for all. Unfortunately, the answer is no. There are two cases where GCC is still irreplaceable.\u00a0First is when you upgrade your kernel. Currently clang is not capable of compiling the kernel without heavy patching, so you still need the good old GCC.<\/p>\n The second case is when you compile C++ code. When I say the binary built by clang is GCC-free, it’s actually not 100% true \ud83d\ude41 There’re two pieces from GCC needed by every C++ program: crtbegin and crtend; unfortunately they’re not provided by any library mentioned above. I tried borrowing implementation of these two files from NetBSD, and they seem to work right out of the box. But another problem is that clang on Linux is hardcoded to use GCC’s crtbegin\/end; NetBSD’s crtbegin\/end won’t be recognized unless clang’s behavior is altered. This issue isn’t unresolvable and I’ll see if I can find a workaround for it. For now, just don’t remove your GCC \ud83d\ude42<\/p>\n This project is not finished. There’re two pieces to be delivered soon: 1) a new package libcxxabi, which is developed by LLVM, will replace libcxxrt as the default C++ ABI library; 2) a new profile for native clang where USE flags, keywords and masks are all set appropriately so you don’t need to do it yourself.<\/p>\n Stay tuned!<\/p>\n <\/p>\n [1]\u00a0https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/2016\/07\/24\/a-new-gentoo-stage4-musl-clang\/<\/p>\n","protected":false},"excerpt":{"rendered":" So far my GSoC project for Gentoo this year is soon coming to an end. There are still a few missing pieces, but the goal \u2014 supporting clang as a native compiler \u2014 is almost achieved. There’s nothing preventing you from using clang natively in your system now, and I’ll show you how in this … Continue reading Use clang as a native compiler in Gentoo<\/span><\/a><\/p>\n","protected":false},"author":161,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/posts\/64"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/users\/161"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/comments?post=64"}],"version-history":[{"count":3,"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/posts\/64\/revisions"}],"predecessor-version":[{"id":77,"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/posts\/64\/revisions\/77"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/media?parent=64"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/categories?post=64"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/tags?post=64"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}$ emerge llvm-libunwind<\/code><\/p>\n$ USE=libunwind emerge libcxx<\/code><\/p>\n$ USE='clang default-libcxx default-compiler-rt' emerge llvm<\/code><\/p>\ndefault-libcxx<\/code>\u00a0and default-compiler-rt<\/code>\u00a0tell clang to use libc++ as the default C++ library and compiler-rt as the default runtime library, in place of libstdc++ and libgcc respectively, thus getting rid of dependence on GCC. If your system is based on musl-libc, you need also add -sanitize<\/code>\u00a0to the USE flags to disable LLVM’s sanitizers, which won’t compile on musl at the moment.<\/p>\n~amd64<\/code>\u00a0on all the packages involved, since the features mentioned above are only available in the latest version of those packages. Additionally, the latest version of LLVM is currently masked for testing; you need to put the following line in package.unmask to unmask it:<\/p>\n# in file \/etc\/portage\/profile\/package.unmask
\n=sys-devel\/llvm-3.8.1-r1<\/code><\/p>\nCC=clang<\/code>\u00a0and CXX=clang++<\/code>\u00a0to ensure all your future packages are compiled by clang. Actually\u00a0I encourage you to rebuild @world instantly, after which all packages in your system will be GCC-free:<\/p>\n$ emerge -e @world<\/code><\/p>\n~amd64<\/code>\u00a0on libmnl so the latest version is used, which works with clang; 2) apply USE flag minimal<\/code>\u00a0on iproute2 so it doesn’t need libmnl at all.<\/p>\n