Re: Dynamic Linker feature set query

[Mike Frysinger <vapier at gentoo dot org>]

On Tuesday, June 29, 2010 08:10:36 Petr Baudis wrote:
>   Their motivation is that they do not want to unconditionally depend on
> libpthread for single-thread applications, and they also do not want to
> depend on libpthread API in particular and instead allow "threading
> model" choice within the setup call - therefore, the setup call itself
> cannot do a proper lock before the threading model is set up.

glibc already provides support for this exact scenario.  many of the main 
libpthread functions are merely stubs in the C library that return appropriate 
success values when libpthread is not loaded.  if an app does link against 
libpthread, then the real pthread functions are called transparently.

i.e. on glibc systems, you may always utilize pthread mutex functions in 
shared libraries without needing to link against libpthread yourself and 
things will "just work".

>   I do not think this is a sane request. The OpenSSL guys want to keep
> their "generic threading model" same across all the systems and would
> prefer the platform to adapt to their requirements rather than them
> adapt to the requirements of the platform. I think this is bad attitude,
> and have two main issues:

agreed.  openssl's configure system is already a huge pile of crap with 
system-specific checks sprinkled all over.  simply add one more for glibc 
compatible targets and use the native threading library.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.