Michel van Deventer wrote:

At 06:29 27-9-2007, Art Edwards wrote:

...

I am building a Centos machine for a specific piece of third party software.

Can I assume that the IA64 verson of CENTOS 4.5 will run on this CPU?

No, you cannot run IA64 on a Core2Duo, you need the AMD64 or x86_64 version.

...

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.

    Regards,

    Michel

...

Art Edwards _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

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.

On Thursday 27 September 2007, John R Pierce wrote:

...

Thanks for the feedback. Unfortunately, the third-party software will be a binary that was built against specific library versions.

all subversions and incremental updates of a RHEL/CentOS major version use the same library versions, they backpatch critical updates and bugfixes.

For instance, CentOS5 has glibc 2.5, python 2.4.3, apache httpd 2.2.3, php 5.1.6, ... it will always have these versions regardless of updates.

the only time incremental updates should break things on a RHEL/CentOS system is add-on kernel modules and drivers, these need to be reinstalled after each incremental kernel update.

Wow - my answer could have been that simple :)

Peter.

on 9/27/2007 8:06 PM Art Edwards spake the following:

Is anyone running Cadence tools on Centos?

How does this apply to this thread? Please don't hijack threads. It tends to aggravate the inmates!

Art Edwards

John R Pierce wrote:

...

...

Thanks for the feedback. Unfortunately, the third-party software will be a binary that was built against specific library versions.

all subversions and incremental updates of a RHEL/CentOS major version use the same library versions, they backpatch critical updates and bugfixes.

For instance, CentOS5 has glibc 2.5, python 2.4.3, apache httpd 2.2.3, php 5.1.6, ... it will always have these versions regardless of updates.

the only time incremental updates should break things on a RHEL/CentOS system is add-on kernel modules and drivers, these need to be reinstalled after each incremental kernel update.

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos