Re: libg++ (again) - patch and rationale included.

[hjl@lucon.org (H.J. Lu)]

> 
> On Fri, 13 March 1998, 13:42:57, law@cygnus.com wrote:
> 
>  > 
>  >   In message < 13576.55644.732642.790993@slsvhmt >you write:
>  >   > As H.J. tried this several times now with no luck, perhaps it might
>  >   > help to tell you, this patch is _really necessary_ and _fixes a real
>  >   > bug_ in the configure mechanism.
>  > It's just blocked behind egcs-1.0.2 stuff.  That's been my primary
>  > egcs concern for the last several weeks.
>  > 
>  > You might submit the patch as well as the rationale behind the patch again --
>  > Jim may be able to take care of it while I work on 1.0.2 stuff.
> 
> I know it's late (perhaps too late), but I guess H.J. wanted this
> patch to be put into the release as well (me too).
> 
> OK, here's the rationale:
> 
> On Sun, 1 February 1998, 15:04:40, hjl@lucon.org wrote:
> 
>  > > 
>  > > I don't understand why we need the second patch.  I've configured
>  > > and used egcs with absolute pathnames for a long time without
>  > > running into these kinds of problems.
>  > > 
>  > 
>  > That is because some systems use the system regex.h/rx.h instead of
>  > the one included in librx. But configure.in doesn't know how to
>  > make a symlink to /usr/include/foo.h since it assumes symlink pathname
>  > is always relative.
>  > 
>  > -- 
>  > H.J. Lu (hjl@gnu.org)
> 
> And here's the patch:
> 
> Mon Aug 25 17:31:49 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)
> 
> 	* configure: When making link, also check the current
> 	directory. The configure scripts may create one.
> 

This may not be very clear. Basically, the source of the symlink may
be outside of the egcs source tree. In case of libg++ on Linux, it is
/usr/include/rx.h or /usr/include/regex.h. The current configure
assumes the source of the symlink is always inside the egcs source
tree. My patch corrects it.

Thanks.

H.J.