On Sun, 16 Mar 2025, Pali Rohár wrote:
On Saturday 15 March 2025 21:17:07 Jacek Caban wrote:
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?
_o_ prefixed symbols use UCRT global state, mostly used by DLL libs.
non-prefixes symbols use application specific global state which does
not affect global state of DLL libraries.
It is documented on MS UCRT webpage:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/global-state
If I understand correctly then system-wide DLL library should use _o_
prefixed symbols. To make it easier for using, msvc/ucrt provides import
library named "ucrt.osmode.lib" which for each import function FUNC call
exported symbol _o_FUNC. So source code DLL library can use normal C
named functions without _o_ prefix.
Right, thanks for the info!
mingw-w64 does not provide libucrt.osmode.a yet, but it could be
extended and implemented in future (if there would be need for it).
Ok. I guess that'd be doable, but I would also prefer to not do it until
we have an actual concrete need for it, not just for completeness.
gcc has already -mcrtdll= argument and it can already process
-mcrtdll=ucrt.osmode (as it process any -mcrtdll=ucrt*"), so it is just
waiting until mingw-w64 gain such support.
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.
AFAIK, no mingw-w64 code calls long double _o_ prefixed symbol. And
applications should not call long double those symbols as ABI of those
symbols expects regular double (not long double).
If there is a needed for supporting 80-bit long double functions with
_o_ prefix then it would be needed to emulate them in mingw-w64 as UCRT
has support only for 64-bit double functions.
Ok, fair enough. I guess this patch could be reasonable to apply then,
also for making things consistent between api-ms-win-crt-* and ucrtbase.
But it should probably be updated to use F_LD64() instead of
F_ARM_ANY(), like the other patch currently in review.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
