From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vmicros1.altlinux.org (vmicros1.altlinux.org [194.107.17.57]) by sourceware.org (Postfix) with ESMTP id 95C693858C27 for ; Wed, 9 Dec 2020 15:35:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 95C693858C27 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=altlinux.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ldv@altlinux.org Received: from mua.local.altlinux.org (mua.local.altlinux.org [192.168.1.14]) by vmicros1.altlinux.org (Postfix) with ESMTP id 4589972C8B1; Wed, 9 Dec 2020 18:35:23 +0300 (MSK) Received: by mua.local.altlinux.org (Postfix, from userid 508) id 1B8957CC8A3; Wed, 9 Dec 2020 18:35:23 +0300 (MSK) Date: Wed, 9 Dec 2020 18:35:23 +0300 From: "Dmitry V. Levin" To: "Frank Ch. Eigler" Cc: Mark Wielaard , Vitaly Chikunov , elfutils-devel@sourceware.org Subject: Re: [PATCH] libdwfl: Do not dlopen libdebuginfod if DEBUGINFOD_URLS is unset or empty Message-ID: <20201209153522.GA14179@altlinux.org> References: <20201105144452.30409-1-vt@altlinux.org> <95de2e2cf1dff241f0a5ce0828b17df654d05a94.camel@klomp.org> <20201109145757.GC28290@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201109145757.GC28290@redhat.com> X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 15:35:26 -0000 Hi, On Mon, Nov 09, 2020 at 09:57:57AM -0500, Frank Ch. Eigler via Elfutils-devel wrote: > Hi - > > > [...] The problem with doing the dlopen late is that we also need > > libcurl and initializing libcurl (as done by libdebuginfod) is not > > thread-safe. > > From reading libcurl code, and that of other clients, I still believe > this concern was & is overrated. We could back down to simple > debuginfod_begin time mutex-protected curl_global_init calls, and we'd > be as fine as other applications. We could ditch the dlopen / > dso-ctor issues entirely. Excuse me, has there been any follow-up to this discussion? -- ldv