Vincent Cojot wrote:

Hi everyone,

At one of my customer sites, we use a number of 'legacy' custom-built graphical
apps built with glibc-2.1.
typically, these apps use X11, motif and.. OpenGL/GLX.
Also, some of these apps require the use of the infamous "export
LD_ASSUME_KERNEL=2.2.5" under RHEL3/RHEL4.

But alas, the time has come to move to a newer RHEL along with an x86_64 kernel.

Since they aren't ready to give up on these apps or re-build them (lack of
engineering resources), I am left with the following transition options:

1) run a fully copy of RHEL4 x86 under VMWare server on every RHEL5/x86_64
workstation and export the app display to the native RHEL5 display using the
network.

2) find a way to provide a full set of ia32 libraries under RHEL5 to enable
those legacy apps on an x86_64 RHEL.

3) run the apps in a paravirtualized 32bit guest (but that's not
supported/doable on RHEL 5.1, right?)

4) use the Solaris/SPARC version of those 32bit apps and get newer SPARC
workstations since these apps run very fine on modern 64bit SPARC workstations
under Solaris 10 and will continue to run under 11.

- I fear that option 1) would eat up all of the resources very quickly.
- On the other hand, I haven't noticed any official document on providing a full
set of ia32 libs under the x86_64 version of RHEL5 like what exists on Solaris.
- I heard the 'LD_ASSUMER_KERNEL' stuff is gone in RHEL5, is that true?
- I'd like to avoid option 4) because of all the trouble in re-deploying just
about everything.

Any comments, ideas, relevant documents/links very welcomed.

Thanks,

Vincent S. Cojot



On my x86_64 RH5.1 system:

$ export LD_ASSUME_KERNEL=2.2.5
$ ls
ls: error while loading shared libraries: librt.so.1: cannot open shared object file: No such file or directory

So, it is certainly true that you can't do LD_ASSUME_KERNEL=2.2.5 anymore.

One of the benefits of Redhat Enterprise was the long support window for each major release. So if you don't want to re-deploy to Solaris, I'd keep it on RH4. VMware server runs reasonably if you've got decent memory and fast disk (I/O is a major bottleneck).

Hugh


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list

Reply via email to