http://bugs.winehq.org/show_bug.cgi?id=27036
--- Comment #16 from Adam Martinson adam.r.martinson@gmail.com 2012-03-18 21:11:52 CDT --- (In reply to comment #14)
Just a guess, but a few dlls import secur32: austin@aw21 ~/wine-git $ git grep secur32 | grep IMPORT dlls/rpcrt4/Makefile.in:DELAYIMPORTS = iphlpapi wininet secur32 user32 dlls/schannel/Makefile.in:IMPORTS = secur32 dlls/secur32/Makefile.in:IMPORTLIB = secur32 dlls/security/Makefile.in:IMPORTS = secur32 dlls/wininet/Makefile.in:DELAYIMPORTS = secur32 crypt32 cryptui
Wouldn't secur32's DllMain() still get called when it's imported?
(In reply to comment #15)
I don't think current versions of gnutls use libgcrypt anymore, so at least as far as secur32 is concerned this should go away on its own. If it did though, I'd argue that it should be up to gnutls to properly initialize libgcrypt, e.g. in gnutls_global_init(). Wine shouldn't have to care about what crypto backend gnutls was compiled with.
I agree, but I think it's not only a gnutls issue... My guess is some other lib is pulling in gcrypt and initializing it without setting the threading model, the same way gnutls does.
Fortunately it looks like gcrypt will fix this itself in the next release (1.6? See git://git.gnupg.org/libgcrypt.git => 5a1b2784cc1a718fd44d551b7ec018ef4614ce30). I would say just let people who need to use the hack until then.