On Tuesday 18 March 2025 11:49:58 Martin Storsjö wrote: > 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.
Sure, for now there is no need for it. > > 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. Yes, in all other .def files were long double functions already disabled. This is the last remaining one. > But it > should probably be updated to use F_LD64() instead of F_ARM_ANY(), like the > other patch currently in review. > > // Martin I'm not sure if the F_LD64 is the best option. And if changing from F_ARM_ANY to F_LD64 is needed then it should be done globally for all files, not just for this one. So I would propose to put this change out of the scope. _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
