libc5 Compatibility in Red Hat 7? 10
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?"
Use old RPMs (Score:1)
Yeah, not even on the Powertools CD! (Score:2)
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
Do we really want this (Score:1)
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 (Score:1)
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 [slackware.com]:
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
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... (Score:1)
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
Re:Yeah, not even on the Powertools CD! (Score:1)
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.
Time to move on... (Score:1)
I'm open to any linux or bsd suggestion.
Library dependancy issues. (Score:2)
Ld.so can differentiate between libraries dynamically linked against different libc versions, loading the correct one.
Re:Time to move on...to FreeBSD (Score:1)
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
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 (Score:2)
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!