enhancement request for gcc bootstrap and gcc binaries

[Warren L Dodge <warrend at mdhost dot cse dot tek dot com>]

I have been fighting bootstrapping gcc with an existing tree of gnu
software. It basically is the can't find libiconv problem. 

Below is some history and explanation of how I build the tools and then a
suggestion for a new configure switch for gcc.

_____________________________________________________________________________
History and Explanation

I generally build any tool I grab into a separate directory. I then put in a
common directory links from bin,include,man,lib  ... to the build directory


So in my build tree I have things like the following.  I also build for
solaris 2.5 so I completely separate the trees using the sun5.8 and
sun5.1. The paths shown below are the values I use for --prefix= in configure

        /gnu/sun5.8/less-381
        /gnu/sun5.8/make-3.80

In this dir /gnu/sun5.8 I also put links in

        less  ->        less-381
        make  ->        make-3.80

These point to the current "master" installed version.

Then in another tree I have

        /my_pathed_dir/sun5.8/bin/less  -> /gnu/sun5.8/bin/less
        /my_pathed_dir/sun5.8/bin/make  -> /gnu/sun5.8/bin/make

and similar trees for man,info,include,lib. 

I have in my path /my_pathed_dir/sun5.8/bin so that I can find all the tools
with only one path entry.

I have scripts to manage all the overhead. This allows me to easily bring in
a new version of a tool, make and install it without disturbing the working
environment. Once some testing is done I would then change the master link in
/gnu/sun5.8 to point to the new tree and leave the old one there for some
time to make sure others don't find something wrong. All the tools are nfs
mounted and used by many, so safe updating is of great importance.


So now I hope you see what I do with all the tools. So back to
libiconv. This is located in /gnu/sun5.8/libiconv-1.8/... with a link
libiconv to it. Then in /my_pathed_dir/sun5.8/lib is a link to the actual
library files.

I also have a dozen other packages which have library files in there.

_____________________________________________________________________________
Suggestion for new feature to allow more versatile library support.

So for me a great solution would be one similar to the --with-libiconv-prefix
switch. But this new switch would configure gcc and all the support tools
such that they knew where /my_pathed_dir/sun5.8 was at.

--add_this_path_to_the_specs_file=/my_pathed_dir/sun5.8

This would be used during the phases of building the compiler as the
--with-libiconv-prefix did, but it would also end up putting the appropriate
-I/my_pathed_dir/sun5.8, -L/my_pathed_dir/sun5.8, and -R/my_pathed_dir/sun5.8
entries in the specs file for both 32 and 64 bit operation.


Now the bootstrap can find everything and the resulting gcc will know where
to look for additional libraries.

I currently have added this to the gcc-3.2.3 specs file and rebuilt about 40
packages with no problems.