Just now getting to cleaning up my mailing list folder and came across this so apologize for reopening an older thread. We will likely appreciate the patch a great deal as we needed to switch to lld form clang (this past week). When we made this switch (had some size related issues with sanitizer builds in our app with ld) lld definitely complained about the symbols not being defined.
I don't have more of the output saved from when we found this, but did save off these lines while discussing with the team. ld.lld: error: version script assignment of 'DPDK_23' to symbol 'rte_eal_hpet_init' failed: symbol not defined ld.lld: error: version script assignment of 'DPDK_23' to symbol 'rte_get_hpet_cycles' failed: symbol not defined ld.lld: error: version script assignment of 'DPDK_23' to symbol 'rte_get_hpet_hz' failed: symbol not defined On Thu, Mar 5, 2026 at 7:30 AM David Marchand <[email protected]> wrote: > On Wed, 18 Feb 2026 at 11:19, David Marchand <[email protected]> > wrote: > > > > The .map generation script has no clue about build configuration as it > > relies only on the presence of RTE_EXPORT* and RTE_VERSION* markers in > > a source file. > > > > As a consequence, Linux eal_exports.map contains references to > > HPET symbols regardless of the use_hpet meson option value. > > > > $ meson configure build -Duse_hpet=false > > $ ninja -C build > > ... > > $ grep hpet build/lib/eal_exports.map > > rte_eal_hpet_init; > > rte_get_hpet_cycles; > > rte_get_hpet_hz; > > > > As far as I have seen, superfluous exports have no impact on generating > > a shared library with the GNU linker, yet it might be different with > > other linkers (MSVC linker would complain, for example). > > > > Moving those symbols to a dedicated source file solves this (non?) issue. > > > > Fixes: 57c194d142d9 ("build: use dynamically generated version maps") > > > > Signed-off-by: David Marchand <[email protected]> > > Acked-by: Chengwen Feng <[email protected]> > > Applied, thanks. > > > -- > David Marchand > >
