[Bug driver/19353] Faulty handling of startfile_prefix_spec

["ryan dot oliver at pha dot com dot au" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From ryan dot oliver at pha dot com dot au  2005-02-08 07:22 -------
(In reply to comment #5)
> The patch was approved by the RM here:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00850.html
> 
> but it is still not applied. It would be great if you could pls commit this
> patch then close the BZ.
> 
> Many thanks.

Greetings, coming in a bit late here...

I have noticed that startfile_prefix_spec is still handled by the driver as of
20050208.

I would personally not like to see this feature go, as it is incredibly useful
when building multilib toolchains (be it native or cross) where the startfiles
and libraries are not located in standard locations, and not located under the
prefix the compiler was installed to. Fair enough nothing internal to the gcc
build still uses it, but it still has a use...

Main thing it facilitates is building a multilib gcc linked against c-libraries
in a non standard location (te create a self hosted toolchain)
 
Use of -B/target/lib to specify the location of startfiles will not fly, you end
up linking in 32bit startfiles into your 64bit libgcc. Unless there is another
mechanism for specifying the location, and have it get adjusted by the multilib
spec, multilib gcc builds in this scenario aren't possible (without much hackery
and pain).

Here the simple adjustment of startfile_prefix_spec to /target/lib/ ensures
everything will build correctly.

It also proves invaluable when cross-compiling a self-hosted toolchain for a
multilib target w/o using --with-sysroot (which isn't appropriate in all
circumstances)

I do hope that you will reconsider the full application of this patch, true it
wont take a lot to maintain a patch which reverts these changes, but I surely
would prefer to not have to do so...

-- 


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