Hi - On Tue, Nov 19, 2019 at 09:15:20PM +0100, Mark Wielaard wrote: > > That's what the doc says. What the code does, as far back as the year > > 2001, is have a static flag/counter in curl_global_init() that > > prevents multiple initialization. > > But the warning isn't about multiple initialization. It is about > initialization when other threads are running that might be using any > of the libcurl support libraries.
Since 2001, the curl_global_init function does nothing to interfere with any libcurl activity, if the library is already initialized. Any call to the normal libcurl functions first calls this function. I guess I just fail to see a plausible problem scenario short of a minuscule race over incrementing an initialization counter, which is a race that every other libcurl user has accepted. > > > That is why I think doing the dlopen of libdebuginfod.so eagerly from a > > > libdw.so constructor function or _init might be necessary to make sure > > > no other threads are running yet. > > > > That's not even enough for "sure" - if we're so deep in the > > hypotheticals hole, an application could be dlopen()ing libdw.so > > itself. > > It could, but I think that would be unlikely. We can at least document > that it is unsafe to use libdw.so with dlopen. But if it is done, > could we detect it and not do the loading of libdebuginfod.so in that > case? I don't know how to do that. - FChE