A patch for io/Versions and linuxthreads/Versions

[H . J . Lu]

On Thu, Nov 09, 2000 at 11:23:34AM -0800, H . J . Lu wrote:
> On Thu, Nov 09, 2000 at 10:22:57AM -0800, Ulrich Drepper wrote:
> > "H . J . Lu" <hjl@valinux.com> writes:
> > 
> > > 	* linuxthreads/Versions (libpthread:GLIBC_2.2): Move pread,
> > > 	__pread64, pread64, pwrite, __pwrite64, pwrite64, lseek64 and 
> > > 	open64 to ...
> > > 	(libpthread:GLIBC_2.1): Here.
> > 
> > This is wrong.  There were no such symbols in the 2.1 version.
> > Therefore applications which as linked against 2.2 and run with 2.1
> > will silently fail.  These are exactly the kind of things the
> > versioning mechanism is catching.
> > 
> 
> It is very unfortunate. But I don't think there is nothing we can
> do about it. If there is a new symbol in linuxthreads 2.2 which must
> be linked with every single pthread application. In that case, any
> pthread application linked with 2.2 will fail with 2.1. The alternative
> is pthread applications in 2.2 may fail silently due to wrong functions
> being used.
> 

Here is a testcase:

# make
cc -g -O   -c -o test.o test.c
cc -o foo.os -c -g -O -fPIC foo.c
cc -shared -o libfoo-1.so foo.os -lpthread
cc -o test1 test.o libfoo-1.so -lpthread -Wl,-rpath,.
cc -shared -o libfoo-2.so foo.os
cc -o test2 test.o libfoo-2.so -lpthread -Wl,-rpath,.
./test1
open is ok
pread is ok
./test2
open is ok
pread is not ok
make: *** [all] Error 1

The problem is libfoo-2.so is built with

# cc -shared -o libfoo-2.so foo.os

which binds pread to the one in libc. Later even

# cc -o test2 test.o libfoo-2.so -lpthread -Wl,-rpath,.

won't help. In this case, pthread applications in 2.2 may fail
silently. I think we have to make sure versions in libc and
linuxthreads are the same for a function. It is bad when applications
linked against 2.2 may fail silently under 2.1. But it is even worse
when pthread applications in 2.2 fail silently.

-- 
H.J. Lu (hjl@valinux.com)