[lsb-discuss] pthread_atfork

Wichmann, Mats D mats.d.wichmann at intel.com
Tue Sep 19 07:23:36 PDT 2006


>Potential inconsistency?
>
>Architecture: x86-64
>
>Running appchck on the Intel openMP library (libguide.so) produces the
>following output:
>
>Checking binary /opt/intel/cce/9.1.039/lib/libguide.so
>Section .text1: Not recognized by name. Checking as type SHT_PROGBITS
>Symbol syscall used, but not part of LSB_Modules
>Symbol pthread_getattr_np used, but not part of LSB_Modules
>
>Notable here is that appchck does not complain about pthread_atfork
>although this interface is used in the library:
>
>-> nm -Bg /opt/intel/cce/9.1.039/lib/libguide.so | grep pthread_at
>                 U pthread_atfork
>                 U pthread_attr_destroy@@GLIBC_2.2.5
>                 U pthread_attr_getstack@@GLIBC_2.2.5
>                 U pthread_attr_getstacksize@@GLIBC_2.2.5
>                 U pthread_attr_init@@GLIBC_2.2.5
>                 U pthread_attr_setdetachstate@@GLIBC_2.2.5
>                 U pthread_attr_setstacksize@@GLIBC_2.2.5
>
>According to a database search pthread_atfork is an IA32 interface.

pthread_atfork is a very weird case.  It ends up getting
resolved at link-edit time against libpthread_nonshared.a
and so it's considered a source-only interface: it's fine
appearing in source code, but should not appear in an
executable binary as a symbol to be resolved by dynamic
linking, as it will already have been resolved by static
linking.

It may be the online database query tool ("dbadmin") isn't
representing this state quite correctly - it's hard for me to
go look at that right now but I'll try to take a look later.
It is correct in the actual database: Interface.Iname is SrcOnly
for this entry.




More information about the lsb-discuss mailing list