toolchain packing does not include vital symlinks
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 7.7k
- Forks
- 748
- Avg merge
- 4d 7h
- Merged PRs (30d)
- 21
Description
Today I tried sccache distributed compiling and it failed by not finding a .so that the cc1plus process was linked to:
sccache: Job failed on server 127.0.0.1:10501: /opt/arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi/bin/../libexec/gcc/arm-none-eabi/14.2.1/cc1plus: error while loading shared libraries: libzstd.so.1: cannot open shared object file: No such file or directory
upon further investigation the file /lib64/glibc-hwcaps/x86-64-v3/libzstd.so.1.5.7 was successfully copied, and it indeed is the one that would be needed, however according to ldd ld.so is looking for libzstd.so.1
# ldd /opt/arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi/libexec/gcc/arm-none-eabi/14.2.1/cc1plus
linux-vdso.so.1 (0x00007ffd7c5e2000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000707b9e62d000)
libzstd.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libzstd.so.1.5.7 (0x0000707b9e54e000)
and indeed if I put that symlink manually into the correct place in the toolchains directory of the overlay fs, cc1plus will run (I get a problem that it cannot execute as later though, but thats probably another issue).
Upon having a quick look at src/dist/pkg.rs parse_ldd_ouptut (note that I don't know much about rust so I might be wrong) it seems to me that it parses dhe => output and only takes the right side, the full path. But for the loader to correctly find it, the symlink must be there too (in fact, creating all these symlinks is a common task done by ldconfig so maybe no matter the part before => the ldconfig behaviour should be replicated and those symlinks always be generated. Note that it comes from the SONAME field of the shared object file)
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in src/dist/pkg.rs at parse_ldd_ouptut and trace how shared-library paths are collected for a packed toolchain. Reproduce the distributed compile failure with the arm-none-eabi toolchain, then verify that the resulting overlay contains the library lookup link needed by cc1plus and that the compile proceeds past the missing libzstd.so.1 error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, rust
- Domain
- build-system, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100