Daniel Jacobowitz wrote:
On Sat, Apr 15, 2006 at 09:46:24AM +0100, Dave Murphy wrote:
No, this patch is not correct. Take a wander through set_std_prefix
and the call to update_path in add_prefix.
Here's another attempt at a patch which fixes the problem for me,
including the translation of the include paths. I'm still not sure this
is correct
set_std_prefix is called quite early on and sets the root of the
installed toolchain. Since update_path checks for a match against
std_prefix before translating the paths translation only happens on
paths that don't actually require it. Checking against the configured
prefix instead fixes this problem for the gcc executable. The check of
standard_exec_prefix/just_machine_suffix/specs uses the hard coded
standard_exec_prefix causes another access to the old location. Using
the translated gcc_exec_prefix fixes this.
cc1 and cc1plus never call set_std_prefix so their calls to update_path
are not aware that the toolchain has been moved. I noticed that gcc sets
GCC_EXEC_PREFIX to a string which it later uses in the call to
set_std_prefix. Moving the putenv from gcc.c to set_std_prefix in
prefix.c and adding a call to set_std_prefix in toplev.c with the string
from GCC_EXEC_PREFIX fixes this.
Updating and using GCC_EXEC_PREFIX like this feels like the wrong thing
to do though. Would it be better to use another name for this purpose,
STD_PREFIX for example?
I've also been looking for a PR in bugzilla but can't seem to find one
for this issue. Could someone point me in the right direction if there
is one?
Dave
diff -Naurb gcc-4.1.0/gcc/gcc.c gcc-4.1.0-arm/gcc/gcc.c
--- gcc-4.1.0/gcc/gcc.c Sat Jan 21 18:29:08 2006
+++ gcc-4.1.0-arm/gcc/gcc.c Fri May 5 10:18:31 2006
@@ -3250,8 +3250,6 @@
gcc_libexec_prefix = make_relative_prefix (argv[0],
standard_bindir_prefix,
standard_libexec_prefix);
- if (gcc_exec_prefix)
- putenv (concat ("GCC_EXEC_PREFIX=", gcc_exec_prefix, NULL));
}
else
gcc_libexec_prefix = make_relative_prefix (gcc_exec_prefix,
@@ -6148,10 +6146,10 @@
/* We need to check standard_exec_prefix/just_machine_suffix/specs
for any override of as, ld and libraries. */
- specs_file = alloca (strlen (standard_exec_prefix)
+ specs_file = alloca (strlen (gcc_exec_prefix)
+ strlen (just_machine_suffix) + sizeof ("specs"));
- strcpy (specs_file, standard_exec_prefix);
+ strcpy (specs_file, gcc_exec_prefix);
strcat (specs_file, just_machine_suffix);
strcat (specs_file, "specs");
if (access (specs_file, R_OK) == 0)
diff -Naurb gcc-4.1.0/gcc/prefix.c gcc-4.1.0-arm/gcc/prefix.c
--- gcc-4.1.0/gcc/prefix.c Sat Jun 25 03:02:01 2005
+++ gcc-4.1.0-arm/gcc/prefix.c Fri May 5 10:18:51 2006
@@ -246,13 +246,16 @@
The returned string is always malloc-ed, and the caller is
responsible for freeing it. */
+
+static const char *old_prefix = PREFIX;
+
char *
update_path (const char *path, const char *key)
{
char *result, *p;
- const int len = strlen (std_prefix);
+ const int len = strlen (old_prefix);
- if (! strncmp (path, std_prefix, len)
+ if (! strncmp (path, old_prefix, len)
&& (IS_DIR_SEPARATOR(path[len])
|| path[len] == '\0')
&& key != 0)
@@ -354,4 +357,6 @@
set_std_prefix (const char *prefix, int len)
{
std_prefix = save_string (prefix, len);
+
+ putenv (concat ("GCC_EXEC_PREFIX=", std_prefix, NULL));
}
diff -Naurb gcc-4.1.0/gcc/toplev.c gcc-4.1.0-arm/gcc/toplev.c
--- gcc-4.1.0/gcc/toplev.c Sat Feb 4 22:13:20 2006
+++ gcc-4.1.0-arm/gcc/toplev.c Wed Apr 26 16:49:36 2006
@@ -82,6 +82,7 @@
#include "value-prof.h"
#include "alloc-pool.h"
#include "tree-mudflap.h"
+#include "prefix.h"
#if defined (DWARF2_UNWIND_INFO) || defined (DWARF2_DEBUGGING_INFO)
#include "dwarf2out.h"
@@ -1434,6 +1435,10 @@
progname = p;
xmalloc_set_program_name (progname);
+
+ p = getenv("GCC_EXEC_PREFIX");
+ set_std_prefix (p, strlen(p));
+
hex_init ();
