[CentOS] CENTOS and INTEL S775 C2D E6750 2.66G 1333 RTL

[Peter Arremann]

On Thursday 27 September 2007, Art Edwards wrote:
> Michel van Deventer wrote:
> > At 06:29 27-9-2007, Art Edwards wrote:
> >> Are there any differences in basic libraries between 4.0 and 4.5?
> >
> > Yes of course, it is wise to install the latest version, otherwise some
> > hardware may not be recognized by the kernel.
>
> Thanks for the feedback. Unfortunately, the third-party software will be
> a binary that was built against specific library versions.

Well, depends on what you mean with specific... You can use ldd to check what 
version it is and if it is being picked up by the linker properly...

Most libraries follow a X.Y.Z version schema. Some leave off the Z and a few 
do something completely different, but as a general rule its x.y.z

Any changes in X (major version number) make things incompatible... so if you 
have 1.4.2 and 2.1.9 then they will be incompatible, no matter what. New 
functions will be added, old ones will be removed or changed.

Changes in the Y series (minor version number) are supposed to be upward 
compatible. so a program that works with 1.4.2 should work as well with 
1.5.2.... the new 1.5 version may add new interfaces but all old ones will 
remain there for backwards compatibility.

Changes in Z (patch level or micro version) are supposed to be forward and 
backward compatible as long as you don't hit a bug that is fixed in the later 
version. So, if you have a library in version 1.4.1 and they fix a function 
called printUselessNames, the result will be 1.4.2... If you compile and link 
against 1.4.2 but the target system has 1.4.1 installed, then your program 
will still run correctly as long as you don't actually execute the code of 
printUselessNames... Usually micro changes do not introduce new interfaces 
into the library. 

The policy for RH is that changes in X will be avoided at all cost. Changes in 
Y will happen only if there is a real good reason but it happend in the past. 
Changes in patch level are common - that's the whole point of update 
releases.  You're best of checking your program with ldd. 

the following empty program:
int main () {
	return 1;
}

compiled with 
gcc -o a a.c 
gives the following output:
# gcc -o a a.c
# ldd a
        linux-gate.so.1 =>  (0x00110000)
        libc.so.6 => /lib/libc.so.6 (0x00582000)
        /lib/ld-linux.so.2 (0x00563000)
#

You can tell everything only specifies the major number.
If I force linking against libstdc++ you use
gcc -o a a.c -lstdc++ 
if you rerun ldd you'll see 
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x009d8000)
and maybe some others more that were pulled in. 
# ls -la /usr/lib/libstdc++.so.*
lrwxrwxrwx 1 root root     18 2007-07-19 19:49 /usr/lib/libstdc++.so.5 -> 
libstdc++.so.5.0.7
-rwxr-xr-x 1 root root 733456 2006-08-21 09:39 /usr/lib/libstdc++.so.5.0.7
lrwxrwxrwx 1 root root     18 2007-05-31 12:15 /usr/lib/libstdc++.so.6 -> 
libstdc++.so.6.0.8
-rwxr-xr-x 1 root root 939500 2007-05-04 06:17 /usr/lib/libstdc++.so.6.0.8
I have v5.0.7 and v6.0.8 installed. The linker automatically picked up version 
6 - but not 6.0.8. This way my system will need v6 but any v6.y.z version 
will work. I'll be good moving from centos 4.0 to 4.5

To check either install a older version or temporarily (on a test box of 
course) move 6.0.8 to 6.0.7, rerun ldconfig . Your code will still work. If 
you remove it altogether, and leave only v5, ldd won't pick up version 5.0.7 
because your binary requires v6... 
 
Because Linux uses <libname>.so.<version> you can't easily request a specific 
version (6.0.8 and not just any 6) like on Darwin where it is 
<libname>.<version>.dynlib ... That is the main reason why you will barely 
find anything more specific than the major version number...

And to sum it up in one line:
You should be OK unless that 3rd party vendor did something really stupid.

Peter.