So apologies for resurrecting an old thread - I did want to chime on this. From a past life as a Windows Programmer, I would say that shared libraries model on Windows is not as strong as on Linux/Unix. Libraries on Windows are typically packaged and distributed along with the applications, not usually at a system level as in Linux/Unix.
That said - I strongly agree with Omar - that does not mean that stable ABI's should not be goal on Windows. This does not diminish the value of enabling Windows applications to seamless upgrade their DPDK, at an application level. So I don't have a problem with disabling function-level versioning as an interim measure, until we figure out the best mechanism. What I would suggest is that we aim to get this sort for the v22 ABI in the 21.11 release. And that we clearly indicate in v21 in 20.11 that Windows is not yet covered in the ABI policy. Make sense? Ray K On 02/06/2020 11:40, Thomas Monjalon wrote: > 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. > >
