Bug 29931 - following argv[0] symlink in process_command breaks symlinked-together toolchain
Summary: following argv[0] symlink in process_command breaks symlinked-together toolchain
Status: REOPENED
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: patch
Depends on:
Blocks: 29842
  Show dependency treegraph
 
Reported: 2006-11-21 17:15 UTC by Jorn Wolfgang Rennecke
Modified: 2021-11-27 01:24 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-02-11 20:17:10


Attachments
proposed patch (2.29 KB, patch)
2006-11-21 17:17 UTC, Jorn Wolfgang Rennecke
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jorn Wolfgang Rennecke 2006-11-21 17:15:39 UTC
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.
Comment 1 Jorn Wolfgang Rennecke 2006-11-21 17:17:45 UTC
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.
Comment 2 Jorn Wolfgang Rennecke 2006-11-30 17:06:01 UTC
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

Comment 3 Andrew Pinski 2006-12-03 21:32:52 UTC
Fixed.
Comment 4 Jorn Wolfgang Rennecke 2006-12-04 14:27:11 UTC
The bug is not fixed; the gcc.c patch has not been reviewed.
Comment 5 simonb 2011-02-07 18:10:21 UTC
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
Comment 6 Eric Gallager 2017-09-16 23:10:41 UTC
(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
Comment 7 Eric Gallager 2018-06-17 04:36:51 UTC
(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
Comment 8 Eric Gallager 2018-09-17 19:53:09 UTC
(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
Comment 9 Harald van Dijk 2018-09-21 16:44:07 UTC
(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.
Comment 10 Eric Gallager 2018-09-21 23:57:32 UTC
(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
Comment 11 Harald van Dijk 2019-08-11 14:09:46 UTC
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.