libc5 Compatibility in Red Hat 7?

A curious Anonymous Coward wrote in with this important issue: "RedHat Linux 7.0 does not include libc5 compatibility libraries. Trying to run an old binary (RH4.2 or earlier) generates a "no such file or directory" error. To what extent does Red Hat commit to binary backward compatibility? Is it possible to get libc5-based programs, such as MATLAB, working under RH 7 without recompiling?"

Comments

Use old RPMs

[yist]

The old libc5 RPM from 6.x and 5.x should still work fine if you need it.

Yeah, not even on the Powertools CD!

[BitMan]

If I didn't miss anything in my investigation, it looks like RedHat did not even put them on the Powertools CD! That is a _huge_ mistake IMHO!

They should always include anything that gives you backwards compatibility, even if they put it on a separate CD -- like the Powertools CD. Heck, it looks like they have at least 50MB free on it! Why not RedHat? [ And to think I've stuck with RedHat all these years because they don't pull stuff like this! Ha! ]

-- Bryan "TheBS" Smith

Re:Yeah, not even on the Powertools CD!

[King of the World]

I (hereby) agree.

It's amazing how much Mandrake are better at the desktop - even on the Gnome side - and Debian among others are better as the server.

I'm waiting for mandrakeisnotlinux.org.

Do we really want this

[Kefaa]

While I appreciate the desire to avoid changing do we really want a release to be forced to maintain such functionality.

It does raise the question how much do we want to support? Do we force everyone into an upgrade at each release? Should we take the approach much like windows that everything that functioned in you last upgrade still does?

Both options are limiting in one respect or another. However in the OOS environment, if my only fixes come in a new release, then how do I manage both without coding my own version? This is certainly not an option for the mainstream applications users.

Re:Do we really want this

[skullY]

While I appreciate the desire to avoid changing do we really want a release to be forced to maintain such functionality.

I see no problem with maintaining backward compatability as long as it's not holding back the forward progress. In this case, keeping support for libc5 (And even a.out libc4) binaries is simply a matter of keeping the libraries around, it doesn't stop someone from moving forward on libc6.

And for the guy who said it's holding back Linux the way that dos compatability is holding back Win2k, you need to stop smoking crack. Win2k still has a lot of legacy code in it because it HAS to have it to run. I don't see old libc5 code hanging around in glibc2 because the libc5 programs need it to run. In fact, the libc5 programs don't, and can go on happily using libc5 while libc6 gets broken all to hell.

FWIW too, Slackware 7.1 still includes a.out (libc4) binary support. From slakware/ a1/ diska1:

aoutlibs: a.out (libc4) shared libraries
aoutlibs:
aoutlibs: These shared libraries provide support for running Linux binaries
aoutlibs: compiled in the now obsolete a.out binary format. These libraries
aoutlibs: can be found in /usr/i386-slackware-linux-gnuaout/lib.
aoutlibs:
aoutlibs: Adds crt0.o, libvga.so.1.2.9, libdb.so.1.85.1, libc.so.4.7.6,
aoutlibs: libcurses.so.0.1.2, libm.so.4.6.27.

And how much extra cruft does this add to your install? About a meg, uncompressed.

Re:Install the rpms from RedHat 5.x and 6.x...

[NNKK]

whoa there buddy...
in my enviorment, being able to run DOS apps in win2k is vital, and there's no reason to remove MS-DOS compatability from win2k, it doesn't slow anything down unless it's actually in use, and the amount of drive space it takes up is nill in todays computers

Time to move on...

[\\x/hite \\/ampire]

Over the past few releases I've been watching alot of my favorite applications (xv, bsd-games, ...) disappear and a lot of others (vi, rcs, ...) break. Because of this I've had to go back to older distribution CDs to get everything back to working condition. Now that they're cutting libraries, this will no longer be posible. Not to flame, but I am seriously considering switching distros for something a bit more reliable. Does anyone have suggestions for a decent distro that can provide a reliable server and robust workstation?

I'm open to any linux or bsd suggestion.

Library dependancy issues.

[shippo]

If you need to run some libc5 only binary, you also often require other libc5 shared libraries as well as libc5, due to these libraries also being dynamically linked against libc5. Loading the wrong library will result in segfaults. Common libraries include ncurses, the various C++ libraries, and some XFree86 libraries.

Ld.so can differentiate between libraries dynamically linked against different libc versions, loading the correct one.

Re:Time to move on...to FreeBSD

[CowbertPrime]

One word. FreeBSD.
Perfect for both server and workstation.
Easy installation.
Easy upgrade and low maintenance. Also, free uptodate security advisories on freebsd.org itself.
CVS support = global upgradeability. You cvsup to freebsd's cvs tree, pull the new stuff, then 'make world' to synchronize kernelspace with userspace and voila. Upgrade done.
Tons and tons of software - on the /usr/ports collection.
No native library conflicts like linux. BSD binaries, are...BSD binaries. That means they are cross compatible with BSD based kernels. Furthermore, you can install the linux binary compatiblity port which lets you run ELF binaries (I haven't used this so I don't know how well it works).
No linux kernel issues. Since everything is based on the revision control system called CVS, you don't need to diff patch your kernel, just cvsup.
And if you write new things for BSD, the BSD licence makes more sense than GPL *wink* *wink* since you can actually resell your code instead of being forced to give it away!

wow they really are getting a bad rep

[josepha48]

With the release of Rh 7.0 I have seen more articles about RH 7.0 and how so many people are pissed off at what they have done to it.

Now about the libc5 thing. I'd recommend recompiling, especially if it is an X program. Most newer programs use libc6 anyway, maybe it is time for you to upgrade your software. Unfortuantely that is the way of the software world.

Examples: Java jdk 1.02 vs 1.1. gtk1.0 vs 1.2. libc5 vs libc6. Does anyone use jdk 1.02 anymore? Not if they are doing something new. Maybe legacy software, in which case it is time to upgrade that software. Even in windows there are incompatibilities between win 3.1 and 95, and 98, NT 3.51, NT 4.0 and win 2k. Not only between major software releases but also between service packs. This is the 'trend' in software.

Personally I think that they should and need to have compatibility in RH 7.0 though, only if they boast that you can upgrade from 2.0 or later with the install cd. Anyone who has been using RH since 2 or 4 and has upgraded there machines probably still has lots of libc5 programs. Not that they may have come with the distro, but more likely because they have installed them on there own.

Just my .02 cents............

I don't want a lot, I just want it all!
Flame away, I have a hose!