Using libstdc++.so with a newer version of glibc without recompiling

Using libstdc++.so with a newer version of glibc without recompiling

[Heiko.Papenfuss]

Hi,

I have a question regarding the dependency of libstdc++.so.6 on libc.so.6:

If changing the underlying glibc version libc.so.6 is pointing to to a
higher version (e.g. from libc-2.4.so to libc-2.7.so), is it expected that
the libstdc++.so.6 will still work correctly when used by a program? Or is
it necessary to recompile GCC under the new glibc and all our with this
new GCC as well?

The background to this question is that I need to compile a C++ program that
uses a shared library which requires a newer version of glibc than the one
that is present in the system. I cannot change the system's glibc nor the
GCC, so I try to figure out a way to do this by using my own version of
glibc without changing anything else.

Best regards,

Heiko

Re: Using libstdc++.so with a newer version of glibc without recompiling

[Jonathan Wakely]

On 7 March 2013 09:23,  <Heiko.Papenfuss@uniserv.com> wrote:
> Hi,
>
> I have a question regarding the dependency of libstdc++.so.6 on libc.so.6:
>
> If changing the underlying glibc version libc.so.6 is pointing to to a
> higher version (e.g. from libc-2.4.so to libc-2.7.so), is it expected that
> the libstdc++.so.6 will still work correctly when used by a program? Or is
> it necessary to recompile GCC under the new glibc and all our with this
> new GCC as well?

The libstdc++.so.6 will still work, glibc is also backwards compatible.

You might not be able to use the older GCC with the newer glibc
headers to compile new programs though, because GCC configures itself
based on the glibc headers present at the time when GCC is built. If
you later change glibc then GCC's C++ headers may be incompatible with
the new glibc headers.  If that happens you'd need to rebuild the same
GCC version against the new glibc.

RE: Using libstdc++.so with a newer version of glibc without recompiling

[Heiko.Papenfuss]

On 7 March 2013 10:45, <jwakely.gcc@gmail.com> wrote:
> On 7 March 2013 09:23,  <Heiko.Papenfuss@uniserv.com> wrote:
> > Hi,
> >
> > I have a question regarding the dependency of libstdc++.so.6 on libc.so.6:
> >
> > If changing the underlying glibc version libc.so.6 is pointing to to a
> > higher version (e.g. from libc-2.4.so to libc-2.7.so), is it expected that
> > the libstdc++.so.6 will still work correctly when used by a program? Or is
> > it necessary to recompile GCC under the new glibc and all our with this
> > new GCC as well?
>
> The libstdc++.so.6 will still work, glibc is also backwards compatible.
>
> You might not be able to use the older GCC with the newer glibc
> headers to compile new programs though, because GCC configures itself
> based on the glibc headers present at the time when GCC is built. If
> you later change glibc then GCC's C++ headers may be incompatible with
> the new glibc headers.  If that happens you'd need to rebuild the same
> GCC version against the new glibc.

How would that become apparent or how could we make sure this is not the
case? In our special case, we have a glibc 2.4 in the system and trying to 
use glibc 2.6 instead.

-----Original Message-----
From: Jonathan Wakely [mailto:jwakely.gcc@gmail.com] 
Sent: Donnerstag, 7. März 2013 10:45
To: Papenfuß Heiko
Cc: gcc-help@gcc.gnu.org
Subject: Re: Using libstdc++.so with a newer version of glibc without recompiling

On 7 March 2013 09:23,  <Heiko.Papenfuss@uniserv.com> wrote:
> Hi,
>
> I have a question regarding the dependency of libstdc++.so.6 on libc.so.6:
>
> If changing the underlying glibc version libc.so.6 is pointing to to a
> higher version (e.g. from libc-2.4.so to libc-2.7.so), is it expected that
> the libstdc++.so.6 will still work correctly when used by a program? Or is
> it necessary to recompile GCC under the new glibc and all our with this
> new GCC as well?

The libstdc++.so.6 will still work, glibc is also backwards compatible.

You might not be able to use the older GCC with the newer glibc
headers to compile new programs though, because GCC configures itself
based on the glibc headers present at the time when GCC is built. If
you later change glibc then GCC's C++ headers may be incompatible with
the new glibc headers.  If that happens you'd need to rebuild the same
GCC version against the new glibc.

Re: Using libstdc++.so with a newer version of glibc without recompiling

[Michael Powell]

On Thu, Mar 7, 2013 at 7:56 AM,  <Heiko.Papenfuss@uniserv.com> wrote:
> On 7 March 2013 10:45, <jwakely.gcc@gmail.com> wrote:
>> On 7 March 2013 09:23,  <Heiko.Papenfuss@uniserv.com> wrote:
>> > Hi,
>> >
>> > I have a question regarding the dependency of libstdc++.so.6 on libc.so.6:
>> >
>> > If changing the underlying glibc version libc.so.6 is pointing to to a
>> > higher version (e.g. from libc-2.4.so to libc-2.7.so), is it expected that
>> > the libstdc++.so.6 will still work correctly when used by a program? Or is
>> > it necessary to recompile GCC under the new glibc and all our with this
>> > new GCC as well?
>>
>> The libstdc++.so.6 will still work, glibc is also backwards compatible.
>>
>> You might not be able to use the older GCC with the newer glibc
>> headers to compile new programs though, because GCC configures itself
>> based on the glibc headers present at the time when GCC is built. If
>> you later change glibc then GCC's C++ headers may be incompatible with
>> the new glibc headers.  If that happens you'd need to rebuild the same
>> GCC version against the new glibc.
>
> How would that become apparent or how could we make sure this is not the
> case? In our special case, we have a glibc 2.4 in the system and trying to
> use glibc 2.6 instead.

Reading the past several posts, I was getting confused. It seems to me
you have the reverse scenario from the backwards compatible one. You
are attempting to use >2.4 while <=2.4 is on the system. I don't know
how you package those updates and/or ensure proper dynamic (?)
linkage.

> -----Original Message-----
> From: Jonathan Wakely [mailto:jwakely.gcc@gmail.com]
> Sent: Donnerstag, 7. März 2013 10:45
> To: Papenfuß Heiko
> Cc: gcc-help@gcc.gnu.org
> Subject: Re: Using libstdc++.so with a newer version of glibc without recompiling
>
> On 7 March 2013 09:23,  <Heiko.Papenfuss@uniserv.com> wrote:
>> Hi,
>>
>> I have a question regarding the dependency of libstdc++.so.6 on libc.so.6:
>>
>> If changing the underlying glibc version libc.so.6 is pointing to to a
>> higher version (e.g. from libc-2.4.so to libc-2.7.so), is it expected that
>> the libstdc++.so.6 will still work correctly when used by a program? Or is
>> it necessary to recompile GCC under the new glibc and all our with this
>> new GCC as well?
>
> The libstdc++.so.6 will still work, glibc is also backwards compatible.
>
> You might not be able to use the older GCC with the newer glibc
> headers to compile new programs though, because GCC configures itself
> based on the glibc headers present at the time when GCC is built. If
> you later change glibc then GCC's C++ headers may be incompatible with
> the new glibc headers.  If that happens you'd need to rebuild the same
> GCC version against the new glibc.

Re: Using libstdc++.so with a newer version of glibc without recompiling

[Jonathan Wakely]

On 7 March 2013 13:56,  <Heiko.Papenfuss@uniserv.com> wrote:
>>
>> You might not be able to use the older GCC with the newer glibc
>> headers to compile new programs though, because GCC configures itself
>> based on the glibc headers present at the time when GCC is built. If
>> you later change glibc then GCC's C++ headers may be incompatible with
>> the new glibc headers.  If that happens you'd need to rebuild the same
>> GCC version against the new glibc.
>
> How would that become apparent or how could we make sure this is not the
> case? In our special case, we have a glibc 2.4 in the system and trying to
> use glibc 2.6 instead.

You'd get compilation errors complaining about invalid types or
declarations libstdc++ headers.

One case I can think of is when you build GCC on RHEL5 and try to run
it on RHEL6 (which obviously has a newer glibc) you get lots of errors
about __locale_t being undeclared.

To make sure it's not the case you'd need to compile every piece of
software in the universe to check if it works. That may not be
practical, so picking a subset of code you care about and testing it
might suffice.  To be safe I would rebuild the same GCC version
against the newer glibc.

RE: Using libstdc++.so with a newer version of glibc without recompiling

[Heiko.Papenfuss]

On 7 March 2013 14:59, <mwpowellhtx@gmail.com> wrote:
> On Thu, Mar 7, 2013 at 7:56 AM,  <Heiko.Papenfuss@uniserv.com> wrote:
> > On 7 March 2013 10:45, <jwakely.gcc@gmail.com> wrote:
> >> On 7 March 2013 09:23,  <Heiko.Papenfuss@uniserv.com> wrote:
> >> >
> >> > I have a question regarding the dependency of libstdc++.so.6 on libc.so.6:
> >> >
> >> > If changing the underlying glibc version libc.so.6 is pointing to to a
> >> > higher version (e.g. from libc-2.4.so to libc-2.7.so), is it expected that
> >> > the libstdc++.so.6 will still work correctly when used by a program? Or is
> >> > it necessary to recompile GCC under the new glibc and all our with this
> >> > new GCC as well?
> >>
> >> The libstdc++.so.6 will still work, glibc is also backwards compatible.
> >>
> >> You might not be able to use the older GCC with the newer glibc
> >> headers to compile new programs though, because GCC configures itself
> >> based on the glibc headers present at the time when GCC is built. If
> >> you later change glibc then GCC's C++ headers may be incompatible with
> >> the new glibc headers.  If that happens you'd need to rebuild the same
> >> GCC version against the new glibc.
> >
> > How would that become apparent or how could we make sure this is not the
> > case? In our special case, we have a glibc 2.4 in the system and trying to
> > use glibc 2.6 instead.
>
> Reading the past several posts, I was getting confused. It seems to me
> you have the reverse scenario from the backwards compatible one. You
> are attempting to use >2.4 while <=2.4 is on the system. I don't know
> how you package those updates and/or ensure proper dynamic (?)
> linkage.

I'll try to clarify: We want to build a software on a system with glibc 2.4
as the system's standard libc. However, we need this program to use a newer
glibc (version 2.6 in our case), which we have installed in a separate
location. Clearly, this program will then no longer run in a system without
a glibc 2.6 or newer. First, I wanted to confirm that this is possible at all, since 
we are exchanging the glibc here, which a lot (rather all) shared objects rely
on.

How to package this is the next question. The software is not meant as a
system component but is specialized, proprietary and self-contained and as
such it is installed as a package in its own directory along with everything
it depends on except for system libraries.

I believe the LGPL allows us to package all the shared libraries
of the glibc with the software and distribute this package as a whole, thus
providing an exact copy of our build environment to the customer, so the
software can run on a system with an older glibc, too. Is that true?

If not, we probably would have to require glibc 2.6 to be present in the
target system, which would be ok for us as well.

RE: Using libstdc++.so with a newer version of glibc without recompiling

[Heiko.Papenfuss]

On 7 March 2013 15:37, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 7 March 2013 13:56,  <Heiko.Papenfuss@uniserv.com> wrote:
> >>
> >> You might not be able to use the older GCC with the newer glibc
> >> headers to compile new programs though, because GCC configures itself
> >> based on the glibc headers present at the time when GCC is built. If
> >> you later change glibc then GCC's C++ headers may be incompatible with
> >> the new glibc headers.  If that happens you'd need to rebuild the same
> >> GCC version against the new glibc.
> >
> > How would that become apparent or how could we make sure this is not the
> > case? In our special case, we have a glibc 2.4 in the system and trying to
> > use glibc 2.6 instead.
>
> You'd get compilation errors complaining about invalid types or
> declarations libstdc++ headers.
>
> One case I can think of is when you build GCC on RHEL5 and try to run
> it on RHEL6 (which obviously has a newer glibc) you get lots of errors
> about __locale_t being undeclared.
>
> To make sure it's not the case you'd need to compile every piece of
> software in the universe to check if it works. That may not be
> practical, so picking a subset of code you care about and testing it
> might suffice.  To be safe I would rebuild the same GCC version
> against the newer glibc.

Ok, we will try that. Thanks for the help!

-----Original Message-----
From: Jonathan Wakely [mailto:jwakely.gcc@gmail.com] 
Sent: Donnerstag, 7. März 2013 15:37
To: Papenfuß Heiko
Cc: gcc-help@gcc.gnu.org
Subject: Re: Using libstdc++.so with a newer version of glibc without recompiling

On 7 March 2013 13:56,  <Heiko.Papenfuss@uniserv.com> wrote:
>>
>> You might not be able to use the older GCC with the newer glibc
>> headers to compile new programs though, because GCC configures itself
>> based on the glibc headers present at the time when GCC is built. If
>> you later change glibc then GCC's C++ headers may be incompatible with
>> the new glibc headers.  If that happens you'd need to rebuild the same
>> GCC version against the new glibc.
>
> How would that become apparent or how could we make sure this is not the
> case? In our special case, we have a glibc 2.4 in the system and trying to
> use glibc 2.6 instead.

You'd get compilation errors complaining about invalid types or
declarations libstdc++ headers.

One case I can think of is when you build GCC on RHEL5 and try to run
it on RHEL6 (which obviously has a newer glibc) you get lots of errors
about __locale_t being undeclared.

To make sure it's not the case you'd need to compile every piece of
software in the universe to check if it works. That may not be
practical, so picking a subset of code you care about and testing it
might suffice.  To be safe I would rebuild the same GCC version
against the newer glibc.