Symbols, pread, __pread64, pread64, pwrite, __pwrite64, pwrite64, lseek64 and open64, have version name GLIBC_2.2 in libpthread. But they have version name GLIBC_2.1 in libc. Their version names are different. As the result, the wrong functions can be called in a thread application. I will attach a testcase here. # make cc -g -O -c -o test.o test.c cc -o foo.o -c -g -O -fPIC foo.c ar rv libfoo.a foo.o a - foo.o cc -o test1 test.o libfoo.a -lpthread cc -shared -o libfoo.so foo.o cc -o test2 test.o libfoo.so -lpthread -Wl,-rpath,. test1: `__pwrite64' is bound to /lib/libc.so test2: `pread' is bound to /lib/libc.so `__pread64' is bound to /lib/libc.so `pread64' is bound to /lib/libc.so `pwrite' is bound to /lib/libc.so `__pwrite64' is bound to /lib/libc.so `pwrite64' is bound to /lib/libc.so `lseek64' is bound to /lib/libc.so `open64' is bound to /lib/libc.so They all are supposed to be bound to libpthread, but they are bound to libc instead.
Created attachment 5480 [details] The testcase
Created attachment 5500 [details] A patch
I submitted a patch. It seems to work for me.
Unless Ulrich accepts this into CVS, I don't want to put this in, since it would just cause us to be incompatible with everyone else (binaries compiled with -lpthread on systems with your patch would not use the cancelation wrappers on systems without it).
As it stands today, glibc 2.2 is broken with thread applications. So far, Ulrich hasn't acknowledged it is a bug. If he doesn't see it as bug, which I believe it is, I don't know if he will accept it into CVS. BTW, thread applications with glibc 2.2 may not use the cancelation wrappers today. At least, it won't happen on systems with my patch installed.