On Oct 22, 2013 10:28 AM, "Ben Laurie" <[email protected]> wrote:
> On 22 October 2013 06:47, Nico Williams <[email protected]> wrote:
>> What I need to know:
>>
>>  - should i add new targets to ./Configure?  for now I modified the
linux-elf target, but this feels wrong to me.
>>
>>  - what about Windows?  I either need to have different targets for
pre-vista/2008 or. i have to write a once initialization function for older
Windows (which I can and know how to do, it's just more work that, and in
particular i couldn't test it, so I'm not inclined to do it).
>>
>>  - if so, should ./config automatically pick the new targets where there
is appropriate threading support?
>
>
> I've been musing about a more autoconf-like approach for some time now
(but, for the love of all that is fluffy, not using autoconf itself, which
sucks) - it seems this is a good reason to go down that path.

Well, I'm not signing up for that, not yet anyways!  :)  Short-term advice
will do.  I think I'll just add new targets and ./config logic for picking
then.

The fact that targets are stable-ish is useful, as it allows building
whatever targets one can build (or cross-build) on the host.  autoconf
can't do this, and that's one more reason not to autoconf.

> Interesting question is: what to do if no appropriate locking mechanism
is discovered?

I think for a linux-elf-pthread target the dependency on pthreads should be
hard.  The old linux-elf target should remain thread-unsafe (I can't make
OpenSSL fully thread-safe without a thread library).

But I could have a target that has a weak dependency on pthreads and is
safe when the library is present.  Ditto Windows (be unsafe pre-vista/2008,
safe in vista/2008 and later, using same OpenSSL DLLs builds).  I'd rather
add this variation later, after the meat of this work is done, assuming
such a variation is desired.

Nico
--

Reply via email to