This is a kind of esoteric problem, but all the more annoying for that. As usual I've built my own version of GCC, and then I check it into Git so that all builds can use this one canonical compiler regardless of operating system, etc.
After being checked into Git, the compiler started failing to link with an error that it could not find libgcc_s.so, even though it exists in exactly the same place (relatively) as it was before. After some debugging and strace-ing, I discovered that in the failure mode the front-end didn't provide this flag to collect2, which is where libgcc_s.so lives: -L/.../cc/unknown/bin/../lib/gcc/x86_64-unknown-linux-gnu/10.2.0/../../../../x86_64-unknown-linux-gnu/lib/../lib64/. The problem is this: when I built this compiler I only built the 64bit version of it, not the 32bit version. As a result, the lib/. directories are empty: only the lib64 directories have any content. When I check this into Git, of course all empty directories are ignored. So while the /.../cc/unknown/x86_64-unknown-linux-gnu/lib64 directory, where 64bit libgcc_s.so lives, does exist, the /.../cc/unknown/x86_64-unknown-linux-gnu/lib directory doesn't exist, which means the above path cannot be resolved. Of course, I can force the lib directory to exist by adding a dummy file there and I will do so. However, it seems to me that it would be better if GCC would apply a simplifying function to pathnames to reduce all the "/.." elements, before it starts looking for directories, to avoid failing if some unnecessary element doesn't exist. This shouldn't be too difficult since the path will be either the same length as, or shorter than, the original so there's no need to reallocate memory etc.: it can be updated in place. Oddly, I looked through the gnulib library and didn't find any appropriate module for this. It seems like there should be one. Anyway, not sure what people think and whether this is worth an enhancement request in bugzilla.
