[openssl-dev] Self-initialization of locking/threadid callbacks and auto-detection of features

[Florian Weimer]

On 10/30/2013 12:15 AM, Nico Williams wrote:
> On Tue, Oct 29, 2013 at 09:58:25PM +0100, Andy Polyakov wrote:
>> pthreads and Windows, and one can indeed argue why wouldn't OpenSSL
>> simply default to either of the two when appropriate. While it's
>> more than appropriate on Windows as it is, on pthreads-powered
>> Unices it's not as obvious. Because pthreads can be undesired in
>> some situations. Basically it boils down to question whether or not
>> libcrypto may be linked with libpthread or not. And answer is
>> actually "not desired." Ideally libcrypto should *detect* if

Detecting things in libcrypto is very difficult on GNU/Linux due to the
way dynamic linking works.

> More details would be nice.  What follows is speculation of mine as to
> what you might have in mind (or even if you don't, it might be
> relevant).
> 
> To summarize the below:
> 
>     OpenSSL .so's should always be linked with -lpthread on OSes where
>     there's a standard libpthread that threaded apps are expected to
>     use; OpenSSL static link archives should assume no threading
>     libraries and rely on the callers to provide the threading
>     callbacks.

On GNU/Linux, you should try very hard to avoid linking -lpthread and
restrict yourself to the pthreads API subset which is available without
-lpthread.  If something is missing, we (as in glibc upstream) can move
additional functionality from libpthread to libc.

Linking -lpthread has a real performance hit for unthreaded
applications, so core libraries should avoid it.

If you have received advice to the contrary, your source of advice is
wrong. :-)

-- 
Florian Weimer / Red Hat Product Security