On Mon, 10 Mar 2025, Pali Rohár wrote:
---
.../api-ms-win-crt-private-l1-1-0.def.in | 64 +++++++++----------
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-private-l1-1-0.def.in
b/mingw-w64-crt/lib-common/api-ms-win-crt-private-l1-1-0.def.in
index 3bcce9953157..90d530d6a686 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-private-l1-1-0.def.in
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-private-l1-1-0.def.in
@@ -700,7 +700,7 @@ _o__strtof_l
_o__strtoi64
_o__strtoi64_l
_o__strtol_l
-_o__strtold_l
+F_ARM_ANY(_o__strtold_l) ; Can't use long double functions from the CRT on x86
_o__strtoll_l
_o__strtoui64
_o__strtoui64_l
I'm a little undecided about this one.
So far, I don't think we've done much about these extra prefixed functions
in the def files, other than keeping track of which symbols exist in which
DLL. In which way do the _o_ prefixed symbols differ from the unprefixed
ones?
As for avoiding long doubles, there would be more of a case for that, if
this was a function that we'd have a declaration for and try to reference
somewhere. But nothing references these functions anywhere and nothing
declares them; we don't have any implementation of our own that we'd like
to link instead of these ones.
So - so far, I have at least personally just decided to ignore this whole
range of symbols.
But I see that we do have the same kind of markings for these _o_ prefixed
functions in ucrtbase-common.def.in, since
ca1326bbcd150b0a6d008ed5bd0013f17ec76c45...
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
