On Wed, 2020-08-12 at 15:08 +0200, Jakub Jelinek wrote: > > I think it's worth adding this to bugzilla. Depending on the > > existence of empty directories seems less than ideal. > > But canonicalizing the paths without taking the filesystem state into > account will significantly change the behavior in some setups (e.g. > in presence of symlinks) and I'm not sure it is desirable.
You're right, about paths that the user provides on the command line. Those should not be modified. However, I'm talking about paths that GCC computes on its own. These are not paths taken from GCC's command line, they are paths computed by the front-end from scratch to be passed to collect2. I agree it would need to be considered carefully. As someone who takes a lot of advantage of the flexibility that tools like GCC provide I'm wary of reducing that flexibility. On the other hand I'm not sure that breaking up the internal structure of GCC's installation via symlinks in random ways is something that needs to be supported. Anyway, the user can always replace the "lib64" directory with a symlink as well. > The lib paths usually are not empty, the typical installation is > together with other programs/libraries. And even the PREFIX/lib path > should have gcc subdirectory with it with lots of files in there. I'm not talking about PREFIX/lib, though. As can be seen from my question I'm talking about PREFIX/<vendor>/<triplet>/lib. This is where GCC keeps its own internal libraries, and that directory will always be empty if you don't build a 32bit compiler. I don't think it's common at all for people to be dropping non-GCC libraries into these internal GCC directories (just from a packaging standpoint it would be a nightmare to maintain). It appears that what happens is that the frontend computes the path to the "lib" (32bit) directory, then when it wants to look for 64bit libraries instead of re-computing the path from scratch with "lib64", it just adds on a "../lib64" to the 32bit path. So maybe the right answer is to build the lib64 path using the same algorithm used to build the "lib" path, except with "lib64", rather than adding a "../lib64" to the end of the "lib" path. I'll be the first to admit I've not looked at the frontend code at all so I could be completely wrong about how it works.
