Re: [PATCH] build: fix linker warnings about undefined symbols

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

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.

ty

> 
> /Bruce