libg++-980119 wouldn't build with egcs-980129 (patch)

libg++-980119 wouldn't build with egcs-980129 (patch)

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

Hi!

Some interfaces between configure scripts were changed in last
snapshot, in a way that libg++ was broken.  Here's a patch that
updates libg++'s configure files so that it builds with the latest
egcs snapshot.

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

[-- Attachment #2: libg++-egcs-980129.diff.gz --]
[-- Type: application/x-gzip, Size: 1435 bytes --]

Re: libg++-980119 wouldn't build with egcs-980129 (patch)

[Franz Sirl]

Hi,

Manfred Hollstein already posted a patch for libg++ when he posted the
configure fixes. Look in the egcs-bugs archive.
But I wonder when the configure patch (minus the alpha part) mentioned in
README.libg++ will finally be integrated ;-). It's from August last year!

Bye,
Franz.


At 22:28 Uhr -0000 31.01.1998, Alexandre Oliva wrote:
>Hi!
>
>Some interfaces between configure scripts were changed in last
>snapshot, in a way that libg++ was broken.  Here's a patch that
>updates libg++'s configure files so that it builds with the latest
>egcs snapshot.
>
>--
>Alexandre Oliva
> mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
> http://www.dcc.unicamp.br/~oliva
>Universidade Estadual de Campinas, SP, Brasil
>
>Content-Type: application/octet-stream; type=gzip
>Content-Disposition: attachment; filename="libg++-egcs-980129.diff.gz"
>
>Attachment converted: System:libg++-egcs-980129.diff.gz (????/----) (00008F45)

Re: libg++-980119 wouldn't build with egcs-980129 (patch)

[Jeffrey A Law]

  In message < v03130301b0f9f1ec9714@[195.180.235.232] >you write:
  > Hi,
  > 
  > Manfred Hollstein already posted a patch for libg++ when he posted the
  > configure fixes. Look in the egcs-bugs archive.
  > But I wonder when the configure patch (minus the alpha part) mentioned in
  > README.libg++ will finally be integrated ;-). It's from August last year!
Can someone send a copy of this patch to the list?

jeff

Re: libg++-980119 wouldn't build with egcs-980129 (patch)

[Franz Sirl]

At 9:20 Uhr -0000 01.02.1998, Jeffrey A Law wrote:
>  In message < v03130301b0f9f1ec9714@[195.180.235.232] >you write:
>  > Hi,
>  >
>  > Manfred Hollstein already posted a patch for libg++ when he posted the
>  > configure fixes. Look in the egcs-bugs archive.
>  > But I wonder when the configure patch (minus the alpha part) mentioned in
>  > README.libg++ will finally be integrated ;-). It's from August last year!
>Can someone send a copy of this patch to the list?
>
>jeff

It's in the archive:
< http://www.cygnus.com/ml/egcs/1997-Oct/1067.html >

Bye,
Franz.


Ciao,
Franz.

--
--------------------------------------------------------------------------
URLs	< mailto:Franz.Sirl@munich.netsurf.de >
	< http://homepages.munich.netsurf.de/Franz.Sirl >
--------------------------------------------------------------------------

Re: libg++-980119 wouldn't build with egcs-980129 (patch)

[Jeffrey A Law]

  In message < v03130303b0f9ff78c629@[195.180.235.207] >you write:
  > >Can someone send a copy of this patch to the list?
  > >
  > >jeff
  > 
  > It's in the archive:
  > < http://www.cygnus.com/ml/egcs/1997-Oct/1067.html >
Thank you.

egcs already has the patch to configure.in.

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.

jeff

Re: libg++-980119 wouldn't build with egcs-980129 (patch)

[H.J. Lu]

> 
> 
>   In message < v03130303b0f9ff78c629@[195.180.235.207] >you write:
>   > >Can someone send a copy of this patch to the list?
>   > >
>   > >jeff
>   > 
>   > It's in the archive:
>   > < http://www.cygnus.com/ml/egcs/1997-Oct/1067.html >
> Thank you.
> 
> egcs already has the patch to configure.in.
> 
> 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)

Re: libg++-980119 wouldn't build with egcs-980129 (patch)

[Franz Sirl]

At 20:53 Uhr -0000 01.02.1998, Jeffrey A Law wrote:
>  In message < v03130303b0f9ff78c629@[195.180.235.207] >you write:
>  > >Can someone send a copy of this patch to the list?
>  > >
>  > >jeff
>  >
>  > It's in the archive:
>  > < http://www.cygnus.com/ml/egcs/1997-Oct/1067.html >
>Thank you.
>
>egcs already has the patch to configure.in.
>
>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.

But I still have this problems. I had to install this patch both in 1.0.1
and current CVS to avoid exactly the error mentioned in the archive. Either
this was reintroduced with Manfred's patches (I couldn't build CVS before
because of the jumptable problem) or is not solved under all circumstances.
H.J, what do you think?

My CVS tree was configured like this:
cd egcs-cvs
tar -xvzf libg++-980119.tar.gz
patch <(manfred's libg++ patch for current cvs)
mkdir objdir
cd objdir
../configure --prefix=/usr --enable-shared --with-gnu-as --with-gnu-ld
--disable-multilib
make bootstrap

Bye,
Franz.

Re: libg++-980119 wouldn't build with egcs-980129 (patch)

[H.J. Lu]

> >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.
> 
> But I still have this problems. I had to install this patch both in 1.0.1
> and current CVS to avoid exactly the error mentioned in the archive. Either
> this was reintroduced with Manfred's patches (I couldn't build CVS before
> because of the jumptable problem) or is not solved under all circumstances.
> H.J, what do you think?
> 

configure doesn't know how to make a symlink from a absolute
pathname. My patch fixes it.


H.J.

libg++ 2.8.1 980201 is released.

[H.J. Lu]

> 
> Some interfaces between configure scripts were changed in last
> snapshot, in a way that libg++ was broken.  Here's a patch that

Thanks. Manfred Hollstein sent me a similar patch earlier. Alexandre,
I didn't include your patch for libg++/src/configure.in which commented
out the rx.h dectection on linux.

> updates libg++'s configure files so that it builds with the latest
> egcs snapshot.
> 

I just made libg++ 2.8.1 980201. It seems to work with both egcs
980129 and libstdc++ 2.8.0.

Thanks.


H.J.
---
This is a libg++ addon for libstdc++ 2.8.x and egcs. It is needed only
if your applications depend on libg++ and the dependency on libg++
cannot be removed easily. The standalone libg++ is not longer needed.

The libg++ and librx have been tested with

1. egcs 980129 on linux/x86/libc 5, linux/x86/glibc 2.0.5c,
   linux/x86/glibc 2.1 and linux/alpha/glibc 2.0.6.
2. gcc 2.8.0 971225 and libstdc++ 2.8.0 on linux/x86/libc 5.

It is available at

ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.1-980201.tar.gz

Patch for libg++ 2.8.1 980119 is also available at

ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.1-980119-980201.diff.gz

Just put libg++ and librx under the egcs or libstdc++ source directory,
i.e.,

# cd src/egcs
# gzip -dc xxxxxx/libg++-2.8.1-980201-tar.gz | tar xf -

Or

# cd src/libstdc++-2.8.x
# gzip -dc xxxxxx/libg++-2.8.1-980201-tar.gz | tar xf -

Potential problems with libstdc++ 2.8.x:

1. Since gcc 2.8.0 is installed under /usr on Linux/GNU, libstdc++
   should be modified to reflect it. Otherwise incorrect header files
   and libraries may be used. A patch is available upon request.
2. libstdc++ 2.8.0 may not support glibc 2.1. "make check" may fail
   on systems using glibc 2.1. A patch is available at

   ftp://ftp.yggdrasil.com/private/hjl/egcs-971201.io.diff.gz

3. When --disable-multilib is used to configure libstdc++ 2.8.0,
   "make check" may fail in libio due to a bug in dejagnu which
   cannot find the build directory for libio. You can either
   fix dejagnu or don't use dejagnu in libstdc++ 2.8.0. A patch for
   libstdc++ 2.8.0 is also available upon request.

You also need to check configure.in and configure to see if the
patch enclosed here is already applied. If not, please do

# patch -p0 < README.libg++

Then you can configure/build/check/install egcs normally. Now it
will include libg++.


H.J. Lu
hjl@gnu.org
02/01/1998
--- 
Sun Sep  7 14:27:56 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

	* configure.in (alpha*-*-linux*): Treat alpha*-*-linux* as
	alpha*-*-linux* and alpha*-*-*.

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.

Index: configure.in
===================================================================
RCS file: /home/work/cvs/gnu/egcs/configure.in,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 configure.in
--- configure.in	1997/09/17 20:09:19	1.1.1.4
+++ configure.in	1997/10/23 00:01:53
@@ -416,6 +507,12 @@
   alpha*-*-*vms*)
     noconfigdirs="$noconfigdirs gdb ld target-newlib target-libgloss"
     ;;
+  alpha*-*-linux*)
+    # newlib is not 64 bit ready
+    noconfigdirs="$noconfigdirs target-newlib target-libgloss"
+    # linux has rx in libc
+    skipdirs="$skipdirs target-librx"
+    ;;
   alpha*-*-*)
     # newlib is not 64 bit ready
     noconfigdirs="$noconfigdirs target-newlib target-libgloss"
Index: configure
===================================================================
RCS file: /home/work/cvs/gnu/egcs/configure,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 configure
--- configure	1997/09/17 20:09:18	1.1.1.2
+++ configure	1997/09/17 20:22:21
@@ -992,27 +1006,34 @@
                 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} ${srcdir}/${file} ${link} >/dev/null 2>&1 ; then
+		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} ${srcdir}/${file} ${link}
+			${hard_link} ${srcfile} ${link}
 		fi
                 if [ ! -r ${link} ] ; then
-                        echo '***' "${progname}: unable to link \"${link}\" to \"${srcdir}/${file}\"." 1>&2
+                        echo '***' "${progname}: unable to link \"${link}\" to \"${srcfile}\"." 1>&2
                         exit 1
                 fi
 
-                echo "Linked \"${link}\" to \"${srcdir}/${file}\"."
+                echo "Linked \"${link}\" to \"${srcfile}\"."
         done
 
         # Create a .gdbinit file which runs the one in srcdir