Hello ^_^ Ludovic Courtès <[email protected]> writes:
> Hi, > > Tomas Volf via Bug reports for GNU Guix <[email protected]> skribis: > >> 4. In the container unpack the archive and source the profile: >> >> # tar -xvf /x/pack.tar.gz >> # . xxetc/profile >> >> 5. Verify gcc starts: >> >> # gcc --version >> gcc (GCC) 16.1.0 >> Copyright (C) 2026 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is >> NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. >> >> 6. Create file and try to compile it: >> >> # echo 'int main(){}' >a.c >> # gcc a.c >> gcc: fatal error: cannot execute 'cc1': posix_spawnp: No such file or >> directory >> compilation terminated. > > It’s one of these two issues: It is both. :) > 1. ‘cc1’ cannot be found in $PATH; cc1 is not in the path, but that is expected. Same holds for regular gcc. --8<---------------cut here---------------start------------->8--- $ guix shell gcc-toolchain -- cc1 guix shell: error: cc1: command not found --8<---------------cut here---------------end--------------->8--- So not an issue. > 2. ‘cc1’ (which is under libexec/) is not wrapped and thus not > relocatable. This is also true, cc1 is not wrapped, but due to different issue. My speculation is that the wrapping code cannot handle symbolic links. In normal package, cc1 is reachable via this path: --8<---------------cut here---------------start------------->8--- /gnu/store/mas0k6vcpn0zj5qpxn5d19nqmgblvyd7-gcc-toolchain-16.1.0/libexec/gcc/x86_64-unknown-linux-gnu/16.1.0/cc1 --8<---------------cut here---------------end--------------->8--- Crucially, the `gcc' segment is a symbolic link: --8<---------------cut here---------------start------------->8--- $ ls -al /gnu/store/mas0k6vcpn0zj5qpxn5d19nqmgblvyd7-gcc-toolchain-16.1.0/libexec total 8 dr-xr-xr-x 1 root root 20 Jan 1 1970 ./ dr-xr-xr-x 1 root root 118 Jan 1 1970 ../ lrwxrwxrwx 1 root root 66 Jan 1 1970 gcc -> /gnu/store/3lj8xxr8p8lgsyrd7fd7x42a836wfbap-gcc-16.1.0/libexec/gcc lrwxrwxrwx 1 root root 70 Jan 1 1970 getconf -> /gnu/store/m31vlvwm79m89fk3xk0z4h7snk61y510-glibc-2.41/libexec/getconf --8<---------------cut here---------------end--------------->8--- However, if we contrast it with the wrapped version, we can see that the symbolic link was converted into a binary, which is probably not correct. --8<---------------cut here---------------start------------->8--- # for x in mas0k6vcpn0zj5qpxn5d19nqmgblvyd7-gcc-toolchain-16.1.0 a0njfslzh2l7jn334fh0shaspiq7prin-gcc-toolchain-16.1.0R; do ls -al /gnu/store/$x/libexec; done total 8 dr-xr-xr-x 1 root root 20 Aug 9 20:21 . dr-xr-xr-x 1 root root 118 Aug 9 20:21 .. lrwxrwxrwx 1 root root 66 Aug 9 20:21 gcc -> /gnu/store/3lj8xxr8p8lgsyrd7fd7x42a836wfbap-gcc-16.1.0/libexec/gcc lrwxrwxrwx 1 root root 70 Aug 9 20:21 getconf -> /gnu/store/m31vlvwm79m89fk3xk0z4h7snk61y510-glibc-2.41/libexec/getconf total 1408 dr-xr-xr-x 1 root root 20 Aug 9 20:21 . dr-xr-xr-x 1 root root 118 Aug 9 20:21 .. -r-xr-xr-x 1 root root 717184 Jan 1 1970 gcc -r-xr-xr-x 1 root root 717184 Jan 1 1970 getconf --8<---------------cut here---------------end--------------->8--- (The second one is the wrapped version.) > > Could you check which one it is? I do not know if the problem is the deep directory structure, or the symbolic link, but it is obviously not wrapped correctly. The immediate instinct would be to just stop wrapping libexec, and instead create a symbolic link to the original one. There should not be any reason to wrap anything in it. Alas, the current code tries (and fails), but provides no comments on why in the first place. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
