Hi Mark, On Wed, Dec 09, 2020 at 12:07:04AM +0100, Mark Wielaard wrote: > 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.
OK > 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. OK > 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? Either way should work fine for __libdwfl_debuginfod_init, I'll change it to use DEBUGINFOD_SONAME then. -- ldv
