Previously we discussed how to build a LLVM\u00a0C++ runtime stack with libc++, libc++abi and libunwind. Along with musl, we now\u00a0have a GNU-free C\/C++ runtime environment. But an\u00a0unfortunate fact\u00a0is, clang is used to living\u00a0with GCC and glibc, and it takes\u00a0some extra effort\u00a0to make clang\u00a0work with our new environment. In my last post, I demonstrated how to make a wrapper of clang to build GNU-free executables. As the name of this project implies, we want a native clang, not an ugly wrapper. So in this post, I’m going to show you how to build a native clang that works “out of the box”.<\/p>\n
Before getting into it, let’s first analyze what dependencies a program built by clang typically has. For C programs, it’s of course glibc; and for C++ programs there’s also libstdc++. Yet there’s a lesser known library that every program relies on: libgcc. Sometimes it’s statically linked into the executable, other times dynamically linked in the form of “libgcc_s”. libgcc is a low-level runtime library provided by GCC. More information can be found at:\u00a0https:\/\/gcc.gnu.org\/onlinedocs\/gccint\/Libgcc.html<\/a>.\u00a0LLVM also has a replacement for it: compiler-rt; and we’ll need this later.<\/p>\n The biggest obstacle preventing clang from working with musl is that musl has its own dynamic linker which could not be recognized by clang. A naive workaround is to rename musl’s linker to the same name as glibc’s, but that would obviously mess up the whole system. We’ll have to take a alternative approach (which I’m personally resistant to): modify clang\/LLVM’s source code.<\/p>\n Two rudimentary patches that work on x86_64 platforms\u00a0could be found here:\u00a0https:\/\/github.com\/zzlei\/musl-clang<\/a>. As their names imply, one patch is for the LLVM source root, and the other for clang. Assume you’ve already checked out LLVM, clang and compiler-rt to the right location, say $LLVM, $LLVM\/tools\/clang and $LLVM\/projects\/compiler-rt respectively. After applying the patches, issue the following command to build them all together: Some explanations: After putting the freestanding C++ runtime libraries we previously built under \/usr\/x86_64-pc-linux-musl\/usr\/lib, we should have a native clang that “almost” works out of the box. Why “almost”? Because we still need to feed\u00a0one\u00a0option to\u00a0clang: “-rtlib=compiler-rt”, indicating the use of compiler-rt instead of libgcc. I’m still struggling to set this option permanently at build time; hopefully I don’t have to modify too much of clang’s code to achieve this…<\/p>\n Now, let’s take a final look of our product: Great!<\/p>\n","protected":false},"excerpt":{"rendered":" Previously we discussed how to build a LLVM\u00a0C++ runtime stack with libc++, libc++abi and libunwind. Along with musl, we now\u00a0have a GNU-free C\/C++ runtime environment. But an\u00a0unfortunate fact\u00a0is, clang is used to living\u00a0with GCC and glibc, and it takes\u00a0some extra effort\u00a0to make clang\u00a0work with our new environment. In my last post, I demonstrated how to … Continue reading Build GNU-free executables with 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":[2],"tags":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/posts\/49"}],"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=49"}],"version-history":[{"count":1,"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/posts\/49\/revisions"}],"predecessor-version":[{"id":50,"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/posts\/49\/revisions\/50"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/media?parent=49"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/categories?post=49"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc2016-native-clang\/wp-json\/wp\/v2\/tags?post=49"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n
\n$ mkdir $LLVM\/build && cd $LLVM\/build
\n$ cmake -DGCC_INSTALL_PREFIX=\/usr \\
\n-DDEFAULT_SYSROOT=\/usr\/x86_64-pc-linux-musl \\
\n-DCLANG_DEFAULT_CXX_STDLIB=libc++ \\
\n-DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-musl ..
\n$ make
\n<\/code><\/p>\n
\nDEFAULT_SYSROOT<\/strong> tells clang where to find musl’s headers and libraries. It’s pointed to the location where the musl toolchain is installed.
\nGCC_INSTALL_PREFIX<\/strong> specifies where GCC is installed. clang needs this to find crtbegin.o and crtend.o. This part is a bit thorny, as neither musl or clang provides these files. We’ll need to replace them with some other vendor’s later in this project.
\nCLANG_DEFAULT_CXX_STDLIB<\/strong> tells clang to use libc++ by default. A vanilla clang on Linux always uses libstdc++ by default.
\nLLVM_DEFAULT_TARGET_TRIPLE<\/strong> informs clang that we’re targeting on musl-libc; without this clang won’t find the correct dynamic linker.<\/p>\n
\n
\n$ .\/bin\/clang++ hello.cc -rtlib=compiler-rt
\n$ readelf -d a.out | grep NEEDED
\n0x0000000000000001 (NEEDED) Shared library: [libc++.so.1]
\n0x0000000000000001 (NEEDED) Shared library: [libc++abi.so.1]
\n0x0000000000000001 (NEEDED) Shared library: [libc.so]
\n<\/code><\/p>\n