02/06/2020 12:27, Neil Horman: > On Mon, Jun 01, 2020 at 09:46:18PM +0000, Omar Cardona wrote: > > >> Do we know if we have future plans of supporting dlls on windows in the > > >> future? > > - Hi Neil, yes this is of interest to us (Windows). > > - Specifically to aid in non-disruptive granular servicing/updating. > > - Our primary scenario Userspace VMSwitch is biased towards shared > > libraries for production servicing > > > Ok, do you have recommendations on how to provide backwards compatibility > between dpdk versions? From what I read the most direct solution would be > per-application dll bundling (which seems to me to defeat the purpose of > creating a dll, but if its the only solution, perhaps thats all we have to > work > with). Is there a better solution? > > If not, then I would suggest that, instead of disabling shared libraries on > Windows, as we do below, we allow it, and redefine > VERSION_SYMBOL[_EXPERIMENTAL] > to do nothing, and implement BIND_DEFAULT_SYMBOL to act like MAP_STATIC_SYMBOL > by aliasing the supplied symbol name to the provided export name. I think > msvc > supports aliasing, correct?
We don't use msvc, but clang and MinGW.
