On Thu, 4 Jun 2026 09:50:25 +0200 David Marchand <[email protected]> wrote:
> On Wed, 3 Jun 2026 at 17:56, Stephen Hemminger > <[email protected]> wrote: > > > > On Wed, 3 Jun 2026 12:01:48 +0200 > > David Marchand <[email protected]> wrote: > > > > > Hello, > > > > > > On Wed, 3 Jun 2026 at 00:57, Stephen Hemminger > > > <[email protected]> wrote: > > > > > > > > When using function versioning and building with Link Time Optimization, > > > > the compiler does not see the __asm__ annotation of symbols and > > > > therefore thinks there are two versions of the same symbol. > > > > > > > > The fix is to use compiler symver attribute on the function which > > > > was added in GCC 10. Keep the older method for backward compatibility > > > > with older compilers. > > > > > > > > Bugzilla ID: 1949 > > > > Fixes: e30e194c4d06 ("eal: rework function versioning macros") > > > > > > We never used the symver stuff, so it seems unlikely the issue was > > > introduced with this rework. > > > > > > The fact that clang does not support this attribute is a concern. > > > > Clang doesn't have this problem. It works as is. > > The Fixes: tag is wrong regardless. > The issue is probably present since introduction of the versioning > macros, or introduction of LTO in DPDK (not sure which came first). Right the Fixes is wrong, will resend without > > > > > > Cc: [email protected] > > > > > > Why do we need to backport? > > > > Well LTO has worked for a long time, it is not experimental just > > not commonly done since it takes so long to build. > > > > We were doing it years ago at MSFT. > > Well, sorry, but every time I enable LTO, I end up with some warnings > somewhere. > I don't think I am doing stuff really exotic though. Using LTO has always been extra effort. It is worth it for largish legacy code because the compiler can crunch things down. > > Looking at bugzilla, we had various fixes for LTO over the years. > We still have one open bz btw: https://bugs.dpdk.org/show_bug.cgi?id=1709 That bug was fixed a while back. It required addition of hints (__rte_assume) > > Hence my feeling this feature is not something used by many people around. > And without a CI, we will keep on having to fix bugs/issues. > > > > > LTO is kind of experimental, so it seems good enough to reply "not > > > expected to work in older LTS" if someone reported an issue. > > > > > > And in practice, no LTS release call the versioning macros, since a > > > LTS drops all compatibility. > > Just to be clear, we don't need fixing the macros in LTS: every time > we prepare a LTS rc0, we drop any kind of symbol compat. Agree, this is not LTS related > > > > > > > Signed-off-by: Stephen Hemminger <[email protected]> > > > > > > I would like to reproduce, but I can't build main with LTO. > > > What patches did you apply locally to avoid warnings on the hash library? > > > > > I use Debian testing and GCC 15 but shows up on older versions as well > > I get no warnings building main > > Building from scratch, I do avoid the warnings I hit yesterday. > > The fix looks correct, my problem is with the form. > Fixes: tags accuracy is important. > And I prefer we stick to "It is not broken, don't fix it". Could argue it is a GCC bug, and applying their desired workaround :-)
