[Git][ghc/ghc][master] Tree-wide cleanup of cygwin logic

Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC Commits: 2dafc65a by Cheng Shao at 2026-01-14T03:55:31-05:00 Tree-wide cleanup of cygwin logic GHC has not supported cygwin for quite a few years already, and will not resume support in the forseeable future. The only supported windows toolchain is clang64/clangarm64 of the msys2 project. This patch cleans up the unused cygwin logic in the tree. Co-authored-by: Codex - - - - - 21 changed files: - compiler/GHC/Driver/MakeFile.hs - compiler/GHC/SysTools/Terminal.hs - configure.ac - docs/users_guide/packages.rst - docs/users_guide/win32-dlls.rst - driver/ghci/ghci.c - driver/utils/cwrapper.c - driver/utils/isMinTTY.c - hadrian/bindist/cwrappers/cwrapper.c - hadrian/src/Settings/Program.hs - libraries/base/tests/IO/T12010/cbits/initWinSock.c - libraries/ghc-internal/cbits/consUtils.c - libraries/ghc-internal/configure.ac - libraries/ghc-internal/src/GHC/Internal/ConsoleHandler.hsc - libraries/ghc-internal/src/GHC/Internal/IO/Handle.hs - m4/ghc_select_file_extensions.m4 - testsuite/driver/runtests.py - testsuite/driver/testglobals.py - testsuite/driver/testlib.py - testsuite/mk/test.mk - testsuite/tests/rts/linker/rdynamic.hs Changes: ===================================== compiler/GHC/Driver/MakeFile.hs ===================================== @@ -331,7 +331,7 @@ writeDependency :: FilePath -> Handle -> [FilePath] -> FilePath -> IO () writeDependency root hdl targets dep = do let -- We need to avoid making deps on -- c:/foo/... - -- on cygwin as make gets confused by the : + -- on Windows as make gets confused by the : -- Making relative deps avoids some instances of this. dep' = makeRelative root dep forOutput = escapeSpaces . reslash Forwards . normalise ===================================== compiler/GHC/SysTools/Terminal.hs ===================================== @@ -41,7 +41,7 @@ stderrSupportsAnsiColors' = do case eMode of Left (_ :: IOError) -> Win32.isMinTTYHandle h -- Check if the we're in a MinTTY terminal - -- (e.g., Cygwin or MSYS2) + -- (e.g., MSYS2) Right mode | modeHasVTP mode -> pure True | otherwise -> enableVTP h mode ===================================== configure.ac ===================================== @@ -469,7 +469,7 @@ dnl -------------------------------------------------------------- dnl Note: we may not have objdump on OS X, and we only need it on dnl Windows (for DLL checks), OpenBSD, and AIX case $HostOS_CPP in - cygwin32|mingw32|openbsd|aix) + mingw32|openbsd|aix) AC_CHECK_TARGET_TOOL([OBJDUMP], [objdump]) ;; esac ===================================== docs/users_guide/packages.rst ===================================== @@ -1139,7 +1139,7 @@ read and write this syntax respectively. Here's an example of the Operating System Interface for Computing Environments - IEEE Std. 1003.1). . - The package is not supported under Windows (except under Cygwin). + The package is not supported under Windows. category: System author: exposed: True ===================================== docs/users_guide/win32-dlls.rst ===================================== @@ -33,23 +33,16 @@ We recommend running GHCi in a standard Windows console: select the use ``Start->Run->cmd`` to get a Windows console and invoke ``ghci`` from there (as long as it's in your ``PATH``). -If you run GHCi in a Cygwin or MSYS shell, then the Control-C behaviour -is adversely affected. In one of these environments you should use the +If you run GHCi in an MSYS shell, then the Control-C behaviour +is adversely affected. In this environment you should use the ``ghcii.sh`` script to start GHCi, otherwise when you hit Control-C you'll be returned to the shell prompt but the GHCi process will still be running. However, even using the ``ghcii.sh`` script, if you hit Control-C then the GHCi process will be killed immediately, rather than letting you interrupt a running program inside GHCi as it should. This -problem is caused by the fact that the Cygwin and MSYS shell -environments don't pass Control-C events to non-Cygwin child processes, -because in order to do that there needs to be a Windows console. - -There's an exception: you can use a Cygwin shell if the ``CYGWIN`` -environment variable does *not* contain ``tty``. In this mode, the -Cygwin shell behaves like a Windows console shell and console events are -propagated to child processes. Note that the ``CYGWIN`` environment -variable must be set *before* starting the Cygwin shell; changing it -afterwards has no effect on the shell. +problem is caused by the fact that the MSYS shell environment doesn't +pass Control-C events to non-console child processes, because in order +to do that there needs to be a Windows console. This problem doesn't just affect GHCi, it affects any GHC-compiled program that wants to catch console events. See the @@ -138,78 +131,6 @@ See the for more details. -.. _ghci-cygwin: - -Using GHC (and other GHC-compiled executables) with Cygwin ----------------------------------------------------------- - -Background -~~~~~~~~~~ - -The Cygwin tools aim to provide a Unix-style API on top of the windows -libraries, to facilitate ports of Unix software to windows. To this end, -they introduce a Unix-style directory hierarchy under some root -directory (typically ``/`` is ``C:\cygwin\``). Moreover, everything -built against the Cygwin API (including the Cygwin tools and programs -compiled with Cygwin's GHC) will see ``/`` as the root of their file system, -happily pretending to work in a typical unix environment, and finding -things like ``/bin`` and ``/usr/include`` without ever explicitly -bothering with their actual location on the windows system (probably -``C:\cygwin\bin`` and ``C:\cygwin\usr\include``). - -The problem -~~~~~~~~~~~ - -GHC, by default, no longer depends on cygwin, but is a native Windows -program. It is built using mingw, and it uses mingw's GHC while -compiling your Haskell sources (even if you call it from cygwin's bash), -but what matters here is that - just like any other normal windows -program - neither GHC nor the executables it produces are aware of -Cygwin's pretended unix hierarchy. GHC will happily accept either ``/`` or -``\`` as path separators, but it won't know where to find ``/home/joe/Main.hs`` -or ``/bin/bash`` or the like. This causes all kinds of fun when GHC is used from -within Cygwin's bash, or in make-sessions running under Cygwin. - -Things to do -~~~~~~~~~~~~ - -- Don't use absolute paths in ``make``, ``configure`` & co if there is any - chance that those might be passed to GHC (or to GHC-compiled - programs). Relative paths are fine because cygwin tools are happy - with them and GHC accepts ``/`` as path-separator. And relative paths - don't depend on where Cygwin's root directory is located, or on which - partition or network drive your source tree happens to reside, as - long as you ``cd`` there first. - -- If you have to use absolute paths (beware of the innocent-looking - ``ROOT=$(pwd)`` in makefile hierarchies or configure scripts), Cygwin - provides a tool called ``cygpath`` that can convert Cygwin's - Unix-style paths to their actual Windows-style counterparts. Many - Cygwin tools actually accept absolute Windows-style paths (remember, - though, that you either need to escape ``\`` or convert ``\`` to ``/``), - so you should be fine just using those everywhere. If you need to use - tools that do some kind of path-mangling that depends on unix-style - paths (one fun example is trying to interpret ``:`` as a separator in - path lists), you can still try to convert paths using ``cygpath`` - just before they are passed to GHC and friends. - -- If you don't have ``cygpath``, you probably don't have cygwin and - hence no problems with it... unless you want to write one build - process for several platforms. Again, relative paths are your friend, - but if you have to use absolute paths, and don't want to use - different tools on different platforms, you can simply write a short - Haskell program to print the current directory (thanks to George - Russell for this idea): compiled with GHC, this will give you the - view of the file system that GHC depends on (which will differ - depending on whether GHC is compiled with cygwin's gcc or mingw's gcc - or on a real Unix system..) - that little program can also deal with - escaping ``\`` in paths. Apart from the banner and the startup time, - something like this would also do: - - .. code-block:: none - - $ echo "Directory.getCurrentDirectory >>= putStrLn . init . tail . show " | ghci - .. _win32-dlls: Building and using Win32 DLLs ===================================== driver/ghci/ghci.c ===================================== @@ -27,7 +27,7 @@ int main(int argc, char** argv) { char *preArgv[1]; if (isMinTTY()) { - printf("WARNING: GHCi invoked via 'ghci.exe' in MinTTY consoles (e.g., Cygwin or MSYS)\n"); + printf("WARNING: GHCi invoked via 'ghci.exe' in MinTTY consoles (e.g., MSYS2)\n"); printf(" doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead\n"); fflush(stdout); } ===================================== driver/utils/cwrapper.c ===================================== @@ -116,7 +116,7 @@ __attribute__((noreturn)) int run (char *exePath, didn't do the trick either. Irrespective of this issue, using CreateProcess() is preferable, - as it makes this wrapper work on both mingw and cygwin. + as it makes this wrapper work reliably on Windows. */ #if 0 fprintf(stderr, "Invoking %s\n", new_cmdline); fflush(stderr); ===================================== driver/utils/isMinTTY.c ===================================== @@ -28,6 +28,6 @@ bool isMinTTY() { PWSTR fn = pfni->FileName; fn[pfni->FileNameLength] = L'\0'; - return ((wcsstr(fn, L"\\cygwin-") || wcsstr(fn, L"\\msys-")) && - wcsstr(fn, L"-pty") && wcsstr(fn, L"-master")); + return (wcsstr(fn, L"\\msys-") && + wcsstr(fn, L"-pty") && wcsstr(fn, L"-master")); } ===================================== hadrian/bindist/cwrappers/cwrapper.c ===================================== @@ -116,7 +116,7 @@ __attribute__((noreturn)) int run (char *exePath, didn't do the trick either. Irrespective of this issue, using CreateProcess() is preferable, - as it makes this wrapper work on both mingw and cygwin. + as it makes this wrapper work reliably on Windows. */ #if 0 fprintf(stderr, "Invoking %s\n", new_cmdline); fflush(stderr); ===================================== hadrian/src/Settings/Program.hs ===================================== @@ -40,7 +40,7 @@ programContext stage pkg = do ghcWithInterpreter :: Stage -> Action Bool ghcWithInterpreter stage = do is_cross <- flag CrossCompiling - goodOs <- anyTargetOs [ OSMinGW32, OSLinux, OSSolaris2 -- TODO "cygwin32"?, + goodOs <- anyTargetOs [ OSMinGW32, OSLinux, OSSolaris2 , OSFreeBSD, OSDragonFly, OSNetBSD, OSOpenBSD , OSDarwin, OSKFreeBSD , OSWasi ] ===================================== libraries/base/tests/IO/T12010/cbits/initWinSock.c ===================================== @@ -1,7 +1,7 @@ #include "HsBase.h" #include "HsFFI.h" -#if defined(HAVE_WINSOCK_H) && !defined(__CYGWIN__) +#if defined(HAVE_WINSOCK_H) static int winsock_inited = 0; ===================================== libraries/ghc-internal/cbits/consUtils.c ===================================== @@ -3,17 +3,13 @@ * * Win32 Console API support */ -#if defined(_WIN32) || defined(__CYGWIN__) +#if defined(_WIN32) /* to the end */ #include "consUtils.h" #include #include -#if defined(__CYGWIN__) -#define _get_osfhandle get_osfhandle -#endif - int is_console__(int fd) { DWORD st; HANDLE h; ===================================== libraries/ghc-internal/configure.ac ===================================== @@ -12,7 +12,7 @@ AC_USE_SYSTEM_EXTENSIONS AC_MSG_CHECKING(for WINDOWS platform) case $host_alias in - *mingw32*|*mingw64*|*cygwin*|*msys*|*windows*) + *mingw32*|*mingw64*|*msys*|*windows*) WINDOWS=YES;; *) WINDOWS=NO;; ===================================== libraries/ghc-internal/src/GHC/Internal/ConsoleHandler.hsc ===================================== @@ -67,9 +67,7 @@ data Handler -- running in a Windows console. Certain environments that look like consoles -- do not support console events, these include: -- --- * Cygwin shells with @CYGWIN=tty@ set (if you don't set @CYGWIN=tty@, --- then a Cygwin shell behaves like a Windows console). --- * Cygwin xterm and rxvt windows +-- * MSYS MinTTY shells -- * MSYS rxvt windows -- -- In order for your application to receive console events, avoid running ===================================== libraries/ghc-internal/src/GHC/Internal/IO/Handle.hs ===================================== @@ -575,7 +575,7 @@ hGetEcho handle = do -- | Is the handle connected to a terminal? -- -- On Windows the result of 'hIsTerminalDevide' might be misleading, --- because non-native terminals, such as MinTTY used in MSYS and Cygwin environments, +-- because non-native terminals, such as MinTTY used in MSYS environments, -- are implemented via redirection. -- Use @System.Win32.Types.withHandleToHANDLE System.Win32.MinTTY.isMinTTYHandle@ -- to recognise it. Also consider @ansi-terminal@ package for crossplatform terminal ===================================== m4/ghc_select_file_extensions.m4 ===================================== @@ -3,11 +3,6 @@ AC_DEFUN([GHC_SELECT_FILE_EXTENSIONS], $2='' $3='.so' case $1 in - *-unknown-cygwin32) - AC_MSG_WARN([GHC does not support the Cygwin target at the moment]) - AC_MSG_WARN([I'm assuming you wanted to build for x86_64-w64-mingw32]) - exit 1 - ;; # examples: x86_64-w64-mingw32 *-mingw32) windows=YES ===================================== testsuite/driver/runtests.py ===================================== @@ -21,8 +21,8 @@ from pathlib import Path # We don't actually need subprocess in runtests.py, but: # * We do need it in testlibs.py # * We can't import testlibs.py until after we have imported ctypes -# * If we import ctypes before subprocess on cygwin, then sys.exit(0) -# says "Aborted" and we fail with exit code 134. +# * If we import ctypes before subprocess on some Windows environments, +# then sys.exit(0) says "Aborted" and we fail with exit code 134. # So we import it here first, so that the testsuite doesn't appear to fail. import subprocess @@ -182,16 +182,13 @@ elif args.ignore_perf_failures == 'decreases': if args.test_env: config.test_env = args.test_env -config.cygwin = False config.msys = False if windows: h = os.popen('uname -s', 'r') v = h.read() h.close() - if v.startswith("CYGWIN"): - config.cygwin = True - elif v.startswith("MINGW") or v.startswith("MSYS"): + if v.startswith("MINGW") or v.startswith("MSYS"): # msys gives "MINGW32" # msys2 gives "MINGW_NT-6.2" or "MSYS_NT-6.3" config.msys = True @@ -274,12 +271,6 @@ def format_path(path): # letter representation. Otherwise it thinks we're adding two env # variables E and /Foo when we add E:/Foo. path = re.sub('([a-zA-Z]):', '/\\1', path) - if config.cygwin: - # On cygwin we can't put "c:\foo" in $PATH, as : is a - # field separator. So convert to /cygdrive/c/foo instead. - # Other pythons use ; as the separator, so no problem. - path = re.sub('([a-zA-Z]):', '/cygdrive/\\1', path) - path = re.sub('\\\\', '/', path) return path # On Windows we need to set $PATH to include the paths to all the DLLs ===================================== testsuite/driver/testglobals.py ===================================== @@ -80,7 +80,6 @@ class TestConfig: self.os = '' self.arch = '' self.msys = False - self.cygwin = False # What is the wordsize (in bits) of this platform? self.wordsize = '' ===================================== testsuite/driver/testlib.py ===================================== @@ -1023,9 +1023,6 @@ def wordsize( ws: int ) -> bool: def msys( ) -> bool: return config.msys -def cygwin( ) -> bool: - return config.cygwin - def js_arch() -> bool: return arch("javascript"); ===================================== testsuite/mk/test.mk ===================================== @@ -65,13 +65,13 @@ TEST_HC_OPTS_INTERACTIVE = $(TEST_HC_OPTS) --interactive -v0 -ignore-dot-ghci -f RUNTEST_OPTS = -ifeq "$(filter $(TargetOS_CPP), cygwin32 mingw32)" "" +ifeq "$(filter $(TargetOS_CPP), mingw32)" "" exeext = else exeext = .exe endif -ifneq "$(filter $(TargetOS_CPP),cygwin32 mingw32)" "" +ifneq "$(filter $(TargetOS_CPP),mingw32)" "" dllext = .dll else ifeq "$(TargetOS_CPP)" "darwin" dllext = .dylib ===================================== testsuite/tests/rts/linker/rdynamic.hs ===================================== @@ -39,10 +39,8 @@ loadFunction mpkg m valsym = do where prefixUnderscore = case (os, arch) of ("mingw32", "x86_64") -> "" - ("cygwin" , "x86_64") -> "" ("mingw32", _ ) -> "_" ("darwin" , _ ) -> "_" - ("cygwin" , _ ) -> "_" _ -> "" foreign import ccall safe "lookupSymbol" c_lookupSymbol :: CString -> IO (Ptr a) View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/2dafc65a48f7d0d959030b801ee45fb4... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/2dafc65a48f7d0d959030b801ee45fb4... You're receiving this email because of your account on gitlab.haskell.org.