From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id CE905385800F for ; Tue, 8 Dec 2020 12:02:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CE905385800F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 7ADC537251C9; Tue, 8 Dec 2020 13:02:41 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 4F2FA413CB2B; Tue, 8 Dec 2020 13:02:41 +0100 (CET) Message-ID: <70c7aa3cc1fdda6b6c886d714178654dfd0757d0.camel@klomp.org> Subject: Re: [PATCH] debuginfod: export DEBUGINFOD_SONAME macro in debuginfod.h From: Mark Wielaard To: "Dmitry V. Levin" Cc: elfutils-devel@sourceware.org Date: Tue, 08 Dec 2020 13:02:41 +0100 In-Reply-To: <20201206122813.GA27041@altlinux.org> References: <20201130090000.GA30063@altlinux.org> <20201206122813.GA27041@altlinux.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Tue, 08 Dec 2020 12:02:47 -0000 On Sun, 2020-12-06 at 15:28 +0300, Dmitry V. Levin wrote: > Hi Mark, >=20 > On Sun, Dec 06, 2020 at 01:06:42PM +0100, Mark Wielaard wrote: > > Hi Dmitry, > >=20 > > On Mon, 2020-11-30 at 09:00 +0000, Dmitry V. Levin wrote: > > > Add DEBUGINFOD_SONAME macro to API for use by those of libdebuginfod > > > clients that would like to dlopen the library in the same way as > > > __libdwfl_debuginfod_init does. > >=20 > > I can see how this is useful, but shouldn't libdwfl/debuginfod-client.c= =20 > > then also use this method/new constants? >=20 > Thanks, I think libdwfl/debuginfod-client.c should use the versioned name > only, and it shouldn't fallback to "libdebuginfod.so" as it does now. > I'll submit a separate patch to address that. Thanks. > > Don't we need both versioned and versionless names (at least dwfl tries > > the versioned one first, then falls back to the unversioned one). >=20 > I don't think the versioned name should be exported because it changes > in every version while clients don't have to be rebuilt that often. I am slightly confused now what we call the versioned name. I assumed that was the SONAME aka libdebuginfod.so.1. In theory we never change the version, because we use symbol versioning. But yes, we only need to export one for dlopen purposes. > > It would be nice to see documentation in > > doc/debuginfod_find_debuginfo.3 >=20 > Yes, it would be nice, agreed. Thanks for adding that. > > Finally, I am actually using the Makefile VERSION variable in a > > downstream (DTS) to make sure the so name of all libraries is different > > from the system one. This is just a minor issue though, and I should > > probably upstream a tweak to do this upstream so others can also more > > easily use this. >=20 > Do you suggest to keep the Makefile VERSION variable? > It would become an unused variable with the remaining part of the patch > applied unless you upstream the tweak you are talking about. Lets just remove it for now. I'll figure something out for my special case. Cheers, Mark