From: "Dmitry V. Levin" <ldv@altlinux.org>
To: Mark Wielaard <mark@klomp.org>
Cc: elfutils-devel@sourceware.org
Subject: Re: [PATCH] debuginfod: export DEBUGINFOD_SONAME macro in debuginfod.h
Date: Sun, 6 Dec 2020 15:28:13 +0300 [thread overview]
Message-ID: <20201206122813.GA27041@altlinux.org> (raw)
In-Reply-To: <e4baa54d9011c70c3eefac58d8e91bf22eae91af.camel@klomp.org>
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.
> 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.
> It would be nice to see documentation in
> doc/debuginfod_find_debuginfo.3
Yes, it would be nice, agreed.
> 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.
--
ldv
next prev parent reply other threads:[~2020-12-06 12:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 9:00 Dmitry V. Levin
2020-12-06 12:06 ` Mark Wielaard
2020-12-06 12:28 ` Dmitry V. Levin [this message]
2020-12-06 13:32 ` Frank Ch. Eigler
2020-12-06 13:34 ` Dmitry V. Levin
2020-12-06 13:54 ` [PATCH v2 1/3] " Dmitry V. Levin
2020-12-06 13:54 ` [PATCH v2 2/3] debuginfod: create the fully versioned libdebuginfod file name during build Dmitry V. Levin
2020-12-06 14:44 ` [PATCH v2 4/3] debuginfod: create libdebuginfod files using a race-free method Dmitry V. Levin
2020-12-06 13:54 ` [PATCH v2 3/3] libdwfl: do not fall back to dlopen of libdebuginfod.so Dmitry V. Levin
2020-12-08 12:02 ` [PATCH] debuginfod: export DEBUGINFOD_SONAME macro in debuginfod.h Mark Wielaard
2020-12-08 13:30 ` Dmitry V. Levin
2020-12-08 15:15 ` Dmitry V. Levin
2020-12-08 23:07 ` Mark Wielaard
2020-12-08 23:20 ` Dmitry V. Levin
2020-12-09 0:12 ` [PATCH v3 1/3] " Dmitry V. Levin
2020-12-09 22:06 ` Mark Wielaard
2020-12-09 0:13 ` [PATCH v3 2/3] debuginfod: create libdebuginfod.so.1 before libdebuginfod.so Dmitry V. Levin
2020-12-09 0:30 ` Dmitry V. Levin
2020-12-09 22:12 ` Mark Wielaard
2020-12-09 0:13 ` [PATCH v3 3/3] libdwfl: switch to DEBUGINFOD_SONAME, remove libdebuginfod.so fallback Dmitry V. Levin
2020-12-09 22:43 ` Mark Wielaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201206122813.GA27041@altlinux.org \
--to=ldv@altlinux.org \
--cc=elfutils-devel@sourceware.org \
--cc=mark@klomp.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).