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

[<Heiko dot Papenfuss at uniserv dot com>]

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.