On Thu, 7 Mar 2024 11:32:36 +0100 David Marchand <david.march...@redhat.com> wrote:
> On Tue, Mar 5, 2024 at 6:53 PM Tyler Retzlaff > <roret...@linux.microsoft.com> wrote: > > > > On Tue, Mar 05, 2024 at 11:14:45AM +0100, David Marchand wrote: > > > On Mon, Mar 4, 2024 at 7:45 PM Stephen Hemminger > > > <step...@networkplumber.org> wrote: > > > > > > > > This reverts commit 07d836e5929d18ad6640ebae90dd2f81a2cafb71. > > > > > > > > Tyler found build issues with MSVC and the thash gfni stubs. > > > > The problem would be link errors from missing symbols. > > > > > > Trying to understand this link error. > > > Does it come from the fact that rte_thash_gfni/rte_thash_gfni_bulk > > > declarations are hidden under RTE_THASH_GFNI_DEFINED in > > > rte_thash_gfni.h? > > > > > > If so, why not always expose those two symbols unconditionnally and > > > link with the stub only when ! RTE_THASH_GFNI_DEFINED. > > > > So I don't have a lot of background of this lib. > > > > I think we understand that we can't conditionally expose symbols. That's > > what windows was picking up because it seems none of our CI's ever end > > up with RTE_THASH_GFNI_DEFINED but my local test system did and failed. > > (my experiments showed that Linux would complain too if it was defined) > > I can't reproduce a problem when I build (gcc/clang) for a target that > has GFNI/AVX512F. > binutils ld seems to just ignore unknown symbols in the map. Turns out MSVC linker does not. That is why Tyler complained.
