Hi Kamil, On Sat, 9 Sep 2017, Johannes Schindelin wrote:
> Actually, there is a remaining problem with that PR (which was sadly > closed, but I think we need to get this problem fixed ASAP): when > compiling cURL with NSS and, say, Secure Channel support, and Secure > Channel is selected at runtime, then Curl_nss_init() will not have been > called, ergo nss_initlink won't be initialized, and hence > Curl_nss_force_init() will complain thusly: > > unable to initialize NSS, curl_global_init() should have > been called with CURL_GLOBAL_SSL or CURL_GLOBAL_ALL > > I see that you added this test yourself, in f3b77e561 (http_ntlm: add > support for NSS, 2010-06-27). > > So I see two options to move forward, building on PR 1848: > > 1) move NSS *waaaay* down in the #if..#elif chain in curl_ntlm_core.c > > 2) change Curl_nss_force_init() so that it can be called *without* > Curl_nss_init() having been called before that. > > The easier method would be 1), I guess. > > For 2), we could introduce yet another lock (or a super-ugly workaround by > calling Curl_nss_init() directly from Curl_ssl_init() if NSS is not the > current backend and neither OpenSSL nor GNU TLS support was compiled in). > > What do you think? Update: PR 1848 was reopened (I am really happy about that), and 1) was chosen as the best way forward. Ciao, Johannes ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
