On 06/15/2015 06:02 PM, Nico Williams wrote:
> On Thu, Jun 11, 2015 at 10:41:58AM +0200, Florian Weimer wrote:
>> Detecting things in libcrypto is very difficult on GNU/Linux due to the
>> way dynamic linking works.
>
> Details?
Detection based on weak symbols can break due to linking order (if t
On Mon, Jun 15, 2015 at 06:19:49PM +, Salz, Rich wrote:
> My overall goal is that I want to remove the thread callback stuff.
Excellent.
> Ideally we have two options: no threads and system-threads.
Presumably that would be either a configure-time option or a run-time
automatic option, but n
My overall goal is that I want to remove the thread callback stuff. Ideally we
have two options: no threads and system-threads.
It seems that on Linux shared/static libraries might be an issue. I hope we
can resolve and simplify that.
___
openssl-de
Hmm, another option is to use weak symbols to detect presence of
pthreads. This should work regardless of whether static or dynamic
linking is used.
A statically-linked, single-threaded program that dlopen()s an object
that brings in libpthread will have different OpenSSL dependencies for
the dy
On Thu, Jun 11, 2015 at 10:41:58AM +0200, Florian Weimer wrote:
> Detecting things in libcrypto is very difficult on GNU/Linux due to the
> way dynamic linking works.
Details?
> On GNU/Linux, you should try very hard to avoid linking -lpthread and
> restrict yourself to the pthreads API subset wh
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 p
