I've been studying the C/C++ build and I think I learned some things:
- glibc is inextricably linked with the Linux operating system. You can't run with a new glibc.
LD_LIBRARY_PATHcan affect libc, but cannot affect
ld-2.3.2.so). It seems you can get around this with
chroot, but then you have other problems.
- glibc 2.3.2 has the symbol
GLIBC_PRIVATEwhich is in
ld-2.3.2.so, but not in
- libstdc++ 3.2 (it comes with g++ 3.2) requires glibc 2.3. Redhat 7 ships with 2.2 or earlier. See previous point. You cannot take a libstdc++ from Redhat 9 and run it on Redhat 7 unless you upgrade glibc and just about everything else in the OS, at which point it's not really Redhat 7.
- libstdc++ is more than STL. It's the C++ runtime and STL. Therefore STLport can never replace libstdc++.
- I can
chrootwith Redhat 7 (actually Mandrake 8) and get my Redhat 9 compiled binary and libstdc++ 3.2 shared object. However, once I do that I can't do things like read
/etcwhich is something we need to do.
- Starting with g++ 3.2, libstdc++ is attempting to be forward/backwards compatible in its ABI where possible. At this point compatibility was completely broken.
- Redhat 9 ships with compat-libstdc++ which contains the C++ runtime libraries for gcc 2.96 as used in Redhat 7.3. This means C++ stuff compiled on Redhat 7 will work on Redhat 9, but only when this package is installed.
- glibc works very well forward/backwards compatibility-wise, with the GLIBC_2.0,GLIBC_2.1, etc. symbols. If you build a binary that is C only, it's probably going to run anywhere, as long as it's glibc v2 or better, preferably glibc v2.1.
- It is impossible to statically link libstdc++ into an executable when exceptions are thrown/caught. This is because symbols such as
libgcc.sobut do not exist in