From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Tyler Retzlaff" <roretzla@linux.microsoft.com>,
"Bruce Richardson" <bruce.richardson@intel.com>
Cc: <dev@dpdk.org>
Subject: RE: [PATCH] build: fix linker warnings about undefined symbols
Date: Fri, 12 Jan 2024 21:49:13 +0100 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F14E@smartserver.smartshare.dk> (raw)
In-Reply-To: <20240112201102.GA21063@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Friday, 12 January 2024 21.11
>
> On Thu, Jan 11, 2024 at 09:48:33AM +0000, Bruce Richardson wrote:
> > On Thu, Jan 11, 2024 at 10:38:05AM +0100, Morten Brørup wrote:
> > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > > Sent: Wednesday, 10 January 2024 17.58
> > > >
> > > > On Wed, Jan 10, 2024 at 03:01:03PM +0000, Bruce Richardson wrote:
> > > > > The default behaviour of "ld.lld" has changed, so it now prints
> out
> > > > > warnings about entries in the version.map file which don't
> exist in
> > > > > the current build. Since we use our version.map file simply to
> filter
> > > > > out the functions we don't want made public, we include in it
> all
> > > > > functions across all OS's and builds that we want public if
> present.
> > > > > This causes these ld warnings to be emitted, e.g. on BSD, which
> is
> > > > > missing functionality found on Linux. For example:
> > > > >
> > > > > * hpet functions in EAL
> > > > > * regexdev enqueue and dequeue burst
> > > > > * eventdev event_timer functions
> > > > >
> > > > > Easiest solution, without major rework of how we use our
> version.map
> > > > > files, and without dynamically generating them per-build, is to
> pass
> > > > > the --undefined-version flag to the linker, to restore the old
> > > > > behaviour.
> > > > >
> > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > ---
> > > >
> > > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > >
> > > > i don't know if has ever been discussed but a way to achieve a
> similar
> > > > outcome would be to introduce a visibility macro allowing the
> data and
> > > > function symbols to be explicitly made visible while making the
> build
> > > > default hidden.
> > > >
> > > > https://gcc.gnu.org/wiki/Visibility
> > >
> > > This looks interesting!
> > > Declaring a function "public" directly in its header seems much
> simpler to manage than having to add it to the version.map file too.
> > >
> > > I wonder if function versioning is still supported if using this
> instead of version.map files?
> > > Of if there are other relevant reasons for continuing to use the
> version.map files instead of this?
> > >
> >
> > I don't see in that wiki page and details of how to mark symbols with
> > different ABI versions. For example, as well as listing what
> functions are
> > public, our version.map files also identify the ABI version (e.g.
> DPDK_24)
> > they belong to, or whether they are experimental or internal. Having
> them
> > all in the version file also makes it easy to see how many
> experimental
> > functions we have in each component.
>
> you can use symver in combination with visibility default
>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
>
> anyway just food for thought, it would get me out of having to hack &
> enhance the .def from .map generation and unfortunately even with that
> there are going to be cases where i still have to annotate the actual
> symbol export in code (for windows).
>
> just thought a more unified approach for all might appeal.
Assuming that we truly want DPDK to support Windows, a more unified approach is a reasonable ask.
If we can eliminate the technical obstacles, we should pursue it.
We may have to sacrifice some "nice to have" advantages of the version.map files along the way, such as having easy access to the list of experimental functions in the version.map file.
next prev parent reply other threads:[~2024-01-12 20:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-10 15:01 Bruce Richardson
2024-01-10 16:58 ` Tyler Retzlaff
2024-01-11 9:38 ` Morten Brørup
2024-01-11 9:48 ` Bruce Richardson
2024-01-12 20:11 ` Tyler Retzlaff
2024-01-12 20:49 ` Morten Brørup [this message]
2024-01-12 22:22 ` Stephen Hemminger
2024-01-15 8:56 ` David Marchand
2024-01-15 16:17 ` Tyler Retzlaff
2024-02-18 17:38 ` Thomas Monjalon
2024-02-20 17:02 ` Tyler Retzlaff
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=98CBD80474FA8B44BF855DF32C47DC35E9F14E@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=roretzla@linux.microsoft.com \
/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 NNTP newsgroup(s).