[Git][ghc/ghc][master] 2 commits: Restore mingwex dependency on Windows
Marge Bot (@marge-bot)
gitlab at gitlab.haskell.org
Fri Jun 9 11:57:19 UTC 2023
Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC
Commits:
2b1a4abe by Ryan Scott at 2023-06-09T07:56:58-04:00
Restore mingwex dependency on Windows
This partially reverts some of the changes in !9475 to make `base` and
`ghc-prim` depend on the `mingwex` library on Windows. It also restores the
RTS's stubs for `mingwex`-specific symbols such as `_lock_file`.
This is done because the C runtime provides `libmingwex` nowadays, and
moreoever, not linking against `mingwex` requires downstream users to link
against it explicitly in difficult-to-predict circumstances. Better to always
link against `mingwex` and prevent users from having to do the guesswork
themselves.
See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10360#note_495873 for
the discussion that led to this.
- - - - -
28954758 by Ryan Scott at 2023-06-09T07:56:58-04:00
RtsSymbols.c: Remove mingwex symbol stubs
As of !9475, the RTS now links against `ucrt` instead of `msvcrt` on Windows,
which means that the RTS no longer needs to declare stubs for the `__mingw_*`
family of symbols. Let's remove these stubs to avoid confusion.
Fixes #23309.
- - - - -
4 changed files:
- configure.ac
- libraries/base/base.cabal
- libraries/ghc-prim/ghc-prim.cabal
- rts/RtsSymbols.c
Changes:
=====================================
configure.ac
=====================================
@@ -917,6 +917,9 @@ AC_CHECK_DECLS([program_invocation_short_name], , ,
[#define _GNU_SOURCE 1
#include <errno.h>])
+dnl ** check for mingwex library
+AC_CHECK_LIB([mingwex],[closedir])
+
dnl ** check for math library
dnl Keep that check as early as possible.
dnl as we need to know whether we need libm
=====================================
libraries/base/base.cabal
=====================================
@@ -398,6 +398,7 @@ Library
if os(windows)
-- Windows requires some extra libraries for linking because the RTS
-- is no longer re-exporting them.
+ -- mingwex: provides GNU POSIX extensions that aren't provided by ucrt.
-- mingw32: Unfortunately required because of a resource leak between
-- mingwex and mingw32. the __math_err symbol is defined in
-- mingw32 which is required by mingwex.
@@ -410,7 +411,7 @@ Library
-- advapi32: provides advanced kernel functions
extra-libraries:
wsock32, user32, shell32, mingw32, kernel32, advapi32,
- ws2_32, shlwapi, ole32, rpcrt4, ntdll
+ mingwex, ws2_32, shlwapi, ole32, rpcrt4, ntdll
-- Minimum supported Windows version.
-- These numbers can be found at:
-- https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745(v=vs.85).aspx
=====================================
libraries/ghc-prim/ghc-prim.cabal
=====================================
@@ -68,12 +68,13 @@ Library
-- is no longer re-exporting them (see #11223)
-- ucrt: standard C library. The RTS will automatically include this,
-- but is added for completeness.
+ -- mingwex: provides GNU POSIX extensions that aren't provided by ucrt.
-- mingw32: Unfortunately required because of a resource leak between
-- mingwex and mingw32. the __math_err symbol is defined in
-- mingw32 which is required by mingwex.
-- user32: provides access to apis to modify user components (UI etc)
-- on Windows. Required because of mingw32.
- extra-libraries: user32, mingw32, ucrt
+ extra-libraries: user32, mingw32, mingwex, ucrt
if os(linux)
-- we need libm, but for musl and other's we might need libc, as libm
=====================================
rts/RtsSymbols.c
=====================================
@@ -113,6 +113,26 @@ extern char **environ;
* by the RtsSymbols entry. To avoid this we introduce a horrible special case
* in `ghciInsertSymbolTable`, ensure that `atexit` is never overridden.
*/
+/*
+ * Note [Symbols for MinGW's printf]
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ * The printf offered by Microsoft's libc implementation, msvcrt, is quite
+ * incomplete, lacking support for even %ull. Consequently mingw-w64 offers its
+ * own implementation which we enable. However, to be thread-safe the
+ * implementation uses _lock_file. This would be fine except msvcrt.dll doesn't
+ * export _lock_file, only numbered versions do (e.g. msvcrt90.dll).
+ *
+ * To work around this mingw-w64 packages a static archive of msvcrt which
+ * includes their own implementation of _lock_file. However, this means that
+ * the archive contains things which the dynamic library does not; consequently
+ * we need to ensure that the runtime linker provides this symbol.
+ *
+ * It's all just so terrible.
+ *
+ * See also:
+ * https://sourceforge.net/p/mingw-w64/wiki2/gnu%20printf/
+ * https://sourceforge.net/p/mingw-w64/discussion/723797/thread/55520785/
+ */
/* Note [_iob_func symbol]
* ~~~~~~~~~~~~~~~~~~~~~~~
* Microsoft in VS2013 to VS2015 transition made a backwards incompatible change
@@ -150,17 +170,17 @@ extern char **environ;
SymI_NeedsProto(__mingw_module_is_dll) \
RTS_WIN32_ONLY(SymI_NeedsProto(___chkstk_ms)) \
RTS_WIN64_ONLY(SymI_NeedsProto(___chkstk_ms)) \
- SymI_HasProto(__mingw_vsnwprintf) \
- /* ^^ Need to figure out why this is needed. */ \
+ RTS_WIN64_ONLY(SymI_HasProto(__stdio_common_vswprintf_s)) \
+ RTS_WIN64_ONLY(SymI_HasProto(__stdio_common_vswprintf)) \
+ RTS_WIN64_ONLY(SymI_HasProto(_errno)) \
+ /* see Note [Symbols for MinGW's printf] */ \
+ SymI_HasProto(_lock_file) \
+ SymI_HasProto(_unlock_file) \
/* See Note [_iob_func symbol] */ \
RTS_WIN64_ONLY(SymI_HasProto_redirect( \
__imp___acrt_iob_func, __rts_iob_func, STRENGTH_WEAK, SYM_TYPE_INDIRECT_DATA)) \
RTS_WIN32_ONLY(SymI_HasProto_redirect( \
- __imp____acrt_iob_func, __rts_iob_func, STRENGTH_WEAK, SYM_TYPE_INDIRECT_DATA)) \
- SymI_HasProto(__mingw_vsnwprintf) \
- /* ^^ Need to figure out why this is needed. */ \
- SymI_HasProto(__mingw_vfprintf) \
- /* ^^ Need to figure out why this is needed. */
+ __imp____acrt_iob_func, __rts_iob_func, STRENGTH_WEAK, SYM_TYPE_INDIRECT_DATA))
#else
#define RTS_MINGW_ONLY_SYMBOLS /**/
#endif
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/567b32e12cbae07bee78d66252e83a0ad08419be...289547580b6f2808ee123f106c3118b716486d5b
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/567b32e12cbae07bee78d66252e83a0ad08419be...289547580b6f2808ee123f106c3118b716486d5b
You're receiving this email because of your account on gitlab.haskell.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20230609/a9088b7e/attachment-0001.html>
More information about the ghc-commits
mailing list