libgcrypt thread safety

[Lei Zhang]

On Wed, Feb 8, 2012 at 1:56 PM, Marcus Meissner <marcus at jet.franken.de> wrote:
> On Wed, Feb 08, 2012 at 02:48:06PM -0600, Adam Martinson wrote:
>> I've been looking into bug 27036
>> <http://bugs.winehq.org/show_bug.cgi?id=27036> , and it's due to the
>> lack of thread safety by default in libgcrypt (in this case via
>> libgnutls in secur32.dll).  To be thread safe, libgcrypt requires a
>> call to gcry_control(GCRYCTL_SET_THREAD_CBS) before any libgcrypt
>> initialization is done.  However, libgcrypt is used by a lot of
>> different libs, one of which is being used by some other dll that's
>> loading before secur32.dll.
>>
>> My question is, is it acceptable to do the gcry_control() call in
>> ntdll's DllMain()?  The alternative seems to be tracking down every
>> lib used by wine that uses libgcrypt and doing it in each of those
>> dlls.  What's the best way to handle this?
>
> No, this would break abstraction.
>
> Why is libgcrypt needed here? It does not seem to be linked directly
> by any Wine component, also it seems strange that gnutls pulls it in...
>
> Can you call it on DllMain() on secur32.dll?
>
> Ciao, Marcus
>
>

I don't know the exact details, but libgcrypt and gnutls are related.
If you search for "gnutls thread safety", you'll find information like
this:

http://www.manpagez.com/info/gnutls/gnutls-2.10.4/gnutls_64.php

http://www.gnupg.org/documentation/manuals/gcrypt/Multi_002dThreading.html