> this is getting annoying, to say the least. I compile a program on a > woody|sid box (linkage: -ldl -lm, and -lc implicitly) and try to run it > on something (anything) else and the dynamic linker complains about not > being able to find version GLIBC_2.2. This happens more often than not > (in the particular case that triggered this email the other system has > libc 2.1.3, whose SONAME *is* libc.so.6). Is there a way to solve this > problem *without* installing a new libc on the *other* system? Glibc doesn't attempt to be forwards compatible: if you build a program against a particular version, you can't expect it to run on older versions. You need to build your binaries against the oldest version of libc that you expect to support. > Other instances of this problem, from the top of my head: am-utils will > break everytime a new libc is installed, in its most annoying > manifestation it doesn't fail to load, it just blocks trying to mount > any filesystem; nis also breaks after a libc6 upgrade (see > changelog.Debian for Miquel's comments regarding this). These, on the other hand, could be genuine bugs. I suggest you analyse the failure and report it with glibcbug if it seems that libc is at fault. p.
Attachment:
pgpuvnEmvv34e.pgp
Description: PGP signature