Missing runtime on Linux

[mmomtchev]

When building on Linux on a machine without a system default compiler installed, I am getting errors about missing compiler runtime:

https://github.com/mmomtchev/magickwand.js/actions/runs/10898992793/job/30243447516

When compiling locally:

strace -f clang -o test-clang test-clang.c -m64 --rtlib=compiler-rt -m64 -static-libstdc++ -static-libgcc -fuse-ld=lld

I see that parts of the gcc runtime are used:

access("/home/mmom/.local/xPacks/@xpack-dev-tools/clang/17.0.6-1.1/.content/lib/clang/17/Scrt1.o", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mmom/.local/xPacks/@xpack-dev-tools/clang/17.0.6-1.1/.content/lib/clang/17/lib/linux/Scrt1.o", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mmom/.local/xPacks/@xpack-dev-tools/clang/17.0.6-1.1/.content/bin/../Scrt1.o", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mmom/.local/xPacks/@xpack-dev-tools/clang/17.0.6-1.1/.content/lib/clang/17/lib/x86_64-unknown-linux-gnu/Scrt1.o", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mmom/.local/xPacks/@xpack-dev-tools/clang/17.0.6-1.1/.content/bin/../lib/x86_64-unknown-linux-gnu/Scrt1.o", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mmom/.local/xPacks/@xpack-dev-tools/clang/17.0.6-1.1/.content/lib/clang/17/lib/x86_64-unknown-linux-gnu/Scrt1.o", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gcc/x86_64-linux-gnu/12/Scrt1.o", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gcc/x86_64-linux-gnu/12/../../../../lib64/Scrt1.o", F_OK) = -1 ENOENT (No such file or directory)
access("/lib/x86_64-linux-gnu/Scrt1.o", F_OK) = 0
[pid 19205] execve("/home/mmom/src/magickwand.js/build/native-xpack/xpacks/.bin/ld.lld", ["/home/mmom/src/magickwand.js/bui"..., "-pie", "-z", "relro", "--hash-style=gnu", "--eh-frame-hdr", "-m", "elf_x86_64", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-o", "test-clang", "/lib/x86_64-linux-gnu/Scrt1.o", "/lib/x86_64-linux-gnu/crti.o", "/home/mmom/.local/xPacks/@xpack-"..., "-L/home/mmom/.local/xPacks/@xpac"..., "-L/home/mmom/.local/xPacks/@xpac"..., "-L/usr/lib/gcc/x86_64-linux-gnu/"..., "-L/usr/lib/gcc/x86_64-linux-gnu/"..., "-L/lib/x86_64-linux-gnu", "-L/lib/../lib64", "-L/usr/lib/x86_64-linux-gnu", "-L/usr/lib/../lib64", "-L/lib", "-L/usr/lib", "/tmp/test-clang-de3abf.o", "/home/mmom/.local/xPacks/@xpack-"..., "-lc", "/home/mmom/.local/xPacks/@xpack-"..., "/home/mmom/.local/xPacks/@xpack-"..., "/lib/x86_64-linux-gnu/crtn.o"], 0x7ffed5e006f0 /* 72 vars */ <unfinished ...>
[pid 19205] openat(AT_FDCWD, "/lib/x86_64-linux-gnu/Scrt1.o", O_RDONLY|O_CLOEXEC) = 3

I think that the missing part is the relocatable prologue/epilogue - is it possible that these must be enabled when installing?

[ilg-ul]

I think that the missing part is the relocatable prologue/epilogue - is it possible that these must be enabled when installing?

I don't know. Traditionally, on Linux, clang used the system & GCC libraries. Only in relatively recent releases they added --rtlib=compiler-rt, but I don't know if this configuration can be made to link standalone.

In my Linux tests I always install the system gcc, even if it is an old version.

Could you check the binaries from https://github.com/llvm/llvm-project/releases/tag/llvmorg-17.0.6 to see if those files are also referred?

[mmomtchev]

From one of the runtime authors https://discourse.llvm.org/t/cross-compile-any-llvm-component-using-clang-only-no-gcc-requirement/80282/24?page=2:

libgcc objects such as crtbegin.o and its friends can alternatively come from compiler-rt.

Glibc objects such as crt1.o, Scrt1.o, rcrt1.o can alternatively come from llvm-libc (which, unfortunately, does not work properly yet).

Inside LLVM, there is llvm-project/llvm-libgcc at main · llvm/llvm-project · GitHub which actually helps you to bundle a libgcc-alike library from compiler-rt. Notice that you are not supposed to use this because llvm-libgcc is for those who want cheat gnu toolchain that they have libgcc*. If you want the whole system to be of LLVM-flavor, you should not need this trick.

Entry/exit code is part of the glibc distribution and not the compiler runtime. Ie, on Debian/Ubuntu, this would be the libc6-dev package.

[ilg-ul]

Thank you for clarifying this.