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 DACFE3857003 for ; Tue, 8 Dec 2020 23:08:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DACFE3857003 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 librem (deer0x15.wildebeest.org [172.31.17.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id CBC8237251CB; Wed, 9 Dec 2020 00:08:03 +0100 (CET) Received: by librem (Postfix, from userid 1000) id 1E538C1BA2; Wed, 9 Dec 2020 00:07:04 +0100 (CET) Date: Wed, 9 Dec 2020 00:07:04 +0100 From: Mark Wielaard To: "Dmitry V. Levin" Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH] debuginfod: export DEBUGINFOD_SONAME macro in debuginfod.h Message-ID: <20201208230704.GD3189@wildebeest.org> References: <20201130090000.GA30063@altlinux.org> <20201206122813.GA27041@altlinux.org> <70c7aa3cc1fdda6b6c886d714178654dfd0757d0.camel@klomp.org> <20201208151540.GD28403@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201208151540.GD28403@altlinux.org> User-Agent: Mutt/1.10.1 (2018-07-13) 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 23:08:06 -0000 Hi Dmitry, On Tue, Dec 08, 2020 at 06:15:40PM +0300, Dmitry V. Levin wrote: > On Tue, Dec 08, 2020 at 01:02:41PM +0100, Mark Wielaard wrote: > > On Sun, 2020-12-06 at 15:28 +0300, Dmitry V. Levin wrote: > > > On Sun, Dec 06, 2020 at 01:06:42PM +0100, Mark Wielaard wrote: > [...] > > > > 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. > > > > > > 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. > > Mark, would you like a re-spin of the patchset containing the VERSION variable > removal, or would you prefer an additional patch removing this variable? I am not very worried what happens to VERSION in the Makefile.am file. I think it gets unused in your final patch, so just remove it in the patch that makes it unused. I did look at the patchset and do have some comments. Patch 1/3 looks fine. If you could merge 2/3 and 4/3 that would be nice. I think that makes things more clear what is going on. In Patch 3/3 I think we can now use DEBUGINFOD_SONAME in the dlopen call. The code does sanity checks to make sure all needed symbols are there, so it doesn't necessarily need the precise VERSION. And that way the code does look the same as other code that would actually want to dlopen debuginfod.so.1. Or is there a reason to prefer the full name? Thanks, Mark