[Bug driver/21553] New: GCC_EXEC_PREFIX mechanism is broken

[Bug driver/21553] New: GCC_EXEC_PREFIX mechanism is broken

[roche at adacore dot com]

Here is what I did:
$ export GCC_EXEC_PREFIX=/my_prefix/lib/gcc/
$ gcc --print-search-dirs
install: /opt/gnu/gnat/lib/gcc/sparc-sun-solaris2.8/3.4.4/

programs: =
/libexec/gcc/sparc-sun-solaris2.8/3.4.4/:
/libexec/gcc/:
/opt/gnu/gnat/libexec/gcc/sparc-sun-solaris2.8/3.4.4/

libraries: =
/my_prefix/lib/gcc/sparc-sun-solaris2.8/3.4.4/:
/my_prefix/lib/gcc/:
/opt/gnu/gnat/lib/gcc/sparc-sun-solaris2.8/3.4.4/

here I would expect gcc to search first in /my_prefix/libexec/gcc/... for programs

looking at gcc.c it looks like the problem is coming from the following line:
 gcc_libexec_prefix = make_relative_prefix 
    (gcc_exec_prefix,
     standard_exec_prefix,
     standard_libexec_prefix);

The problem is that make_relative_prefix is expecting a program name as first
argument. But the gcc_exec_prefix is a directory. So that's why /my_prefix/ is
removed when computing gcc_libexec_prefix...

Besides this I think that since 3.4.x series GCC_EXEC_PREFIX is quite useless
indeed it is quite hard to redefine the location where cc1 is found (gcc will
always append something like ../../libexec/gcc). I think it would be better to
define another variable called GCC_LIB_PREFIX. GCC_EXEC_PREFIX will have
<gcc_location>/../libexec/gcc as default value and GCC_LIB_PREFIX will have
<gcc_location>/../lib/gcc as default value.

-- 
           Summary: GCC_EXEC_PREFIX mechanism is broken
           Product: gcc
           Version: 3.4.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: driver
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: roche at adacore dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: *-*-*
  GCC host triplet: *-*-*
GCC target triplet: *-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21553

[Bug driver/21553] GCC_EXEC_PREFIX mechanism is broken

[roche at adacore dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roche at adacore dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21553

[Bug driver/21553] GCC_EXEC_PREFIX mechanism is broken

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-13 22:53 -------
If I read the docs correctly it says you have to add -B. to the invocation.

See PR 19856 and 14435.

Reference from the docs:
In addition, the prefix is used in an unusual way in finding the directories to search for header files. For 
each of the standard directories whose name normally begins with /usr/local/lib/gcc (more precisely, 
with the value of GCC_INCLUDE_DIR), GCC tries replacing that beginning with the specified prefix to 
produce an alternate directory name. Thus, with -Bfoo/, GCC will search foo/bar where it would 
normally search /usr/local/lib/bar. These alternate directories are searched first; the standard 
directories come next. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21553

[Bug driver/21553] GCC_EXEC_PREFIX mechanism is broken

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-13 22:56 -------
Also the documenation has said since June 2001.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21553

[Bug driver/21553] GCC_EXEC_PREFIX mechanism is broken

[roche at act-europe dot fr]

------- Additional Comments From roche at act-europe dot fr  2005-05-13 23:40 -------
Subject: Re:  GCC_EXEC_PREFIX mechanism is broken

pinskia at gcc dot gnu dot org wrote:
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-13 22:53 -------
> If I read the docs correctly it says you have to add -B. to the invocation.
> 

As far as I understand, you can add -B but you don't have to.
(from the docs)
"If GCC_EXEC_PREFIX is set, it specifies a prefix to use in the names of 
the subprograms executed by the compiler"

"Other prefixes specified with -B take precedence over this prefix"

> See PR 19856 and 14435.
> 
> Reference from the docs:
> In addition, the prefix is used in an unusual way in finding the directories to search for header files. For 
> each of the standard directories whose name normally begins with /usr/local/lib/gcc (more precisely, 
> with the value of GCC_INCLUDE_DIR), GCC tries replacing that beginning with the specified prefix to 
> produce an alternate directory name. Thus, with -Bfoo/, GCC will search foo/bar where it would 
> normally search /usr/local/lib/bar. These alternate directories are searched first; the standard 
> directories come next. 
> 

I am sorry but I don't understand your comment. This paragraph of the 
documentation concerns the header files and not programs like cc1 ...

Is there something I miss ?

Futhermore the documentation says:
The default value of GCC_EXEC_PREFIX is prefix/lib/gcc/ where prefix is 
the value of prefix when you ran the configure script.

If you set explicitely the value of GCC_EXEC_PREFIX to this default, the 
driver do not behave the same way. (basically it will look first in 
prefix/../libexec/gcc/<target>/<version> instead of 
prefix/libexec/gcc/<target>/<version> for programs).

Best regards,
Nicolas



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21553

[Bug driver/21553] GCC_EXEC_PREFIX mechanism is broken

[jason_gouger at mentor dot com]

------- Additional Comments From jason_gouger at mentor dot com  2005-09-20 02:14 -------
Created an attachment (id=9778)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9778&action=view)
Patch generated with diff -e against gcc 4.0.1 - corrects gcc_libexec_prefix
when GCC_EXEC_PREFIX is set.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21553

[Bug driver/21553] GCC_EXEC_PREFIX mechanism is broken

[jason_gouger at mentor dot com]

------- Additional Comments From jason_gouger at mentor dot com  2005-09-20 02:17 -------
(In reply to comment #0)
> looking at gcc.c it looks like the problem is coming from the following line:
>  gcc_libexec_prefix = make_relative_prefix 
>     (gcc_exec_prefix,
>      standard_exec_prefix,
>      standard_libexec_prefix);
> 
> The problem is that make_relative_prefix is expecting a program name as first
> argument. But the gcc_exec_prefix is a directory. So that's why /my_prefix/ is
> removed when computing gcc_libexec_prefix...

I think there are more issues than that incorrect argument.  From what I could
see was that even though make_relative_path expects a program name the return
path discards it which may be okay.  

I am not sure on the original intent but preserving the common suffixes on arg2
and arg3 and then reapplying to the result seems to fix or at least work around
the problem.

>From make-relative-prefix.c :

For example, if @var{bin_prefix} is @code{/alpha/beta/gamma/gcc/delta},
@var{prefix} is @code{/alpha/beta/gamma/omega/}, and @var{progname} is
@code{/red/green/blue/gcc}, then this function will return
@code{/red/green/blue/../../omega/}.

progname = /red/green/blue/gcc
bin_prefix = /alpha/beta/gamma/gcc/delta
prefix = /alpha/beta/gamma/omega/
returns = /red/green/blue/../../omega/

In this case :

progname = <NEW_PATH>/gcc-Y.Y.Y/lib/gcc (gcc_exec_prefix)
bin_prefix = <COMPILE_PATH>/gcc-X.X.X/lib/gcc (standard_exec_prefix)
prefix = <COMPILE_PATH>/gcc-X.X.X/libexec/gcc (standard_libexec_prefix)
returns = <NEW_PATH>/gcc-Y.Y.Y/lib/../../libexec/gcc

1. make bin_prefix relative to prefix
   <COMPILE_PATH>/gcc-X.X.X/lib/gcc/../../libexec/gcc
2. Replace the program path '<NEW_PATH>/gcc-X.X.X/lib' (dropped prg name gcc)
   <NEW_PATH>/gcc-Y.Y.Y/lib/../../libexec/gcc

So the ../.. is caused by the fact in step one make_relative_path needed to go
up two directories.

If we strip the common suffixes of bin_prefix and prefix and then reappend we
will get the desired result.

common_suffix=/gcc
progname = <NEW_PATH>/gcc-Y.Y.Y/lib/gcc (gcc_exec_prefix)
bin_prefix = <COMPILE_PATH>/gcc-X.X.X/lib (standard_exec_prefix w/out common suffix)
prefix = <COMPILE_PATH>/gcc-X.X.X/libexec (standard_libexec_prefix w/out common
suffix)
returns = <NEW_PATH>/gcc-Y.Y.Y/lib/../libexec/gcc

1. make bin_prefix relative to prefix
   <COMPILE_PATH>/gcc-X.X.X/lib/../libexec
2. Replace the program path '<NEW_PATH>/gcc-X.X.X/lib' (dropped prg name gcc)
   <NEW_PATH>/gcc-Y.Y.Y/lib/../libexec
3. Reappend common suffix
   <NEW_PATH>/gcc-Y.Y.Y/lib/../libexec/gcc

> Besides this I think that since 3.4.x series GCC_EXEC_PREFIX is quite useless
> indeed it is quite hard to redefine the location where cc1 is found

This worked properly in gcc 3.4.3 and prior releases.

To reproduce the problem install to a non-standard location.  Remove (rename)
the build area.  Rename the non-standard location to another non-standard name
and set the GCC_EXEC_PREFIX.  In 3.4.3 this worked...

Here is a patch file against gcc 4.0.1 (gcc/gcc.c) which implements the
algorithm mentioned above.

3232,3235c
  else 
    {
      /* Find common ending of stanard_exec_prefix and standard_libexec_prefix.
      // Essentially we are stripping /gcc/ for later use... This is required
      // because make_relative path will just add ..'s for these directories.
      // This is not the intention as the make_relative_path given three 
      // paths "progname", "bin_prefix", and "prefix"; returns the path that
      // is in the same position relative to "progname's" directory as "prefix"
      // is relative to "bin_prefix".  So we can achieve the desired result by
      // stripping this common suffix and concat'ing the result */
      const char *exec_ptr = standard_exec_prefix + strlen (standard_exec_prefix);
      const char *libexec_ptr = standard_libexec_prefix + strlen
(standard_libexec_prefix);
      char *exec_buf;
      char *libexec_buf;
      char *gccexec_buf;
      int exec_len;
      int libexec_len;
      while (exec_ptr > standard_exec_prefix
             && libexec_ptr > standard_libexec_prefix
             && *exec_ptr == *libexec_ptr )
        {
          --exec_ptr;
          --libexec_ptr;
        }
      if (exec_ptr > standard_exec_prefix)
        ++exec_ptr;
      exec_len = exec_ptr - standard_exec_prefix;
      exec_buf = xmalloc(exec_len + 1);
      strncpy(exec_buf, standard_exec_prefix, exec_len);
      exec_buf[exec_len] = '\0';
      if (libexec_ptr > standard_libexec_prefix)
        ++libexec_ptr;
      libexec_len = libexec_ptr - standard_libexec_prefix;
      libexec_buf = xmalloc(libexec_len + 1);
      strncpy(libexec_buf, standard_libexec_prefix, libexec_len);
      libexec_buf[libexec_len] = '\0';
      /* NOTE: make_relative_path really takes a program name as the
      //       first argument.  However, even though it is a directory
      //       it just needs to be stripped. */
      gccexec_buf = make_relative_prefix (gcc_exec_prefix,
                                          exec_buf,
                                          libexec_buf);
      free(exec_buf);
      free(libexec_buf);
      if (gccexec_buf)
        {
          gcc_libexec_prefix = concat(gccexec_buf, exec_ptr, NULL);
          free(gccexec_buf);
        }
      else
        gcc_libexec_prefix = 0;
    }
.
w





-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21553