[PATCH] GCC_EXEC_PREFIX (consider for 2.95)

[Donn Terry <donn at interix dot com>]

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================
Bug: GCC_EXEC_PREFIX doesn't work correctly unless it's followed by
TWO slashes.  (I consider this an "embarrasing" bug, and should be
considered for 2.95 as well as the main line.)

Try:
   GCC_EXEC_PREFIX=xyzzy/usr/contrib/ ./gcc -print-search-dirs

You'll get something like (after a little reformtting for readability):
install:
 //C/Interix//usr/contrib/lib/gcc-lib/i386-pc-interix/gcc-2.95/
programs:
 xyzzy/usr/contribi386-pc-interix/gcc-2.95/:
 xyzzy/usr/contrib:
 ...

Note the missing slash between contrib and i386-pc-interix.  If I change
the command to use "...contrib//", one slash appears (and everything
works!).


Scenario (all line numbers approximate, of course):
(Ignoring for the discussion the issue of varying directory separators.)

Set GCC_EXEC_PREFIX to a value with a trailing slash.

This is pulled from the environment by GET_ENV_PATH list at
line 2584 of gcc.c.

At line 2619, it is passed to set_std_prefix(), and becomes the
value of std_prefix (unmodified unless it contains /lib/gcc-lib).

add_prefix is then called at line 2620, with the value for "component"
non-null ("GCC").  add_prefix calls update_path with that value
which in turn calls translate_name (both in prefix.c).
translate_name sees a non-null key value, and std_prefix matches
path (guaranteed, see line 2619 above), so it calls translate_name
with the key "GCC".

Using the key GCC translate_name calls get_key_value, which 
(if GCC_ROOT is not set) returns the value of std_prefix.
At line 278 of translate_name, the trailing / found in std_prefix (now
called just prefix) is deleted.

This name, without the slash, is returned as "path" in update_path
(line 303), and becomes the result of update_path.  So now we have
the value, without a /, as the value of prefix in add_prefix.

If I understand things correctly, and from looking at various examples
including the call to add_prefix() associated with the -B option,
the names that add_prefix is supposed to be adding should always end
with /.  (Certainly if -B doesn't end in /, it doesn't usually work.)

Fix:

Since I don't see a compelling reason to delete the slash in prefix.c,
I suggest simply deleteing that code.  That may cause an occasional
imbedded //, but it's better than omitting one!

This has been regressed using my usual regression (a heavy-duty 3
stage boot), and passes.  I've also manually checked that it works 
correctly, since it appears that none of the standard regressions check this.

ChangeLog:

	* prefix.c (translate_name): Don't strip trailing DIR_SEPARATOR.

diff -urP egcs.source.old/gcc/prefix.c egcs.source/gcc/prefix.c
--- egcs.source.old/gcc/prefix.c	Sat Apr 10 10:08:45 1999
+++ egcs.source/gcc/prefix.c	Wed Jul  7 13:03:36 1999
@@ -274,6 +274,9 @@ translate_name (name)
   if (prefix == 0)
     prefix = PREFIX;
 
+#if 0
+  /* This is a bad idea, because it sometimes can yield a result with
+     no separator, causing two path components to run together. */
   /* Remove any trailing directory separator from what we got.  */
   if (IS_DIR_SEPARATOR (prefix[strlen (prefix) - 1]))
     {
@@ -281,6 +284,7 @@ translate_name (name)
       temp[strlen (temp) - 1] = 0;
       prefix = temp;
     }
+#endif
 
   return concat (prefix, name, NULL_PTR);
 }