test: fix(main/llvm): link LLVM readelf to libLLVM statically

[robertkirkman]

• Experiment for testing related to [Bug]: ldd in Termux is much slower than ldd in GNU/Linux (and LLVM readelf is slower than GNU readelf) #28904

[TomJo2000]

6 Megs seems like a worthwhile tradeoff to fix the performance issue of llvm readelf/readobj until we have a more permanent answer/fix from upstream about the root cause.

[Andarwinux]

Maybe consider using LLVM_TOOL_LLVM_DRIVER_BUILD to build the whole llvm/clang toolchain as a statically linked package independent of libLLVM?

[robertkirkman]

Maybe consider using LLVM_TOOL_LLVM_DRIVER_BUILD to build the whole llvm/clang toolchain as a statically linked package independent of libLLVM?

I have just tested that locally a while ago, and unfortunately it didn't really work properly, doing that causes some problems but the major one is that it causes the size of lots of things to get really big and take up an additional 4 GB of space. setting only readelf to statically link to libLLVM and keeping everything else the same only increases the space used by 6 MB.

[robertkirkman]

Also, I need to find out, from other people, does installing the packages from the CI artifact from this PR make the time ldd $PREFIX/bin/ls command take more or less time than it does with the current packages from pkg install llvm ldd? If you know how to download the artifacts, could you test that and let me know?

also, the time command shows 3 times, the top one marked "real" is the real one
For me it's about the same, but I'd like to find out if on average it's faster or slower

[Andarwinux]

Maybe consider using LLVM_TOOL_LLVM_DRIVER_BUILD to build the whole llvm/clang toolchain as a statically linked package independent of libLLVM?

I have just tested that locally a while ago, and unfortunately it didn't really work properly, doing that causes some problems but the major one is that it causes the size of lots of things to get really big and take up an additional 4 GB of space. setting only readelf to statically link to libLLVM and keeping everything else the same only increases the space used by 6 MB.

LLVM_TOOL_LLVM_DRIVER_BUILD is designed to address this problem. clang, lld, and llvm-tools will be built into a single busybox-style executable to avoid bloat. see https://reviews.llvm.org/D109977

[robertkirkman]

I tried this locally: -DLLVM_LINK_LLVM_DYLIB=OFF -DLLVM_TOOL_LLVM_DRIVER_BUILD=ON, but it did what I described above.

Would you like me to upload my local test version into this PR and build it here, so that you can download the artifact and see what problem happened?

[Andarwinux]

I tried this locally: -DLLVM_LINK_LLVM_DYLIB=OFF -DLLVM_TOOL_LLVM_DRIVER_BUILD=ON, but it did what I described above.

Would you like me to upload my local test version into this PR and build it here, so that you can download the artifact and see what problem happened?

I understand. It's building a full LLVM here, not just toolchain-only. Many non-toolchain llvm-tools lack support of LLVM_TOOL_LLVM_DRIVER_BUILD.

[robertkirkman]

For me with this PR time ldd $PREFIX/bin/ls takes on average over 5 times 3.4402 seconds, but without this PR it takes 3.3716 seconds. It's a bit too close to tell but probably the same or slower, so most likely not worth the extra 14 MB of space that would be saved when clang and ldd are both installed.

• bump(main/ldd): 0.4 #28911 will be effective for optimizing ldd,
• test: fix(main/llvm): link LLVM readelf to libLLVM statically #28936 will not really be and probably won't be worth applying unless LLVM upstream makes some adjustments to the build options in the future

[TomJo2000]

I'm currently working on rebasing this branch to the latest master with Robert's findings applied.
Performing a local build test now, I expect to have the results of that in ~2 hours.

And... this was the wrong PR, this was meant for #29045.
Thanks github search.