Hi, Explicitly pulling in Steve Lhomme to disuss this matter:
On Tue, 3 Oct 2023, Mark Harmstone wrote:
diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-io-l1-1-1.def b/mingw-w64-crt/lib-common/api-ms-win-core-io-l1-1-1.def index 9401e3d53..c13c4928b 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-core-io-l1-1-1.def +++ b/mingw-w64-crt/lib-common/api-ms-win-core-io-l1-1-1.def @@ -4,6 +4,7 @@ EXPORTS CancelIo CancelIoEx +CancelSynchronousIo CreateIoCompletionPort DeviceIoControl GetOverlappedResult
So, the main issue is that both the mincore and windowsapp umbrella libraries link against api-ms-win-core-io-l1-1-1.dll. When linking with windowsapp, there's no CancelSynchronousIo symbol anywhere to link against, but when linking against mincore, this symbol does exist and is provided in that DLL.
This means that if we apply this patch, our windowsapp import library also will expose CancelSynchronousIo even if the MS version doesn't.
Steve, do you feel that this is ok? Or should we separate all the api-ms-win-* import libraries, into one version for mincore and one for windowsapp, to keep things strict and correct?
I guess there's a potential risk, if there's e.g. a configure script, that tests whether the symbol can be linked, and uses it if available - such cases are broken if our umbrella import libraries export too many symbols.
I guess there's also a risk, if e.g. windowsapp would be providing this symbol in another DLL; then our umbrella library would expose it in two forwarder DLLs, and it'd be up to the linker which one it ends up picking.
What do you say Mark and Steve, is this ok with both of you? If it is, most of the rest of this patchset should be fine as well. If not, we'll need to spend a lot more effort on this...
// Martin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
