GLIBC backward compatibility

glibc backward compatibility
http://www.groupsrv.com/linux/about58413.html

Is there any way I can have two version of glib running on my machine at the same time. Ideally, I would like to have my current 2.3.2

Sure - no problem. Use LD_LIBRARY_PATH in a wrapper script. But I think you'll find that the later glibc works fine for executables compiled against an earlier glibc, since symbols are individually versioned!

update glibc 2.5 -> 2.7
http://forums.gentoo.org/viewtopic-t-645593-start-0.html

if you downgrade a glibc version, then you need to recompile your system. If you upgrade your glibc version, then you don't need to recompile because the new version is compatible with your files compiled by the old version.
(...................)
After upgrading glibc, you have to recompile the whole system.

No. Not anymore. Not since quite some time ago (2.3-2.4 glibc, about) - and even then, a revdep-rebuild was the only thing -strictly- required.

The GNU C Library With Versioned Interface
ftp://ftp.kernel.org/pub/software/libs/glibc/hjl/compat/index.html

The current GNU C library provides the run-time backward compatibility. That means executables and shared libraries built against the previous versions of glibc will continue to work with the current shared glibc, libc.so. This functionality is implemented with the symbol versioning in libc.so. This work is based on the effort from Eric Youngdale.

But the run-time compatibility is not enough for the Independent Software Vendors (ISVs). Many software applications may come with not only executables and shared libraries, but also header files, regular object files and archives which may be used to develop softwares for the application. Since the new version of glibc may not provide the compile-time nor link-time compatibility, the software applications from ISVs built against the previous versions of glibc may not be compatible with the new version of glibc if they have header files, regular object files or archives which reference the interfaces updated in the new glibc. One such a example is the problem of Oracle 8i under glibc 2.2. It may not be the only software package having similar problems.

One way to solve this compile-time/link-time compatibility problem is for ISVs to recompile their applications against the new version of glibc. But it may not be practical for all ISVs. ISVs usually provide their software applications on more than one platform. Their applications may be very complex. Porting their applications to a new version of glibc may take the same long, involved process as porting to a new platform since it not only needs to recompile and re-test, but also the new glibc may require other changes in the system, like new kernel. Also ISVs have to make decision if the want to support more than one version of glibc and which version of glibc they want to support. All of these may not something every ISV wants to endure. It may not be very helpful for more ISVs to develop/port their applications for Linux.

Linux compatibility
http://www.vsni.co.uk/downloads/asreml/version-2/linux-compatibility/

Platform	Linux kernel	GLIBC	Motif
32-bit Red Hat 7.1	2.4.2-2	2.2.2	2.1
32-bit Red Hat 9.1
32-bit Fedora Core 3	2.6.9-1.667	2.3.3	3.0.2
64-bit Fedora Core 3	2.6.9-1.667	2.3.3	3.0.2
64-bit Fedora Core 6	2.6.22.1-32.fc6	2.5-18.fc6	4.0.0

(......................)

GLIBC

GLIBC (or glibc) is the GNU C runtime library. It is backward compatible, in that a program built on a system using any particular GLIBC version will also execute on a system with a later version installed. However, it is not forward compatible, programs will not execute if only an earlier version is found, leading to messages like: ASReml: /lib/libc.so.6: version `GLIBC_2.3' not found (required by asreml200ag) If you get this message

---

Not related.... :)
GLIBC SUCKS
http://www.galexander.org/glibc.html