libstdc++ soname in egcs 1.1 and 1.0.3

libstdc++ soname in egcs 1.1 and 1.0.3

[H.J. Lu]

Hi,

On linux/x86/glibc 2, libstdc++ is not compatible between egcs
1.0.3 and 1.1 due to MT-safe EH. But they use the same soname.
That causes a problem. All C++ binaries on my RedHat 5.1 compiled
against egcs 1.0.3 stop working due to incompatible libstdc++.so.2.8
when I installed egcs 1.1 snapshot. It has to be fixed for egcs 1.1.

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

Re: libstdc++ soname in egcs 1.1 and 1.0.3

[Manfred Hollstein]

On Tue, 23 June 1998, 19:22:59, hjl@lucon.org wrote:

 > Hi,
 > 
 > On linux/x86/glibc 2, libstdc++ is not compatible between egcs
 > 1.0.3 and 1.1 due to MT-safe EH. But they use the same soname.
 > That causes a problem. All C++ binaries on my RedHat 5.1 compiled
 > against egcs 1.0.3 stop working due to incompatible libstdc++.so.2.8
 > when I installed egcs 1.1 snapshot. It has to be fixed for egcs 1.1.

Yes! We should definitely change

  VERSION = 2.8.0

to

  VERSION = 2.9.0

Since this is currently defined at several locations, we should
probably define this only once and add it to FLAGS_TO_PASS instead.
Perhaps, we should also change MSHLINK's definition to use the first
three digits instead of the first two.

What do you think?

manfred

Re: libstdc++ soname in egcs 1.1 and 1.0.3

[Carlo Wood]

Manfred wrote about libstdc++:
| Yes! We should definitely change
| 
|   VERSION = 2.8.0
| 
| to
| 
|   VERSION = 2.9.0

Leaving it at 2.8.0 is definitely, positively, wrong.

But bumping it to 2.9.0 could still cause compilation
with gcc-2.8.x to use it too.
You still can only have one libstdc++.so symbolic link;
so every time you switch compiler you need to change
that link, right?.  I am not sure if that is the same
problem though :)

Carlo

Re: libstdc++ soname in egcs 1.1 and 1.0.3

[Manfred Hollstein]

On Thu, 25 June 1998, 17:57:08, carlo@runaway.xs4all.nl wrote:

 > Manfred wrote about libstdc++:
 > | Yes! We should definitely change
 > | 
 > |   VERSION = 2.8.0
 > | 
 > | to
 > | 
 > |   VERSION = 2.9.0
 > 
 > Leaving it at 2.8.0 is definitely, positively, wrong.
 > 
 > But bumping it to 2.9.0 could still cause compilation
 > with gcc-2.8.x to use it too.
 > You still can only have one libstdc++.so symbolic link;
 > so every time you switch compiler you need to change
 > that link, right?.  I am not sure if that is the same
 > problem though :)

Fortunately, we now have the new flag `--enable-version-specific-runtime-libs',
which installs libstdc++.{a,so*,sl*} and its include files in the
compiler specific subdirectory named by the make macro "$(libsubdir)".

So, if you're using this approach, no problem at all!

manfred

Re: libstdc++ soname in egcs 1.1 and 1.0.3

[Franz Sirl]

At 07:18 26.06.98 , Manfred Hollstein wrote:
>On Thu, 25 June 1998, 17:57:08, carlo@runaway.xs4all.nl wrote:
>
> > Manfred wrote about libstdc++:
> > | Yes! We should definitely change
> > | 
> > |   VERSION = 2.8.0
> > | 
> > | to
> > | 
> > |   VERSION = 2.9.0
> > 
> > Leaving it at 2.8.0 is definitely, positively, wrong.
> > 
> > But bumping it to 2.9.0 could still cause compilation
> > with gcc-2.8.x to use it too.
> > You still can only have one libstdc++.so symbolic link;
> > so every time you switch compiler you need to change
> > that link, right?.  I am not sure if that is the same
> > problem though :)
>
>Fortunately, we now have the new flag
`--enable-version-specific-runtime-libs',
>which installs libstdc++.{a,so*,sl*} and its include files in the
>compiler specific subdirectory named by the make macro "$(libsubdir)".

Hmm, two questions (I'm no shared lib expert):
- would it harm anything if the libraries got always installed in eg.
/usr/lib _and_ $(libsuddir)? So one would have at least a reference copy
available
- is linking from /usr/lib to $(libsubdir) ok?

I wonder what's the best thing to do on Linux, since I also could modify
/etc/ld.so.conf on the fly and add $(libsubdir) while installing the RPM.

Franz.

Re: libstdc++ soname in egcs 1.1 and 1.0.3

[Manfred Hollstein]

On Fri, 26 June 1998, 11:48:40, Franz.Sirl-kernel@lauterbach.com wrote:

 > At 07:18 26.06.98 , Manfred Hollstein wrote:
 > >On Thu, 25 June 1998, 17:57:08, carlo@runaway.xs4all.nl wrote:
 > >
 > > > Manfred wrote about libstdc++:
 > > > | Yes! We should definitely change
 > > > | 
 > > > |   VERSION = 2.8.0
 > > > | 
 > > > | to
 > > > | 
 > > > |   VERSION = 2.9.0
 > > > 
 > > > Leaving it at 2.8.0 is definitely, positively, wrong.
 > > > 
 > > > But bumping it to 2.9.0 could still cause compilation
 > > > with gcc-2.8.x to use it too.
 > > > You still can only have one libstdc++.so symbolic link;
 > > > so every time you switch compiler you need to change
 > > > that link, right?.  I am not sure if that is the same
 > > > problem though :)
 > >
 > >Fortunately, we now have the new flag
 > `--enable-version-specific-runtime-libs',
 > >which installs libstdc++.{a,so*,sl*} and its include files in the
 > >compiler specific subdirectory named by the make macro "$(libsubdir)".
 > 
 > Hmm, two questions (I'm no shared lib expert):
 > - would it harm anything if the libraries got always installed in eg.
 > /usr/lib _and_ $(libsuddir)? So one would have at least a reference copy
 > available
 > - is linking from /usr/lib to $(libsubdir) ok?

If you're only interested in Linux, then yes, as long as _only_ the
real file libstdc++.so.x.y.z (and not libstdc++.so) is linked.
But, on SunOS this would fail, because the bloody ld.so there
will always happily use the lib with the highest version number :-(

 > 
 > I wonder what's the best thing to do on Linux, since I also could modify
 > /etc/ld.so.conf on the fly and add $(libsubdir) while installing the RPM.

For me defining LD_RUN_PATH at linktime seems to be the best solution.

 > 
 > Franz.
 > 

manfred

Re: libstdc++ soname in egcs 1.1 and 1.0.3

[Alex Buell]

On Fri, 26 Jun 1998, Manfred Hollstein wrote:

> If you're only interested in Linux, then yes, as long as _only_ the
> real file libstdc++.so.x.y.z (and not libstdc++.so) is linked.
> But, on SunOS this would fail, because the bloody ld.so there
> will always happily use the lib with the highest version number :-(

You could try downloading binutils-2.9.1.0.6 and building it for Sparc
architecture. This could help.

Cheers,
Alex
--
 /\_/\  Legalise cannabis now! 
( o.o ) Smoke some cannabis today!
 > ^ <  Peace, Love, Unity and Respect to all.

http://www.tahallah.demon.co.uk

Re: libstdc++ soname in egcs 1.1 and 1.0.3

[H.J. Lu]

> 
> On Fri, 26 June 1998, 11:48:40, Franz.Sirl-kernel@lauterbach.com wrote:
> 
>  > At 07:18 26.06.98 , Manfred Hollstein wrote:
>  > >On Thu, 25 June 1998, 17:57:08, carlo@runaway.xs4all.nl wrote:
>  > >
>  > > > Manfred wrote about libstdc++:
>  > > > | Yes! We should definitely change
>  > > > | 
>  > > > |   VERSION = 2.8.0
>  > > > | 
>  > > > | to
>  > > > | 
>  > > > |   VERSION = 2.9.0
>  > > > 
>  > > > Leaving it at 2.8.0 is definitely, positively, wrong.
>  > > > 
>  > > > But bumping it to 2.9.0 could still cause compilation
>  > > > with gcc-2.8.x to use it too.
>  > > > You still can only have one libstdc++.so symbolic link;
>  > > > so every time you switch compiler you need to change
>  > > > that link, right?.  I am not sure if that is the same
>  > > > problem though :)
>  > >
>  > >Fortunately, we now have the new flag
>  > `--enable-version-specific-runtime-libs',
>  > >which installs libstdc++.{a,so*,sl*} and its include files in the
>  > >compiler specific subdirectory named by the make macro "$(libsubdir)".

That is a bad idea. I will like to keep libstdc++.so*. But I
certainly don't want to keep all $(libsubdir).

>  > 
>  > Hmm, two questions (I'm no shared lib expert):
>  > - would it harm anything if the libraries got always installed in eg.
>  > /usr/lib _and_ $(libsuddir)? So one would have at least a reference copy
>  > available
>  > - is linking from /usr/lib to $(libsubdir) ok?
> 
> If you're only interested in Linux, then yes, as long as _only_ the
> real file libstdc++.so.x.y.z (and not libstdc++.so) is linked.
> But, on SunOS this would fail, because the bloody ld.so there
> will always happily use the lib with the highest version number :-(
> 
>  > 
>  > I wonder what's the best thing to do on Linux, since I also could modify
>  > /etc/ld.so.conf on the fly and add $(libsubdir) while installing the RPM.
> 
> For me defining LD_RUN_PATH at linktime seems to be the best solution.
> 

I don't like it. I like to be able to mov the shared libraries around
and I don't want to keep all $(libsubdir). How about install it in
$(libdir)/$(version) for SunOS?


H.J.