On Mon, Jul 19, 2021 at 12:12:12PM +0300, Dmitry Kozlyuk wrote: > > > > mingw emutls just makes it compile allowing the variables to be exported, > > the binaries still won't work without loader support. or are you saying > > they do? > > > > > > > > No, it is not acceptable to add a generic feature supported by only one > > > compiler. (FWIW, I'm displeased even by mlx5 being tied to clang.) > > > Particularly, I don't understand how could MinGW and clang coexist > > > if they export different sets of symbols. Apps will need to know > > > if it's MingW- or clang-compiled DPDK? Sounds messy. > > > > it doesn't seem reasonable to reject the feature because mingw may or > > may not work. mingw binaries are not worse off if the feature can be > > enabled with clang. either way it is untested i am uncertain if it will > > work with mingw and have no time budget to test it. if it made mingw > > built binaries "worse" i would agree with you but the worst case > > scenario is that it works exactly as well as it does now. > > My mistake, I thought we exported __emutls.VARNAME symbols (in which case > MinGW DLLs would work without loader change). Since we don't, then you're > right, we have the same set of exported symbols and can enable this feature. > I'm willing to share the effort and help with MinGW.
sounds good to me, i'll work on a draft patch with you and when we have something acceptable we'll formally post it. thanks for helping out.
