On Thu, 8 Jun 2023, Steve Lhomme wrote:
According to the WACK.
---
.../lib-common/api-ms-win-crt-filesystem-l1-1-0.def | 5 +++++
mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def | 1 +
mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def | 1 +
3 files changed, 7 insertions(+)
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def
b/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def
index 45ae728ba..f5ccd2161 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def
@@ -27,6 +27,9 @@ _fstat32i64
_fstat64
_fstat64i32
_fullpath
+_getcwd
+getcwd == _getcwd
+_getdcwd
This is wrong.
When looking through the XML listings of current WACK, yes, it does list
_getcwd and _getdcwd as allowed for api-ms-win-crt-filesystem-l1-1-0.dll.
But they're also allowed for api-ms-win-crt-stdio-l1-1-0.dll, where we
currently provide these symbols.
If we provide them in both api-ms-win-crt-filesystem-l1-1-0 and
api-ms-win-crt-stdio-l1-1-0, it's somewhat unspecified which one we end up
linking against - it's pretty much up to the linker.
When looking at the redistributable api-ms-win-crt*.dlls from the
redistributable UCRT, api-ms-win-crt-filesystem-l1-1-0.dll does not
contain these symbols; neither in the original releases of UCRT from 2015,
nor in the current releases from the latest WinSDK. So if we link against
this function from api-ms-win-crt-filesystem-l1-1-0.dll, a binary won't
load with the redistributable version of UCRT.
As these DLLs don't exist physically on disk in actual Windows 10, I can't
inspect that, but I did try to link a test executable with this, which
imports _getcwd from api-ms-win-crt-filesystem-l1-1-0.dll and it actually
does seem to run successfully on Windows 10, so it is somewhat there
still.
But if looking at ucrt.lib in the WinSDK, it only links _getcwd against
api-ms-win-crt-stdio-l1-1-0.dll (otherwise it would also break deployment
against the redistributable UCRT).
So as this is functions that already is provided elsewhere, we shouldn't
provide them in another location with lesser availability. (If it was the
question of a function which wasn't available at all previously, it would
be a different thing.)
@@ -62,6 +65,8 @@ _wfindnext32i64
_wfindnext64
_wfindnext64i32
_wfullpath
+_wgetcwd
+_wgetdcwd
Same thing as _getcwd, already provided in
api-ms-win-crt-environment-l1-1-0, also allowed by WACK there.
_wmakepath
_wmakepath_s
_wmkdir
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def
b/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def
index fd793fe82..8a00f801c 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def
@@ -25,6 +25,7 @@ _query_new_handler
_query_new_mode
_realloc_base
_recalloc
+_resetstkoflw
Already in api-ms-win-crt-runtime-l1-1-0
_set_new_mode
calloc
free
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def
b/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def
index d59859ced..e1020e2ef 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def
@@ -179,6 +179,7 @@ getwc
getwchar
putc
putchar
+putenv
Now this one is actually slightly different from the others.
The old redistributable UCRT DLLs don't provide any direct "putenv"
symbol, but api-ms-win-crt-environment-l1-1-0.dll does provide "_putenv".
Our api-ms-win-crt-environment-l1-1-0.def provides putenv as an alias for
_putenv. So here it's still the same; when we already provide the symbol
in a more reliable/accessible/compatible way (which also is accepted by
the WACK), we shouldn't start linking it this way.
TL;DR, I don't think any part of this patch should be applied.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
