On Wed, Dec 04, 2024 at 08:56:35AM +0100, David Marchand wrote: > Hello Andre, > > On Wed, Dec 4, 2024 at 3:20 AM Andre Muezerie > <andre...@linux.microsoft.com> wrote: > > > > MSVC issues the warning below: > > > > ../lib/lpm/rte_lpm.c(297): warning C4013 > > '__atomic_store' undefined; assuming extern returning int > > ../lib/lpm/rte_lpm.c(298): error C2065: > > '__ATOMIC_RELAXED': undeclared identifier > > > > The fix is to use standard atomic_store_explicit() instead of > > gcc specific __atomic_store(). > > atomic_store_explicit() was already being used in other parts > > of DPDK and is compatible > > with many compilers, including MSVC. > > > > Signed-off-by: Andre Muezerie <andre...@linux.microsoft.com> > > With this change, is there anything remaining that blocks this library > compilation with MSVC? > If not, please update meson.build so that CI can test lpm compilation > with MSVC on this patch (and that will detect regressions once > merged). > > > -- > David Marchand
Hi David, I'm eager to enable lpm to be compiled with MSVC. Even though this was the last issue I observed for this lib on my machine, lpm depends on hash, which depends on net, which depends on mbuf and mbuf is not enabled for MSVC yet. I have several fixes affecting these pending review and would prefer to not depend on lpm's dependencies for the system to start compiling this code in case some critical fix gets completed later. I have not analyzed all sequences in which patches can be completed, and it's quite possible that some sequences would result in MSVC compilation failures if the libs were enabled in meson.build. However, this code would still get compiled on Linux as usual, and hopefully we can enable all these libs once the patches get completed. I am aware that regressions can happen before that point. We will address them if that happens. It is tricky to handle so many paches/dependencies. Let me know if there's something that can be improved. Andre
