On 10.01.2025 21:39, Pali Rohár wrote:
On Thursday 09 January 2025 15:58:11 Jacek Caban wrote:
On 8.01.2025 21:40, Pali Rohár wrote:
With the previous change, these 3 files can be compiled and included also
for non-msvcrt-os import library.
---
mingw-w64-crt/Makefile.am | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 97ab3b4742cc..7f8841a85f3f 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -772,6 +772,9 @@ src_pre_msvcr80=\
misc/__sys_errlist.c \
misc/__sys_nerr.c \
misc/_configthreadlocale.c \
+ misc/_create_locale.c \
+ misc/_free_locale.c \
+ misc/_get_current_locale.c \
What's the point of that? Those "emu" functions are useless, so a link
failure seems better than silently compiled broken code. A proper error also
gives build system a chance to adopt to the missing functionality.
Jacek
The point is to provide those symbols also for other libraries.
For msvcrt.dll builds we provide that dummy emu functions, so why not to
have them also for other builds?
For me it makes sense to provide these functions for all builds or none
builds. Just for one build it looks strange.
I don't fully agree with that logic. The underlying CRTs differ, and
while some differences can be patched, others cannot. Feature parity
isn’t a realistic goal; it wouldn’t be achievable anyway.
msvcrt-os also exports different symbols depending on its version. We
have mechanisms to allow using those symbols without breaking
compatibility. Symbols like these are part of that system. Other
versions, such as msvcr70, have a fixed set of exported symbols, so they
don’t need this.
More generally, when we don’t provide a functionality, it’s better to
fail at the linking stage. This gives developers immediate feedback on
what needs to be changed. Providing a broken implementation instead
forces debugging and possibly learning about mingw-w64 details to figure
it out. That’s why I believe the default should be to avoid providing
incomplete fallbacks unless there’s a compelling reason.
Looking at the git log, I found these locale symbols were added to
satisfy libc++ with msvcrt-os. Since libc++ is part of the toolchain, it
often pulls symbols even when they’re not actually needed. So, I guess
libc++ could be a reason to extend this to other CRTs, but I’m not sure.
Is it even feasible to use it like that? Wouldn’t it fail due to other
missing functionality anyway?
Thanks,
Jacek
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
