https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931
--- Comment #11 from Harald van Dijk <harald at gigawatt dot nl> --- Thinking about this a bit more, the logic should probably be: pick a file known to exist. libgcc.a could be a good candidate, but there could be better options. Look this up twice, once following symlinks, one without. If they both succeed, and they are the same file (comparing the dev and ino numbers after a stat() call), do not follow symlinks. If they both succeed, and they are not the same file, do follow symlinks. And if only one lookup succeeds, go with the one that succeeds. (If neither succeeds, something is seriously wrong.) This is a bit complicated, but that's because there is one case where it seems important to me to continue following symlinks: if you have two GCC builds of the same version (one probably containing a patch that the other doesn't), configured exactly the same way, install the first into its configured prefix, and the second to a custom prefix, calling the second compiler should not pick up any bits of the first.
