mozilla / mozilla/sccache

toolchain packing does not include vital symlinks

Open
#2,801 0 comments 0 reactions 0 assignees View on GitHub

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.