On Wed, Feb 8, 2012 at 1:56 PM, Marcus Meissner <mar...@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