On Tue, Apr 03, Matt Wilson wrote: > Or use glibc 2.X.Y (2.X.Y > 2.2.2) in /lib/lsb. If there is a change > in glibc that would break backwards compatibility (older applications, > including LSB applications, not running on newer glibc), it's a bug in > glibc.
We introduce ld-lsb.so.1 exact for the this case, to be on the safe side if some glibc functions will be binary incompatible. Uli Drepper will not gurantee that this will never happen. And we now that we sometimes have to break compatibility if a old version was wrong. Thorsten > > Matt > > On Tue, Apr 03, 2001 at 07:54:35PM +0200, Thorsten Kukuk wrote: > > > > This is not the problem. Even if we can filter out ld-linux.so.2, > > it must not work. > > Assume: > > /lib/ld-lsb.so.1 is from glibc 2.2.2 > > /lib/ld-linux.so.2 is from glibc 2.X.Y (2.X.Y > 2.2.2) > > > > Now, which libc.so.6 will you use ? > > /lib/lsb/libc.so.6 ? What happens if libreadline is compiled against > > glibc 2.X.Y and uses newer versions of functions ? > > /lib/libc.so.6 ? This will not work, since /lib/ld-lsb.so.1 is to old for > > for /lib/libc.so.6. > > > > So, the only solution is to recompile and link libreadline against > > glibc 2.2.2/ld-lsb.so.1 in this example -> we need to do this with > > every LSB library. -- Thorsten Kukuk http://www.suse.de/~kukuk/ [EMAIL PROTECTED] SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background.
