Re: libg++ (again)

Re: libg++ (again)

[H.J. Lu]

> 
> On Wed, 11 March 1998, 20:07:00, jkj@sco.com wrote:
> 
>  > Ok.
>  > Got libstdc++2.8.1. Got libg++2.8.1. Moves the extracted libg++2.8.1 into
>  > libstdc++ directory and called it "libg++". Which, by the way, the
>  > README doesnt tell you to do. Do a configure inthe main dir, start the
>  > make, and everything works to a point. First think it barfs on it a
>  > lack of "rx.h" ... did GNU rx used to be in this package somewhere?
>  > Then start make again and it gets further, this time stopping due to:
>  > 'No rule to make target libgxx.list'.
>  > 
>  > This is on a multi-libbed target, if that makes any difference.
> 
> Who packaged this file? The directory librx is missing, and I'd
> suppose adding the README.libg++ file wouldn't be bad, either.
> 

Jeff, could you please install my egcs/configure patch? libstdc++
2.8.1 has it. But egcs doesn't. People still need to apply my patch
contained in README.libg++ if they want to use it as the libg++ addon
for egcs. Thanks.

> We should simply take H.J.'s file from
> 
>   < ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.1-980306.tar.gz >
> 
> rename it to libg++-2.8.1.tar.gz and copy it ASAP over the existing
> one on ftp.gnu.org!
> 
> manfred
> 


-- 
H.J. Lu (hjl@gnu.org)

Re: libg++ (again)

[Manfred Hollstein]

On Thu, 12 March 1998, 08:22:04, hjl@lucon.org wrote:

 > > 
 > > On Wed, 11 March 1998, 20:07:00, jkj@sco.com wrote:
 > > 
 > >  > Ok.
 > >  > Got libstdc++2.8.1. Got libg++2.8.1. Moves the extracted libg++2.8.1 into
 > >  > libstdc++ directory and called it "libg++". Which, by the way, the
 > >  > README doesnt tell you to do. Do a configure inthe main dir, start the
 > >  > make, and everything works to a point. First think it barfs on it a
 > >  > lack of "rx.h" ... did GNU rx used to be in this package somewhere?
 > >  > Then start make again and it gets further, this time stopping due to:
 > >  > 'No rule to make target libgxx.list'.
 > >  > 
 > >  > This is on a multi-libbed target, if that makes any difference.
 > > 
 > > Who packaged this file? The directory librx is missing, and I'd
 > > suppose adding the README.libg++ file wouldn't be bad, either.
 > > 
 > 
 > Jeff, could you please install my egcs/configure patch? libstdc++
 > 2.8.1 has it. But egcs doesn't. People still need to apply my patch
 > contained in README.libg++ if they want to use it as the libg++ addon
 > for egcs. Thanks.
 > 

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.

I've used it since several months (and yes, even while building in
srcdir and even with multilibs, too ;-) without any problems - it's
really safe to be put into the release and the main trunk.

Just my 2 cents...

manfred

Re: libg++ (again)

[Alexandre Oliva]

Manfred Hollstein writes:

>> Jeff, could you please install my egcs/configure patch? libstdc++
>> 2.8.1 has it. But egcs doesn't. People still need to apply my patch
>> contained in README.libg++ if they want to use it as the libg++ addon
>> for egcs. Thanks.

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

I second (third? :-) that.  I've used this patch myself too, on the
eight different platforms I build both gcc and egcs regularly, and it
did fine.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: libg++ (again)

[Jeffrey A Law]

  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.

jeff

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

[Manfred Hollstein]

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.

diff -rcp -x CVS -x *.o -x *.info* -x *.html* -x *.elc -x *.dvi -x *.orig -x *~ -x version.el egcs-1.0.2.orig/configure egcs-1.0.2/configure
*** egcs-1.0.2.orig/configure	Wed Dec  3 16:54:34 1997
--- egcs-1.0.2/configure	Sat Mar  7 19:56:34 1998
*************** for subdir in . ${subdirs} ; do
*** 992,1018 ****
                  set ${links}; link=$1; shift; links=$*
  
                  if [ ! -r ${srcdir}/${file} ] ; then
                          echo '***' "${progname}: cannot create a link \"${link}\"," 1>&2
                          echo '***' "since the file \"${srcdir}/${file}\" does not exist." 1>&2
                          exit 1
                  fi
  
                  ${remove} -f ${link}
  		# Make a symlink if possible, otherwise try a hard link
! 		if ${symbolic_link} ${srcdir}/${file} ${link} >/dev/null 2>&1 ; then
  			true
  		else
  			# We need to re-remove the file because Lynx leaves a 
  			# very strange directory there when it fails an NFS symlink.
  			${remove} -r -f ${link}
! 			${hard_link} ${srcdir}/${file} ${link}
  		fi
                  if [ ! -r ${link} ] ; then
!                         echo '***' "${progname}: unable to link \"${link}\" to \"${srcdir}/${file}\"." 1>&2
                          exit 1
                  fi
  
!                 echo "Linked \"${link}\" to \"${srcdir}/${file}\"."
          done
  
          # Create a .gdbinit file which runs the one in srcdir
--- 993,1026 ----
                  set ${links}; link=$1; shift; links=$*
  
                  if [ ! -r ${srcdir}/${file} ] ; then
+                   if [ ! -r ${file} ] ; then
+ 		    
                          echo '***' "${progname}: cannot create a link \"${link}\"," 1>&2
                          echo '***' "since the file \"${srcdir}/${file}\" does not exist." 1>&2
                          exit 1
+ 		  else
+ 			srcfile=${file}
+ 		  fi
+ 		else
+ 			srcfile=${srcdir}/${file}
                  fi
  
                  ${remove} -f ${link}
  		# Make a symlink if possible, otherwise try a hard link
! 		if ${symbolic_link} ${srcfile} ${link} >/dev/null 2>&1 ; then
  			true
  		else
  			# We need to re-remove the file because Lynx leaves a 
  			# very strange directory there when it fails an NFS symlink.
  			${remove} -r -f ${link}
! 			${hard_link} ${srcfile} ${link}
  		fi
                  if [ ! -r ${link} ] ; then
!                         echo '***' "${progname}: unable to link \"${link}\" to \"${srcfile}\"." 1>&2
                          exit 1
                  fi
  
!                 echo "Linked \"${link}\" to \"${srcfile}\"."
          done
  
          # Create a .gdbinit file which runs the one in srcdir

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

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

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

[Jim Wilson]

The patch looks OK to me.  Go ahead and check it in to the current sources.
I will leave it for Jeff to decide whether it gets into the 1.0.2 release.

Jim

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

[H.J. Lu]

> 
> The patch looks OK to me.  Go ahead and check it in to the current sources.
> I will leave it for Jeff to decide whether it gets into the 1.0.2 release.

Thanks. I haven't setup the CVS write yet. Could you please install
it? BTW, I'd like to see it in 1.0.2 also.

Thanks a lot.

-- 
H.J. Lu (hjl@gnu.org)

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

[Manfred Hollstein]

On Mon, 16 March 1998, 12:52:04, hjl@lucon.org wrote:

 > > 
 > > The patch looks OK to me.  Go ahead and check it in to the current sources.
 > > I will leave it for Jeff to decide whether it gets into the 1.0.2 release.
 > 
 > Thanks. I haven't setup the CVS write yet. Could you please install
 > it? BTW, I'd like to see it in 1.0.2 also.

Installed (into the snapshot sources).

manfred