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 _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
