Update RootFS build

[giordano]

Companion PR to JuliaPackaging/Yggdrasil#11095.

[giordano]

C++ - Linux x86_64 {libc=glibc}: Test Failed at /home/runner/work/BinaryBuilderBase.jl/BinaryBuilderBase.jl/test/runners.jl:384
  Expression: run(ur, cmd, iobuff; tee_stream = devnull)
Stacktrace:
 [1] macro expansion
   @ /opt/hostedtoolcache/julia/1.7.3/x64/share/julia/stdlib/v1.7/Test/src/Test.jl:445 [inlined]
 [2] (::var"#293#315"{Platform})(dir::String)
   @ Main ~/work/BinaryBuilderBase.jl/BinaryBuilderBase.jl/test/runners.jl:384

This failure is relevant since here we're upgrading CSL, including libstdc++, in the rootfs. I won't have the time to look into this for a while though.

[giordano]

C++ - Linux x86_64 {libc=glibc}: Test Failed at /home/runner/work/BinaryBuilderBase.jl/BinaryBuilderBase.jl/test/runners.jl:387
  Expression: endswith(readchomp(iobuff), "Hello World!")
   Evaluated: endswith("`/bin/bash -c \"set -e\necho '#include <iostream>\nclass breakCCompiler; // Courtesy of Meson\nint main() {\n    std::cout << \\\"Hello World!\\\" << std::endl;\n    return 0;\n}\n' > test.cpp\n# Make sure we can compile successfully also when \\`\\\${libdir}\\` is in the\n# linker search path\nc++ -o test test.cpp -L\\\${libdir}\n./test 2>&1\n\"`\n./test: /usr/lib/csl-musl-x86_64/libstdc++.so.6: no version information available (required by ./test)\nHello World!\n/bin/bash: line 12:    13 Segmentation fault      (core dumped) ./test 2>&1", "Hello World!")

Two interesting notes:

• /usr/lib/csl-musl-x86_64/libstdc++.so.6 is mentioned when running a glibc executable: are we loading the wrong library?
• Hello World!\n/bin/bash: line 12: 13 Segmentation fault: we do run the executable and print the output, but also segfault? What's going on? 😂

[giordano]

 Got correct result, please change to @test if no longer broken.

[giordano]

Ok, swapping the order the libraries in CSL breaks something else, e.g. cargo:

sandbox:${WORKSPACE} # make -j${nproc} -sC /usr/share/testsuite install
c++ -o /tmp/testsuite/x86_64-linux-gnu/cxx/hello_world/hello_world -g -O2 hello_world.cc
cc -o /tmp/testsuite/x86_64-linux-gnu/c/hello_world/hello_world -g -O2 hello_world.c
c++ -shared -o /tmp/testsuite/x86_64-linux-gnu/cxx/dyn_link/librepeater/librepeater.so -fPIC -g -O2 -lm librepeater/librepeater.cc
cc -shared -o /tmp/testsuite/x86_64-linux-gnu/c/dyn_link/libfoo/libfoo.so -fPIC -g -O2 -lm libfoo/libfoo.c
gcc -o /tmp/testsuite/x86_64-linux-gnu/c/openmp/openmp -g -O2 -fopenmp openmp.c
cc -o /tmp/testsuite/x86_64-linux-gnu/c/dyn_link/dyn_link -I/usr/share/testsuite/c/dyn_link/libfoo -fPIC -g -O2 -Wl,-z,origin -Wl,-rpath,$ORIGIN/libfoo -L/tmp/testsuite/x86_64-linux-gnu/c/dyn_link/libfoo -lfoo dyn_link.c
c++ -o /tmp/testsuite/x86_64-linux-gnu/cxx/dyn_link/dyn_link -I/usr/share/testsuite/cxx/dyn_link/librepeater -fPIC -g -O2 -Wl,-z,origin -Wl,-rpath,$ORIGIN/librepeater -L/tmp/testsuite/x86_64-linux-gnu/cxx/dyn_link/librepeater -lrepeater dyn_link.cc
gfortran -o /tmp/testsuite/x86_64-linux-gnu/fortran/hello_world/hello_world.o -c hello_world.f
cargo install --verbose --path . --root /tmp/testsuite/x86_64-linux-gnu/rust/cargo_build
rustc -o /tmp/testsuite/x86_64-linux-gnu/rust/hello_world/hello_world hello_world.rs
Error relocating /usr/lib/csl-glibc-x86_64/libgcc_s.so.1: __cpu_indicator_init: symbol not found
Error relocating /usr/lib/csl-glibc-x86_64/libgcc_s.so.1: __cpu_model: symbol not found
Error relocating /lib64/ld-linux-x86-64.so.2: unsupported relocation type 37
make[1]: *** [Makefile:7: /tmp/testsuite/x86_64-linux-gnu/rust/cargo_build/cargo_build] Error 127
make: *** [Makefile:48: install-project-rust-cargo_build] Error 2
make: *** Waiting for unfinished jobs....
Error relocating /usr/lib/csl-glibc-x86_64/libgcc_s.so.1: __cpu_indicator_init: symbol not found
Error relocating /usr/lib/csl-glibc-x86_64/libgcc_s.so.1: __cpu_model: symbol not found
Error relocating /lib64/ld-linux-x86-64.so.2: unsupported relocation type 37
make[1]: *** [Makefile:7: /tmp/testsuite/x86_64-linux-gnu/rust/hello_world/hello_world] Error 127
make: *** [Makefile:48: install-project-rust-hello_world] Error 2

@staticfloat @Keno I think there's something wrong with the musl rejection patch though: #423 (comment)

[giordano]

I may be wrong, but https://github.com/JuliaPackaging/Yggdrasil/blob/31124d256133d96e48c5558317c125deae96e0a4/0_RootFS/Rootfs/bundled/patches/glibc_musl_rejection.patch doesn't seem to be applied anywhere in https://github.com/JuliaPackaging/Yggdrasil/blob/31124d256133d96e48c5558317c125deae96e0a4/0_RootFS/Rootfs/build_tarballs.jl. How's that supposed to work?

[giordano]

I'm moving a bit blindfolded because I don't know exactly how this was designed to work, but as far as I can tell this isn't really working in practice.

I'm trying to summarise the facts I could gather:

• that's a patch for glibc, we apply it when compiling glibc in gcc: https://github.com/JuliaPackaging/Yggdrasil/blob/31124d256133d96e48c5558317c125deae96e0a4/0_RootFS/gcc_common.jl#L354-L356
• in the RootFS we fetch the libcs in https://github.com/JuliaPackaging/Yggdrasil/blob/31124d256133d96e48c5558317c125deae96e0a4/0_RootFS/Rootfs/bundled/libs/libc/download_libcs.sh
• we then install these libraries at https://github.com/JuliaPackaging/Yggdrasil/blob/31124d256133d96e48c5558317c125deae96e0a4/0_RootFS/Rootfs/build_tarballs.jl#L234-L241

Questions:

1. do I understand correctly that we should apply the musl reject patch to the glibc we install, which is basically Glibc_jll?
2. since that's a patch for glibc to reject musl, having glibc before musl in LD_LIBRARY_PATH would make sense, right? Edit: thinking more about this, probably this isn't correct: the problem now is with trying to run a musl executable with glibc libraries listed first: there's nothing to prevent this going wrong.

[giordano]

About question 1: we already apply the musl rejection patch: https://github.com/JuliaPackaging/Yggdrasil/blob/31124d256133d96e48c5558317c125deae96e0a4/G/Glibc/Glibc%402.34/bundled/patches/glibc-006-glibc_musl_rejection_234.patch. So I'm even more lost now.

Side note, at a quick glance, bminor/glibc@8ee8785 in glibc 2.37 may have made it harder to implement the rejection patch.