http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48520
--- Comment #2 from tim.vanholder at anubex dot com 2011-04-11 06:56:27 UTC ---
Fair enough.
However, this was the _only_ (noticeable) breakage resulting from this
configuration.
If that's really all there is I don't see why this couldn't/shouldn't simply be
handled by the makefile rule.
Also, I don't really understand why it's ok for "make install" to silently
ignore errors during the creation of the (hard links to the) binaries in the
installation tree. That seems to be a rather fundamental aspect of "make
install".
If there are more (hidden) breakages resulting from this, maybe this
"program-prefix should not be '<target>-'" rule should be enforced by configure
(as far as I can tell, it's not mentioned anywhere in the source tree).
In fact, gcc/configure currently includes
# The aliases save the names the user supplied, while $host etc.
# will get canonicalized.
test -n "$target_alias" &&
test "$program_prefix$program_suffix$program_transform_name" = \
NONENONEs,x,x, &&
program_prefix=${target_alias}-
so it even explictly sets the program prefix to the target_alias (if one is
given), meaning that even if I had not explicitly given
--program-prefix=mingw32-, configure would have set that up for me
automatically (provided I also left off the --program-suffix, which for a
cross-compiler would not be entirely needed either).
So I guess the only issue is when both prefix & suffix are set to the standard
ones used during installation, which should be handled perfectly well by
adjusting gcc/Makefile.am to only do the rm+ln if GCC_INSTALL_NAME does not
match the canon_target-gcc-version construct.
