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

Reply via email to