| Issue |
172365
|
| Summary |
Cannot use clang 18.1.8 hermetically on linux
|
| Labels |
clang
|
| Assignees |
|
| Reporter |
krinkinmu
|
Hi Folks,
We are using hermetic LLVM toolchain (version 18.1.8) via Bazel to build our project. I noticed that the clang binary in the distribution depends on `libtinfo.so.5` (aka libncurses5):
```
readelf -d bin/clang-18
Dynamic section at offset 0x9c03f28 contains 36 entries:
Tag Type Name/Value
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib]
...
0x0000000000000001 (NEEDED) Shared library: [libtinfo.so.5]
...
```
And by itself it does not cause problems, but some distributions (e.g., Ubuntu) moved to a newer version of the library (`libncurses6) and when you use hermetic LLVM toolchain on a host with a newer OS it breaks because dynamic linker fails to find the library. So basically, it's not really hermetic and that both causes inconvenience and defates one of the advantages of using hermetic toolchains in the first place.
NOTE: It's still possible in principle to install an older version of `libncurses` on the newer Ubuntu system, but that requires jumping through some hoops and doing things that are not generally recommended (or safe to do) - that's not convenient to do if you know what to do, but there is additional burden of explaining it to all the people who might want to build the project from sources.
Looking at the clang binary (and other binaries in the distribution), it looks that the binaries have `RUNPATH` set that allows in principle to put all the libraries required by clang itself into the `../lib` directory (relative to the binary path) and that, if I understand correctly, should satisfy the dynamic linker and make the whole distribution hermetic (or at least more hermetic than it is now).
*Would it be possible to include at least `libtinfo` into the LLVM distributions as long as clang binary itself depends on it?*
I'm not asking to do the same with all the libraries, just the `weirder` of those that are more likely to change (e.g., I don't suggest to include `libc` or `libpthread` the same way).
I know that those seems to be released by volonteers, so I'm happy to dig into it and contribute a PR that changes scripts that generate those distributions, but I'd likely need some basic pointers (i.e., where can I find those scripts?) to get started.
Also, *would it be possible, once the fix is available, to re-publish some of the existing releases with the fix (specifically, 18.1.8 is of interest to us)?* Basically, migrating to a newer version of clang is not straighforward for a large project, so it would be quite awesome if we could update the existing published release.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
