------- Comment #1 from kkylheku at gmail dot com 2008-02-23 01:35 ------- Created an attachment (id=15210) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15210&action=view) Patch to gcc/prefix.c for path relocation.
At some point gcc/gcc.c calls the function set_std_prefix in gcc/prefix.c to install a different prefix, overriding the original one which comes from the PREFIX variable at compile time (passed in via -DPREFIX when the file is compiled). The problem is that there is only one variable! The std_prefix variable is used to determine whether the path is inside the toolchain. However, the default substitution logic is that the key lookup for @GCC, @BINUTILS, et cetera will produce that same path. I.e. std_prefix is both the match and the default substitution, if the key doesn't resolve. And so the update_path function doesn't translate the path from the prefix to the relocated location. When the add_prefix function is called in various places in gcc.c to install search paths, in sometimes passes down paths from the original $prefix, which are recorded as string literals during compilation of gcc. These paths don't match the new prefix set up by the call to set_std_prefix, and so are entered into the list untranslated. The update_path function should use the original prefix to match against input paths, but then substitute the new path (if the @ translation doesn't produce any match). E.g. the path /original/libexec/bin should become (for example, if the key is "GCC") @GCC/libexec/bin. Then the @GCC substituion finds that the environment variable GCC_ROOT is not defined, and so substitutes /new to make /new/libexec/bin. Don't know if the current GCC has the problem, but a superficial skim through gcc/prefix.c tells me that nothing has changed there. So either the problem is not solved, or it's addressed by other logic elsewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
