On 15.03.2025 17:36, Martin Storsjö wrote:
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.
FWIW, ignoring them seems reasonable to me.
Jacek
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public