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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
