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. 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). 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. > > 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 > We already ignore all long double named symbols from all CRT .dll libraries, so we should also these _o_ long double named symbols. They are ABI incompatible with gcc/mingw-w64. _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
