On 7/12/21 8:42 AM, Brian Cain wrote: > If you don't mind binaries, there are x86_64 linux binary toolchains with lld > on releases.llvm.org
I've never managed to run those binaries, because they're dynamically linked against some specific distro I'm not using: $ bin/clang --help /lib/ld-linux-aarch64.so.1: No such file or directory All the toolchains I build for distribution are statically linked on the host. (Back in the day I even wrote a https://github.com/landley/aboriginal/blob/master/sources/toys/ccwrap.c wrapper to feed --nostdinc --nostdlib to gcc and build up all the includes again manually to stop gcc from leaking random host context into the cross compilers, but these days I use https://github.com/landley/toybox/blob/master/scripts/mcm-buildall.sh with Rich Felker's musl-cross-make to create statically linked cross and native musl toolchains which I would happily post binaries of if they weren't GPLv3 and thus non-distributable. Oh well.) Vaguely trying to make an llvm-buildall.sh for toybox, which might be a fourth section to https://landley.net/toybox/faq.html#cross but first I'm trying to make the hexagon-only one work based on your model. :) > and there's also a binary hexagon-linux cross toolchain that > we shared for use by kernel developers. The hexagon linux > toolchain is built on Ubuntu 16.04. Where's that one? > But when building your toolchain, omitting LLVM_ENABLE_LLD should work just > fine. It did, thanks. Now I'm trying to figure out what all the extra CFLAGS are for. The clang_rt build has CMAKE_ASM_FLAGS="-G0 -mlong-calls -fno-pic --target=hexagon-unknown-linux-musl" which https://clang.llvm.org/docs/ClangCommandLineReference.html defines as: -G<size> Put objects of at most <size> bytes into small data section (MIPS / Hexagon) -mlong-calls Generate branches with extended addressability, usually via indirect jumps. I don't understand why your libcc build needs no-pic? (Are we only building a static libgcc.a instead of a dynamic one? I'm fine with that if so, but this needs to be specified in the MAKE_ASM_FLAGS why?) Why is it saying --target=hexagon-random-nonsense-musl to a toolchain we built with exactly one target type? How does it NOT default to hexagon? (Is this related to the build writing a hexagon-potato-banana-musl.cfg file in the bin directory, meaning the config file is in the $PATH? Does clang only look for it in the same directory the clang executable lives in?) And while we're at it, the CONTENTS of hexagon-gratuitous-gnu-format.cfg is: cat <<EOF > hexagon-unknown-linux-musl.cfg -G0 --sysroot=${HEX_SYSROOT} EOF Which is ALREADY saying -G0? (Why does it want to do that globally? Some sort of bug workaround?) So why do we specify it again here? Next up build_musl_headers does CROSS_CFLAGS="-G0 -O0 -mv65 -fno-builtin -fno-rounding-math --target=hexagon-unknown-linux-musl" which: -O0 disable most of the optimizer -mv65 -mtune for a specific hexagon generation. (Why? Does qemu only support that but not newer?) -fno-builtin musl's ./configure already probes for this and will add it if the compiler supports it. -fno-rounding-math the docs MENTION this, but do not explain it. And again with the -G0. These flags probably aren't needed _here_ because this is just the headers install (which is basically a cp -a isn't it?). This looks like it's copied verbatim from the musl library build. But that library build happens in a bit, so relevant-ish I guess... (Also, why does building librt-but-not-really need the libc headers? The libgcc build EXPLICITLY does not require that, because otherwise you have this kind of BS circular dependency. Also, how do you EVER build a bare metal ELF toolchain with that dependency in there?) Next up build_kernel_headers has KBUILD_CFLAGS_KERNEL="-mlong-calls" which again, A) why does the compiler not do by default, B) can't be needed here because you don't even have to specify a cross compiler when doing headers_install. (I just confirmed this by diffing installs with an without a cross compiler specified: they were identical. I remembered this from https://github.com/torvalds/linux/commit/e0e2fa4b515c but checked again to be sure.) Presumably this is more "shared with full kernel build". And then build_musl, covered above under the headers build: lotsa flags, not sure why. > -Brian > Rob P.S. It took me a while to figure out that clang_rt is NOT librt.a, I think it's their libgcc? Especially confusing since librt.a has existed for decades and was on solaris before it was on linux, and the OBVIOUS name is libcc the same way "cc" is the generic compiler name instead of "gcc". (In fact that was the posix compiler name until they decided to replace it with "c99" and everybody ignored them the way tar->pax was ignored, largely because make's $CC defaults to "cc" so it Just Works, and yes the cross compiler should have that name but the prepackaged clang tarball above does not. *shrug* I fix that up when making my prefix symlinks. The android NDK guys at least have the excuse of shipping NINE different x86_64-linux-android*-clang with API version numbers and thus not wanting to pick a default to single out, so leave making the -cc link as an exercise for the reader. I give instructions for doing so on the toybox cross compiling page I linked above. :)