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

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

[Thomas Monjalon]

10/01/2024 17:58, Tyler Retzlaff:
> 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>

+Cc stable

Applied as easy solution for this linker.

The discussion about Windows linker and use of macros
deserve to continue, maybe in a new dedicated thread?

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

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

[Tyler Retzlaff]

On Sun, Feb 18, 2024 at 06:38:22PM +0100, Thomas Monjalon wrote:
> 10/01/2024 17:58, Tyler Retzlaff:
> > 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>
> 
> +Cc stable
> 
> Applied as easy solution for this linker.
> 
> The discussion about Windows linker and use of macros
> deserve to continue, maybe in a new dedicated thread?

yes, i will start a new discussion on the topic after clearing other
windows / msvc changes as soon as i have time.

thanks!

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