[EMAIL PROTECTED] said: > I'm no expert, but I thought glibc2.1 was supposed to be backward > compatible with glibc2.0. I have had problems when I have upgraded my > compiler from from 2.7.2 to gcc-2.95.x. The compiler is so good that > it optimizes out symbols that the old libraries expect to resolve. > The only way (that I know of) to fix this is to recompile the > libraries with the new compiler.
yes, but the problem R4 was not glibc2 - it was based of some random (well, OK, probably carefully selected) CVS snapshot the predates the final glibc2 release (long before glibc2 binary compatibility was frozen) and it diverged from there. it's... umm... *special*. (I thought I'd seen the end of it a long time ago - ugh). It's not just binary incompatible with glibc2.1, it's incompatible with the real glibc2.0 as well - it's just it's own little world. have you tried using fix961212 (from the bincompat package) on whatever program this is that you're trying to use? did that work? it often fixes up programs compiled against the old R4 glibc (a 12-12-1996 CVS snapshot of what eventually became glibc2, hence the name) to work with the real glibc2.0/2.1/whatever. just run it on all the libs and executables you can find in the package and pray :-) failing that, I guess I would get the R4 libc.so.6 (not that this is NOT really libc6, and is NOT compatible with a real libc6), stick it in it's own little directory somewhere, and play LD_LIBRARY_PATH games to make your program find it, but otherwise keep a system that doesn't use it. This could be a real headache though, as all the other libraries that your program uses will need to be recompiled against the old R4 glibc also, and installed with two copies. It depends on how many outside libs this packages uses. I hope that fix961212 does the job, it's really your best hope...
