toolchain packing does not include vital symlinks #2801

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)