Hi Dirk, On Tue, 2022-03-29 at 13:06 +0200, Dirk Müller wrote: > Am Di., 29. März 2022 um 09:42 Uhr schrieb Mark Wielaard < > m...@klomp.org>: > > The patch itself looks right. But I am slightly afraid this > > (theoretically?) will break some programs which set DEBUGINFOD_URLS > > themselves. We currently have no other way to make libdwfl use > > debuginfod-client. Thoughts? > > I was concerned about that as well, but I couldn't google a case where > this is the case. What we can also do is to do the initialization > lazily upon first use rather than in a > constructor function, but the intention of initializing early has been > specified as avoiding issues in multiple threads with libcurl: > > commit fa0226a78a101d26fd80c7e9e70a5f0aa6f9d1cc > Author: Mark Wielaard <m...@klomp.org> > Date: Sun Nov 17 22:17:26 2019 +0100 > > debuginfod: add client context > > Add a mandatory debuginfod_begin()/_end() call pair to manage a client > object that represents persistent but non-global state. From libdwfl, > dlopen the debuginfod.so client library early on. This hopefully > makes sure that the code (and the libcurl.so dependency) is loaded > before the program goes into multi-threaded mode. > > > What we can do is both, do the reinit at a later point in time if the > environment variable happens to be set at that point in time. then you > are risking the thread-safety issues only when there is no other way. > > Or just do it lazily on demand, and work through the libcurl or > whatever the unsafety issue is.
This is indeed the (safety) issue I am concerned about. I just sent an email to the libcurl mailinglist (CCed to the elfutils-devel list) to ask about how/when/if a library should call curl_global_init. https://curl.se/mail/lib-2022-03/0118.html Lets see what the curl developers say and then decide what to do. Cheers, Mark
