I’m glad to announce that I just successfully deployed the GNU-free toolchain, which I’ve been working on so far, into a musl-based Gentoo stage4. Everything in this stage4, except for the kernel, is built by clang with\u00a0non-GNU runtime libs. I’m now using this as my main Linux system, and luckily nothing breaks so far \ud83d\ude42<\/p>\n
To be more specific, the runtime environments of this stage4 is composed of the following components:<\/p>\n
Let’s take program \/usr\/bin\/ld.gold for example, which is written in C++, and see its runtime dependencies:<\/p>\n
$ ldd \/usr\/bin\/ld.gold\r\n\t\/lib\/ld-musl-x86_64.so.1 (0x559f8b598000)\r\n\tlibz.so.1 => \/lib\/libz.so.1 (0x7f5a5b7a9000)\r\n\tlibc++.so.1 => \/usr\/lib\/libc++.so.1 (0x7f5a5b6ea000)\r\n\tlibcxxrt.so.1 => \/usr\/lib\/libcxxrt.so.1 (0x7f5a5b4cd000)\r\n\tlibunwind.so.1 => \/usr\/lib\/libunwind.so.1 (0x7f5a5b4c4000)\r\n\tlibc.so => \/lib\/ld-musl-x86_64.so.1 (0x559f8b598000)\r\n<\/code><\/pre>\nApparently none of\u00a0the above libs is related to gcc. So this program is just free from gcc!<\/p>\n
Actually I’ve already figured out how to glue clang and those non-GNU C++ runtime libs together weeks ago; but this is the first time I put it into serious use. The most challenging part is to rebuild @world with this toolchain; I’m really nervous that\u00a0countless packages get broken after I issue the command\u00a0emerge -e @world<\/code>. Surprisingly enough, only two packages are broken.<\/p>\nThe first broken package\u00a0is\u00a0iproute2, which depends on\u00a0libmnl and libmnl is mis-compiled by clang. libmnl has an unpleasant past with clang [2], but its new\u00a0versions are fine. So the fix is simple: just upgrade libmnl to the latest version available (use ~amd64).<\/p>\n
The second broken package, ironically, is clang\/llvm itself. It turned out the libunwind I’m using lacks a few functions essential to llvm. Actually there’re two versions of libunwind available: one is from nongnu [3] which already exists in Gentoo’s repo for a while; the other one is developed by\u00a0LLVM and is\u00a0almost\u00a0<\/em>functionally equivalent to the former. Initially I just used the nongnu version, since there’s no package for LLVM’s libunwind yet. Unfortunately, the nongnu one works fine with everything else except for llvm itself. I just had to stop being lazy and wrote an ebuild for LLVM’s libunwind. Luckily again, it has everything we need, including those functions missing in the other libunwind.<\/p>\nAfter that, while I’m using this new system, I encountered a few other broken packages. But they’re either incompatible with musl, or the gold linker (yes, it’s the \/usr\/bin\/ld.gold I just showed you). There’s nothing wrong with clang or the C++ runtime libs.<\/p>\n
I also found an interesting fact: the building of gcc involves several steps of bootstrapping and the final executable has no dependence on any external C++ runtime libs, though gcc itself written in C++. This means gcc still works even clang or the C++ runtime gets broken. So I don’t need\u00a0to worry about breaking packages since I can still rebuild them with gcc \ud83d\ude42<\/p>\n
Now that I have a working stage4, the next step is to make gcc-config support clang, so clang can act like a real<\/strong>\u00a0native compiler.<\/p>\nStay tuned!<\/p>\n
<\/p>\n
[1] libcxxrt is functionally equivalent to libc++abi, and is planned to be replaced by the latter later in this project
\n[2]\u00a0https:\/\/bugs.chromium.org\/p\/chromium\/issues\/detail?id=548786
\n[3]\u00a0http:\/\/www.nongnu.org\/libunwind\/<\/p>\n","protected":false},"excerpt":{"rendered":"
I’m glad to announce that I just successfully deployed the GNU-free toolchain, which I’ve been working on so far, into a musl-based Gentoo stage4. Everything in this stage4, except for the kernel, is built by clang with\u00a0non-GNU runtime libs. I’m now using this as my main Linux system, and luckily nothing breaks so far \ud83d\ude42 … Continue reading A new Gentoo stage4: musl + clang<\/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\/58"}],"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=58"}],"version-history":[{"count":2,"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/posts\/58\/revisions"}],"predecessor-version":[{"id":60,"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/posts\/58\/revisions\/60"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/media?parent=58"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/categories?post=58"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/tags?post=58"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}