I've recently come about a Python extension/package build via CFFI which uses pthread_atfork (and a pthread mutex) but does not link against pthread, i.e. specifies neither -pthread nor -lpthread and hence fails on systems which have a static part which is linked in by a libpthread link script (as opposed to a purely shared library) due to missing symbols.
When thinking about the correct fix I stumbled over the Difference between -pthread and -lpthread while compiling. So using -pthread on compile and link step does not only place -lpthread at the correct position (crucial in the above setup) but also defines preprocessor symbols which change definitions of functions.
An example of a (third-party) function is boost::datetime::c_time::localtime(...) which calls either localtime_r or std::localtime.
Isn't that a (very likely) source for ODR violations? So e.g. compiling a simple static library not using threads at all without -pthread and linking that into a binary which does use threads and hence is using -pthread will lead to different definitions of such a function and be UB(/IB?)?
However from my /usr/include/features.h I see
_REENTRANT, _THREAD_SAFE
Obsolete; equivalent to _POSIX_C_SOURCE=199506L.
So questions:
- Are/were there ODR violations due to
-pthreadand if so why (was it not avoided/on purpose/an oversight)? - Are those definitions no longer relevant? So
-pthreadis now equivalent to-lpthread(save the placement)? - What should one use to build a CFFI extension for Python? Using
-pthreadis difficult due to compiler dependent naming (-pthread, -pthreads, -mthreads, ...)