libstdc++.so.5 vs libstdc++.so.6

libstdc++.so.5 vs libstdc++.so.6

[danny payton]

Hi:

I used g++ to compile an executable on an older Linux.
ldd shows it is linked against libstdc++.so.5:

        linux-gate.so.1 =>  (0xffffe000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7f29000)
        libm.so.6 => /lib/tls/libm.so.6 (0xb7f04000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7ef9000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7dc7000)
        /lib/ld-linux.so.2 (0x80000000)

But I found that people with newer library cannot run it
so I had to recompile my program to produce an alternate version
like so:

        linux-gate.so.1 =>  (0xffffe000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7e8d000)
        libm.so.6 => /lib/tls/libm.so.6 (0xb7e68000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e5d000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7d2b000)
        /lib/ld-linux.so.2 (0x80000000)

Is there a way to compile a C++ program using g++ so that it works
with library versions ">=" some version number?

If not with C++ programs (due to the complex ABI), I could try
to rewrite my program in C. Is it doable with C programs using gcc?

Thank you!

Re: libstdc++.so.5 vs libstdc++.so.6

[Ian Lance Taylor]

danny payton <dannyx.payton@gmail.com> writes:

> I used g++ to compile an executable on an older Linux.
> ldd shows it is linked against libstdc++.so.5:
>
>         linux-gate.so.1 =>  (0xffffe000)
>         libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7f29000)
>         libm.so.6 => /lib/tls/libm.so.6 (0xb7f04000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7ef9000)
>         libc.so.6 => /lib/tls/libc.so.6 (0xb7dc7000)
>         /lib/ld-linux.so.2 (0x80000000)
>
> But I found that people with newer library cannot run it
> so I had to recompile my program to produce an alternate version
> like so:
>
>         linux-gate.so.1 =>  (0xffffe000)
>         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7e8d000)
>         libm.so.6 => /lib/tls/libm.so.6 (0xb7e68000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e5d000)
>         libc.so.6 => /lib/tls/libc.so.6 (0xb7d2b000)
>         /lib/ld-linux.so.2 (0x80000000)
>
> Is there a way to compile a C++ program using g++ so that it works
> with library versions ">=" some version number?

No.  Sorry.  Changes in the major version number indicate incompatible
code.

Ian

Re: libstdc++.so.5 vs libstdc++.so.6

[danny payton]

On Sat, Jan 17, 2009 at 5:43 PM, Ian Lance Taylor wrote:
> No.  Sorry.  Changes in the major version number indicate
> incompatible code.

Dear Ian:

Thank you for your prompt reply.

Are there really no way out? I'm distributing a research project
developed jointly by my professor and several other students,
and currently we are forced to deliberately keep several different
versions of Linux around, just so that we can build the *same*
simple C++ source code and produce different versions of the library.

Our Mac OS X distribution is a breeze. Not only does the binary
simply depend on library version >= 1.0 for every main library of Mac OS X,
and we can even compile both PowerPC and Intelx86 code into
the *same* library file, and the user's Mac OS will intelligently load
the PowerPC chunk versus the Intelx86 chunk.

Okay. So I need to keep multiple Linux build boxes. That's fine.
Is there perhaps a way to bundle multiple versions of the code
into the ELF output file, tagged with different versions, so that
we can at least distribute only 1 file to the user (rather than asking
the users to check their Linux library version number for stdc++,
libm, libgcc... which is just asking them too much)?

(Likewise, due to user inability, distributing the source code
and asking them to compile is also out of the question,
especially due to Linux distros being so incompatible
with each other...)

This is not a complaint. I'm thankful for your reply.
And I think perhaps I'm trying to solve the wrong problem
rather than finding the right solution, so if anyone has other
suggestions, please let me know.  Thanks!

Re: libstdc++.so.5 vs libstdc++.so.6

[Axel Freyn]

Hello Danny,
On Sun, Jan 18, 2009 at 07:08:04AM -0800, danny payton wrote:
> On Sat, Jan 17, 2009 at 5:43 PM, Ian Lance Taylor wrote:
> > No.  Sorry.  Changes in the major version number indicate
> > incompatible code.
> 
> Dear Ian:
> 
> Thank you for your prompt reply.
> 
> Are there really no way out? I'm distributing a research project
> developed jointly by my professor and several other students,
> and currently we are forced to deliberately keep several different
> versions of Linux around, just so that we can build the *same*
> simple C++ source code and produce different versions of the library.
>
> [...]
>
> Okay. So I need to keep multiple Linux build boxes. That's fine.
No, I don't think that's necessary. You can just install different
versions of gcc in parallel on the same Linux box, and the compile using
libstdc++.so.5 and libstdc++.so.6 on the same machine.

Another possibility is that you distribute the adequate version of
libstdc++.so together with your compiled programm, and use the
environment-variable LD_LIBRARY_PATH to tell the linker where to find
the library. E.g using bash, the command

LD_LIBRARY_PATH=./lib ./program

will execute the program "program", and search (in addition to the
default locations) in the directory ./lib for libraries. If you store
there libstdc++.so.6, ist should work on all machines.

HTH,

Axel

Re: libstdc++.so.5 vs libstdc++.so.6

[danny payton]

Axel Freyn wrote:
> You can just install different versions of gcc in parallel
> on the same Linux box, and the compile using
> libstdc++.so.5 and libstdc++.so.6 on the same machine.
>
> Another possibility is that you distribute the adequate version of
> libstdc++.so together with your compiled programm, and use the
> environment-variable LD_LIBRARY_PATH to tell the linker where to find
> the library. E.g using bash, the command
> LD_LIBRARY_PATH=./lib ./program
> will execute the program "program", and search (in addition to the
> default locations) in the directory ./lib for libraries. If you store
> there libstdc++.so.6, it should work on all machines.

Very interesting! Potentially this solves my problem.
So I would just distribute three versions of the library:
1) Mac OS X
2) Linux ia32 (together with libstdc++.so.5 from old RedHat)
3) Linux amd64 (together with libstdc++.so.5 from old RedHat)

Regardless of whether the user already have libstdc++.so.5,
it sounds like setting LD_LIBRARY_PATH would make this idea work.

Hmm, how about kernel version number? If I just grab libstdc++.so.5
from one of the older Linux distro, would it be guaranteed to work
even for users with newer Kernel versions?

Thanks!

Re: libstdc++.so.5 vs libstdc++.so.6

[Ian Lance Taylor]

danny payton <dannyx.payton@gmail.com> writes:

> Okay. So I need to keep multiple Linux build boxes. That's fine.

You don't necessary need multiple build boxes.  You can build and
install several different versions of gcc using a different --prefix
option when you run configure.  However, the glibc symbol versions
will be included in your build, so you will want to do this on a
system which runs the oldest version of glibc that you care to
support.

> Is there perhaps a way to bundle multiple versions of the code
> into the ELF output file, tagged with different versions, so that
> we can at least distribute only 1 file to the user (rather than asking
> the users to check their Linux library version number for stdc++,
> libm, libgcc... which is just asking them too much)?

I don't see any way to do this short of accessing all symbols via
dlopen and dlsym.

Note that libm and libgcc have not changed major version numbers in
many years.  For them, what matters is the version of the symbol.  The
symbol version which you link against will have to be available on the
system where the executable is run.  For that matter, libstdc++ also
uses symbol versions.

So in practice, for these basic system libraries, there is only one
relevant distinction: libstdc++.so.5 vs. libstdc++.so.6.  The latter
has been in use for over five years.

The situation is certainly not ideal.  While having a single library
provide both the libstdc++.so.5 and libstd++.so.6 symbols is
technically feasible, making it actually work in practice would
require a significant amount of tedious work.

Ian