Hey! This week I’ve spent most of my time figuring out how to bootstrap
\na LLVM cross compiler toolchain targeting a hosted Linux environment. I
\nhave also resolved the wint_t issue from last week. Both of these things
\ntook way longer than expected, but I also learned a lot more than
\nexpected so it was worth it.<\/p>\n
I’ll start with discussing the LLVM cross compiler setup. My initial As the compiler-rt cross compilation documentation only tells you to use After this is done you can pass the following CFLAGS: After this is done you can export To then build actual binaries targeting the newly built libc you can do something like this:<\/p>\n ld.lld -static main.o \\ Running the binary with qemu-user: Afterwards it feels pretty obvious that the headers were needed, and I Next I also figured out what, and why, the wint_t problem occurs when The problem arises because LLVM libc assumes that the Clang headers will After discussing this we agreed to first actually get the libc built, Other things worth noting is that my ‘USE=emacs llvm-common’ PR inspired a https:\/\/reviews.llvm.org\/D153729<\/a><\/p>\n Next week I will try to make Crossdev be able to use LLVM\/Clang by Hey! This week I’ve spent most of my time figuring out how to bootstrap a LLVM cross compiler toolchain targeting a hosted Linux environment. I have also resolved the wint_t issue from last week. Both of these things took way … Continue reading
\nidea on how to bootstrap a toolchain was to simply specify LLVM_TARGETS<\/code>
\nfor the target architecture when building LLVM, then compile compiler-rt
\nfor the target triple, and then the libc. This is indeed true, but the official
\ncross compilation instructions tells you to specify a sysroot where the
\nlibc is already built, and that’s not possible when bootstrapping from
\nscratch.<\/p>\n
\nan already set up sysroot, which I didn’t have, I had to try my way
\nforward. This actually took me a few days, and I did things like trying
\nto bootstrap with a barebones build of compiler-rt, mixing in some GCC
\nthings, and a lot of hacks. I then studied
\nmussel<\/a> for a while until finding out about
\nheaders-only “builds” for glibc and musl. It turns out that the only
\nthing compiler-rt needs the sysroot for is libc headers, and those can
\nbe generated without a functioning compiler for both musl and
\nglibc. This is done by setting CC=true<\/code> to pass all the configure tests
\nand then run ‘make headers-install<\/code>‘ (for musl) into a temporary install
\ndirectory to generate the headers needed for bootstrapping
\ncompiler-rt.<\/p>\nexport CC=true
\n.\/configure \\
\n --target=${CTARGET} \\
\n --prefix=\"${MUSL_HEADERS}\/usr\" \\
\n --syslibdir=\"${MUSL_HEADERS}\/lib\" \\
\n --disable-gcc-wrapper
\nmake install-headers<\/code><\/p>\n
\n‘-nostdinc -I*path to temporary musl install dir*\/usr\/include<\/code>‘ to the
\ncompiler-rt build. <\/p>\n-DCMAKE_ASM_COMPILER_TARGET=\"${CTARGET}\"
\n-DCMAKE_C_COMPILER_TARGET=\"${CTARGET}\"
\n-DCMAKE_C_COMPILER_WORKS=1
\n-DCMAKE_CXX_COMPILER_WORKS=1
\n-DCMAKE_C_FLAGS=\"--target=${CTARGET} -isystem ${MUSL_HEADERS}\/usr\/include -nostdinc -v\"<\/code><\/p>\n
\nLIBCC=\"${COMPILER_RT_BUILDDIR}\"\/lib\/linux\/libclang_rt.builtins-aarch64.a<\/code>
\nto the musl build to use the previously built compiler-rt builtins for
\nthe actual libc build.<\/p>\nclang --target=\"${CTARGET}\" main.c -c -nostdinc -nostdlib -I\"${MUSL_HEADERS}\"\/usr\/include -v<\/p>\n
\n \"${COMPILER_RT_BUILDDIR}\"\/lib\/linux\/libclang_rt.builtins-aarch64.a \\
\n \"${MUSLLIB}\"\/crti.o \"${MUSLLIB}\"\/crt1.o \"${MUSLLIB}\"\/crtn.o \"${MUSLLIB}\"\/libc.a<\/code><\/p>\n
\n$ cat \/etc\/portage\/package.use\/qemu
\n> app-emulation\/qemu static-user QEMU_USER_TARGETS: aarch64
\n$ emerge qemu
\n$ qemu-aarch64 a.out
\n> hello, world<\/code><\/p>\n
\ncould’ve probably figured it out a lot sooner by for example examining
\ncrossdev a bit closer. But I am happy I did play with this since I
\nlearned things like what the different runtime libraries did, what’s
\nneeded to link a binary, and a lot more. Here’s a complete script that
\ndoes everything:
\ngist<\/a>.
\nNext I will integrate this into crossdev. Another thing I need to think
\nabout is how to do a header-only install of LLVM libc. Currently the
\nheaders get generated with libc-hdrgen and installed with the
\ninstall-libc target. Probably this can be done by packaging a standalone
\nlibc-hdrgen binary and using that for bootstrapping. I could also
\ntemporarily “cheat” and do a compiler-rt+libc build to get going.<\/p>\n
\nbuilding LLVM libc in fullbuild mode on a musl system (see last week’s
\nreport). The problem here is that on a musl system, \/usr\/include will be
\nfirst in the include path, regardless of CFLAGS=\"-ffreestanding\"<\/code>. (for
\nC++ they will be after the standard C++ headers and then
\n#include_next<\/code>‘ed, so no difference). I thought at first that this was a
\nbug since you don’t want to target an environment where the libc is
\navailable (hosted environment) when building in freestanding
\nmode. However, after asking in #musl IRC this is actually fine since the
\nmusl headers respect the __STDC_HOSTED__<\/code> variable that gets set when using
\n-ffreestanding<\/code>, and there is a clear standard specifying what should be
\navailable in a freestanding environment.<\/p>\n
\nbe used when passing -ffreestanding<\/code>, and therefore relies on Clang header
\ninternals. Specifically the __need_wint_t<\/code> macro for stddef.h<\/code> which is
\nin no way standardized and only an implementation detail. My thought
\nhere was to instead of relying on CFLAGS=\"-ffreestanding\"<\/code> to use the
\nClang headers, we should instead figure out another way using the build
\nsystem to force Clang headers. Another way to solve this would also just
\nbe to also rely on musl internals (__NEED_wint_t<\/code> for stddef.h).<\/p>\n
\nand then decide on a strategy once we know how many times similar issues
\npop up. If there are only a few instances of this then more #defines are
\nfine, else we could do something like the gcc buildbot target. My only
\nworry with this is that it will keep biting us in the ass as more things
\nget added.
\nhttps:\/\/github.com\/llvm\/llvm-project\/issues\/63510<\/a><\/p>\n
\nnew elisp-common.eclass<\/code> function called elisp-make-site-file<\/code>
\nhttps:\/\/github.com\/gentoo\/gentoo\/commit\/a4e8704d22916a96725e0ef819d912ae82270d28<\/a>because mgorny thought that my sitefiles were a waste of inodes :D.
\nhttps:\/\/github.com\/gentoo\/gentoo\/pull\/31635<\/a>. I also got my
\n__unix__<\/code>->__linux__<\/code> CL merged into LLVM. I do however have some worries
\nthat this could’ve broken some things on macOS as seen in my comment:<\/p>\n> done! I think there should be something addressing pthread_once_t and
\n> once_flag for other Unix platforms though. Both of these would've
\n> previously, before this commit, been valid on macOS, as __unix__ is
\n> defined and __futex_word is just an aligned 32 bit int. No internal
\n> Linux headers were used here before that would've caused an error.<\/code><\/p>\n
\nintegrating the things I did this week.<\/p>\n","protected":false},"excerpt":{"rendered":"