We (STM) create a directory which has symlinks to gcc and other tools and related libraries, and these symlinks point to different places. The current behaviour of gcc is to follow the gcc link, from where it won't be able to find the other tools, nor the libraries.
Created attachment 12663 [details] proposed patch The patch checks if the directory spec_machine (e.g. i686-linux), i.e. the directory where all the target libraries and assorted stuff are, can be found without following symlinks; if that is the case, it assumes that the other pieces of the toolchain should also be found without trying to resolve symlinks for generating the prefixes.
Subject: Bug 29931 Author: amylaar Date: Thu Nov 30 17:05:45 2006 New Revision: 119366 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119366 Log: include: 2006-05-03 Andrew Stubbs <andrew.stubbs@st.com> J"orn Rennecke <joern.rennecke@st.com> PR driver/29931 * libiberty.h (make_relative_prefix_ignore_links): Declare. libiberty: 2006-05-03 Andrew Stubbs <andrew.stubbs@st.com> J"orn Rennecke <joern.rennecke@st.com> PR driver/29931 * make-relative-prefix.c (make_relative_prefix_1): New function, broken out of make_relative_prefix. Make link resolution dependent on new parameter. (make_relative_prefix): Use make_relative_prefix_1. (make_relative_prefix_ignore_links): New function. Modified: trunk/include/ChangeLog trunk/include/libiberty.h trunk/libiberty/ChangeLog trunk/libiberty/make-relative-prefix.c
Fixed.
The bug is not fixed; the gcc.c patch has not been reviewed.
Author: simonb Date: Mon Feb 7 18:10:15 2011 New Revision: 169891 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169891 Log: Auto-detect suitable default behaviour for prefix canonicalization. Current gcc offers -no-canonical-prefixes to turn off realpath() for prefixes generated from the path used to address the gcc driver. This allows gcc to work in "symlink farm" installations, where every file in gcc is actually a symlink to its real contents. However, the flag has to be given explicitly. If not, the default is to use realpath() to create prefixes and the result is usually failure to find cc1[plus], f951, etc. This patch adds a check for a file as a way to auto-detect whether prefix canonicalization is appropriate or not. Detection can be overridden by using the -[no-]canonical-prefixes flags. The patch also completes the fix for PR/29931, adding code that covers the unadopted portion of this PR's attached patch. gcc/ChangeLog.google: 2011-02-07 Simon Baldwin <simonb@google.com> PR driver/29931 * doc/invoke.texi: Adjust -[no-]canonical-prefixes documentation. * gcc.c (display_help): Help text for -[no-]canonical-prefixes. (driver_handle_option): Ignore OPT_canonical_prefixes. (process_command): Handle OPT_[no_]canonical_prefixes, auto-detect suitable default prefix canonicalization mode. * common.opt (canonical-prefixes): New flag. Google ref: 40029, 38719 Modified: branches/google/integration/gcc/ChangeLog.google-integration branches/google/integration/gcc/common.opt branches/google/integration/gcc/doc/invoke.texi branches/google/integration/gcc/gcc.c
(In reply to Jorn Wolfgang Rennecke from comment #4) > The bug is not fixed; the gcc.c patch has not been reviewed. What about now, after r169891? As mentioned in the comment after you: (In reply to simonb from comment #5) > Author: simonb > Date: Mon Feb 7 18:10:15 2011 > New Revision: 169891 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169891 > Log: > Auto-detect suitable default behaviour for prefix canonicalization. > > Current gcc offers -no-canonical-prefixes to turn off realpath() for prefixes > generated from the path used to address the gcc driver. This allows gcc to > work in "symlink farm" installations, where every file in gcc is actually a > symlink to its real contents. However, the flag has to be given explicitly. > If not, the default is to use realpath() to create prefixes and the result > is usually failure to find cc1[plus], f951, etc. > > This patch adds a check for a file as a way to auto-detect whether prefix > canonicalization is appropriate or not. Detection can be overridden by > using the -[no-]canonical-prefixes flags. > > The patch also completes the fix for PR/29931, adding code that covers the > unadopted portion of this PR's attached patch. > > gcc/ChangeLog.google: > 2011-02-07 Simon Baldwin <simonb@google.com> > > PR driver/29931 > * doc/invoke.texi: Adjust -[no-]canonical-prefixes documentation. > * gcc.c (display_help): Help text for -[no-]canonical-prefixes. > (driver_handle_option): Ignore OPT_canonical_prefixes. > (process_command): Handle OPT_[no_]canonical_prefixes, auto-detect > suitable default prefix canonicalization mode. > * common.opt (canonical-prefixes): New flag. > > Google ref: 40029, 38719 > > > Modified: > branches/google/integration/gcc/ChangeLog.google-integration > branches/google/integration/gcc/common.opt > branches/google/integration/gcc/doc/invoke.texi > branches/google/integration/gcc/gcc.c
(In reply to Eric Gallager from comment #6) > (In reply to Jorn Wolfgang Rennecke from comment #4) > > The bug is not fixed; the gcc.c patch has not been reviewed. > > What about now, after r169891? As mentioned in the comment after you: > > (In reply to simonb from comment #5) > > Author: simonb > > Date: Mon Feb 7 18:10:15 2011 > > New Revision: 169891 > > > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169891 > > Log: > > Auto-detect suitable default behaviour for prefix canonicalization. > > > > Current gcc offers -no-canonical-prefixes to turn off realpath() for prefixes > > generated from the path used to address the gcc driver. This allows gcc to > > work in "symlink farm" installations, where every file in gcc is actually a > > symlink to its real contents. However, the flag has to be given explicitly. > > If not, the default is to use realpath() to create prefixes and the result > > is usually failure to find cc1[plus], f951, etc. > > > > This patch adds a check for a file as a way to auto-detect whether prefix > > canonicalization is appropriate or not. Detection can be overridden by > > using the -[no-]canonical-prefixes flags. > > > > The patch also completes the fix for PR/29931, adding code that covers the > > unadopted portion of this PR's attached patch. > > > > gcc/ChangeLog.google: > > 2011-02-07 Simon Baldwin <simonb@google.com> > > > > PR driver/29931 > > * doc/invoke.texi: Adjust -[no-]canonical-prefixes documentation. > > * gcc.c (display_help): Help text for -[no-]canonical-prefixes. > > (driver_handle_option): Ignore OPT_canonical_prefixes. > > (process_command): Handle OPT_[no_]canonical_prefixes, auto-detect > > suitable default prefix canonicalization mode. > > * common.opt (canonical-prefixes): New flag. > > > > Google ref: 40029, 38719 > > > > > > Modified: > > branches/google/integration/gcc/ChangeLog.google-integration > > branches/google/integration/gcc/common.opt > > branches/google/integration/gcc/doc/invoke.texi > > branches/google/integration/gcc/gcc.c WAITING on a reply
(In reply to Eric Gallager from comment #7) > (In reply to Eric Gallager from comment #6) > > (In reply to Jorn Wolfgang Rennecke from comment #4) > > > The bug is not fixed; the gcc.c patch has not been reviewed. > > > > What about now, after r169891? As mentioned in the comment after you: > > > > (In reply to simonb from comment #5) > > > Author: simonb > > > Date: Mon Feb 7 18:10:15 2011 > > > New Revision: 169891 > > > > > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169891 > > > Log: > > > Auto-detect suitable default behaviour for prefix canonicalization. > > > > > > Current gcc offers -no-canonical-prefixes to turn off realpath() for prefixes > > > generated from the path used to address the gcc driver. This allows gcc to > > > work in "symlink farm" installations, where every file in gcc is actually a > > > symlink to its real contents. However, the flag has to be given explicitly. > > > If not, the default is to use realpath() to create prefixes and the result > > > is usually failure to find cc1[plus], f951, etc. > > > > > > This patch adds a check for a file as a way to auto-detect whether prefix > > > canonicalization is appropriate or not. Detection can be overridden by > > > using the -[no-]canonical-prefixes flags. > > > > > > The patch also completes the fix for PR/29931, adding code that covers the > > > unadopted portion of this PR's attached patch. > > > > > > gcc/ChangeLog.google: > > > 2011-02-07 Simon Baldwin <simonb@google.com> > > > > > > PR driver/29931 > > > * doc/invoke.texi: Adjust -[no-]canonical-prefixes documentation. > > > * gcc.c (display_help): Help text for -[no-]canonical-prefixes. > > > (driver_handle_option): Ignore OPT_canonical_prefixes. > > > (process_command): Handle OPT_[no_]canonical_prefixes, auto-detect > > > suitable default prefix canonicalization mode. > > > * common.opt (canonical-prefixes): New flag. > > > > > > Google ref: 40029, 38719 > > > > > > > > > Modified: > > > branches/google/integration/gcc/ChangeLog.google-integration > > > branches/google/integration/gcc/common.opt > > > branches/google/integration/gcc/doc/invoke.texi > > > branches/google/integration/gcc/gcc.c > > WAITING on a reply Assuming this was FIXED
(In reply to Eric Gallager from comment #6) > (In reply to Jorn Wolfgang Rennecke from comment #4) > > The bug is not fixed; the gcc.c patch has not been reviewed. > > What about now, after r169891? That was only checked in on a Google branch, so this is not fixed, regardless of the below. The check-in applies almost cleanly to GCC 8.2.0, but actually testing it, I find that it does not work in my test case. I suppose it would work when all files are put together in a single directory, but that's not the only way symlinks can be used. I installed packages with DESTDIR into separate directories, and installed symlinks to the files in each of those using cp -rs. When the code checks whether spec_machine can be found, it correctly sees that it can be: GCC is one of the packages that provides that directory. As a result, -canonical-prefixes is used. However, it cannot find anything from binutils or glibc there, so things still break.
(In reply to Harald van Dijk from comment #9) > (In reply to Eric Gallager from comment #6) > > (In reply to Jorn Wolfgang Rennecke from comment #4) > > > The bug is not fixed; the gcc.c patch has not been reviewed. > > > > What about now, after r169891? > > That was only checked in on a Google branch, so this is not fixed, > regardless of the below. > > The check-in applies almost cleanly to GCC 8.2.0, but actually testing it, I > find that it does not work in my test case. I suppose it would work when all > files are put together in a single directory, but that's not the only way > symlinks can be used. I installed packages with DESTDIR into separate > directories, and installed symlinks to the files in each of those using cp > -rs. When the code checks whether spec_machine can be found, it correctly > sees that it can be: GCC is one of the packages that provides that > directory. As a result, -canonical-prefixes is used. However, it cannot find > anything from binutils or glibc there, so things still break. OK, reopening then
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.