On 7 March 2013 14:59, <mwpowellhtx@xxxxxxxxx> wrote: > On Thu, Mar 7, 2013 at 7:56 AM, <Heiko.Papenfuss@xxxxxxxxxxx> wrote: > > On 7 March 2013 10:45, <jwakely.gcc@xxxxxxxxx> wrote: > >> On 7 March 2013 09:23, <Heiko.Papenfuss@xxxxxxxxxxx> 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.
