[dpdk-dev] ABI versioning in Windows

[Thomas Monjalon]

27/05/2020 23:27, Thomas Monjalon:
> 27/05/2020 22:35, Neil Horman:
> > On Wed, May 27, 2020 at 02:50:07PM +0200, Thomas Monjalon wrote:
> > > +Cc more people
> > > 
> > > 27/05/2020 12:41, Fady Bader:
> > > > What should we do with the ABI versioning in Windows ?
> > > 
> > > I think there are 2 questions here:
> > > 
> > > 1/ Do we want to maintain ABI compatibility on Windows like we do for Linux and FreeBSD?
> > > The decision must be clearly documented.
> > > 
> > My first notion, without any greater thought is "why wouldn't we".  ABI
> > stability is OS agnostic.  If a symbol is considered stable, theres no reason
> > that I can think of that it wouldn't be stable for each OS.
> 
> Technical reason + no need so far.
> 
> 
> > > 2/ How do we implement the macros in rte_function_versioning.h for Windows?
> > > Something needs to be done, otherwise we cannot compile libraries having some function versioning.
> > > 
> > Can you elaborate on what exactly the issue is here?  I presume by your comment
> > above that visual studio either doesn't support symbol level versioning or
> > doesn't support versioning at all?
> 
> I don't know how to implement the macros in rte_function_versioning.h for Windows.
> 
> 
> > If thats the case, and there is a commitment to make dpdk buildable on windows,
> > I suppose the only choice is to make a ifdef WINDOWS section of the
> > rte_function_versioning.h file, and effectively turn all the macros into no-ops.
> 
> Yes that's the idea.
> But we still need to implement either BIND_DEFAULT_SYMBOL or MAP_STATIC_SYMBOL
> to alias the latest function version to the actual function symbol.

I've just found a tip in https://sourceware.org/binutils/docs/ld/WIN32.html
It suggests to create a weak symbol:
void foo() __attribute__((weak, alias ("foo_latestversion")));


> > The BIND_DEFAULT_SYMBOL macro looks like it could still work, as MSVC has an
> > alias linker command thats implementable via __pragma, but thats probably all we
> > can do, unless there is some more robust versioning support that I can't find.
> 
> What is this pragma?
> 
> 
> > Note we will also likely need to agument the makefiles/meson files so that the
> > link stage doesn't pass the version script to the linker
> 
> Why not using the version script for exported symbols?
> We are already doing it (.def file generated from .map).