Unexpected difference between _CS_GNU_LIBPTHREAD_VERSION and actual version

[Elmar Krieger]

Hi everyone,

my program is dynamically linked with libpthread, and 
confstr(_CS_GNU_LIBPTHREAD_VERSION,...) returns

NPTL 2.3.3  (on Fedora Core 3)

But if I analyze the program with GDB, I get output like:

Dump of assembler code for function pthread_attr_setaffinity_np@@GLIBC_2.3.4:
0x00a03ea0 <pthread_attr_setaffinity_np@@GLIBC_2.3.4+0>:        push   %ebp
0x00a03ea1 <pthread_attr_setaffinity_np@@GLIBC_2.3.4+1>:        mov    %esp,%ebp
0x00a03ea3 <pthread_attr_setaffinity_np@@GLIBC_2.3.4+3>:        push   %edi
0x00a03ea4 <pthread_attr_setaffinity_np@@GLIBC_2.3.4+4>:        push   %esi
0x00a03ea5 <pthread_attr_setaffinity_np@@GLIBC_2.3.4+5>:        push   %ebx
0x00a03ea6 <pthread_attr_setaffinity_np@@GLIBC_2.3.4+6>:        sub    $0x10,%es
p
0x00a03ea9 <pthread_attr_setaffinity_np@@GLIBC_2.3.4+9>:        mov    0x10(%ebp
),%esi
0x00a03eac <pthread_attr_setaffinity_np@@GLIBC_2.3.4+12>:       mov    0xc(%ebp)


So why does confstr return "2.3.3" while the actual symbols indicate "2.3.4"?

This kills me because the function prototype of pthread_attr_setaffinity_np has 
been changed from 2.3.3 to 2.3.4 (if I read the libc sources correctly), so I 
have to determine at run-time which parameters to pass in which order, after 
obtaining the entry point with dlsym. (My program must also run on older 
libpthreads that don't know pthread_attr_setaffinity_np yet).

Any more secure way than using 'confstr' to determine at runtime which arguments 
pthread_attr_setaffinity_np expects?

Many thanks for your help,
Elmar

P.S.: If I look at /lib/tls/libpthread.so.0 in a hex-editor, I see that it 
contains @@GLIBC_2.3.3 and @@GLIBC_2.3.4 symbols.