On Sun, 2020-12-06 at 15:28 +0300, Dmitry V. Levin wrote: > Hi Mark, > > On Sun, Dec 06, 2020 at 01:06:42PM +0100, Mark Wielaard wrote: > > Hi Dmitry, > > > > 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. > > > > I can see how this is useful, but shouldn't libdwfl/debuginfod-client.c > > then also use this method/new constants? > > 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). > > 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 > > 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. > > 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
