On Sun, 12 Jan 2025, Jacek Caban wrote:
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.
In general, I agree with this reasoning.
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?
If someone is actively trying to build/use libc++ with these CRTs, I guess
it could be worthwhile to add them... The locale functionality wouldn't
work, but this is the same situation we have right now on Windows 7
anyway. (And even on OSes where the locale functions exist in msvcrt.dll,
it's quite nonfunctional anyway, iirc it only supports setting the "C"
locale.)
Furthermore, regarding custom CRTs with libc++; officially, libc++
requires Windows 7. It is possible to make it work somewhat on older OSes,
by using winpthreads instead of the win32 thread/synchronization APIs, but
it's not guaranteed that there won't be use of other APIs that require
Windows 7 anyway.
So regarding this patch, I don't have a very strong opinion either way,
but let's say that I'm not planning on building libc++ for older CRTs
myself at least.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
