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

["Morten Brørup" <mb@smartsharesystems.com>]

> 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?

> 
> on windows symbols are hidden by default (opposite of gnu toolchain)
> and
> allowing the symbols that are intended to be public be annotated in
> code
> with a macro instead of a separate map/def file would arguably appear
> more consistent.  additionally, the current process of converting a map
> file to a def file for windows has limitations with respect to things
> like marking the type of symbol being exported.
> 
> ty