------- 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
