Hi Mark, Am Di., 29. März 2022 um 09:42 Uhr schrieb Mark Wielaard <m...@klomp.org>:
> I assume this is because debuginfod-client loads and initializes > libcurl, which triggers crypto checks for https support? Yes, the dependencies of the DSO contain libcurl and other libraries including the openssl library, which, when patched with FIPS support, take quite a while to initialize. > 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. Greetings, Dirk
