disabling the CI on Cygwin

The newest Cygwin release (3.5.5) has three major regressions: - bash hangs [1] - access() behaviour changed [2] - raise() produces random behaviour [3] The first one has the potential to hang the CI for 6 hours; the second and third one causes unit test failures in the CIs of gnulib, gettex

access, euidaccess tests: Avoid test failure in Cygwin 3.5.5

The GitHub CI reports these test failures: FAIL: test-access = ../../gltests/test-access.h:101: assertion 'func (BASE "f2", X_OK) == -1' failed ../../gltests/test-access.h:102: assertion 'errno == EACCES' failed FAIL test-access.exe (exit status: 1) FAIL: test-euidaccess

Re: supporting in the UTF-8 environment on native Windows

Lasse Collin wrote: > (1) > In 9f7ff4f423cd ("localename-unsafe: Support the UTF-8 environment on > native Windows."), the N(name) macro is used with strings that include > @modifier. For example, N("az_AZ@cyrillic") can expand to > "az...@cyrillic.utf-8". Similarly in 00211fc69c92 ("setlocale: Sup

[PATCH] stdlib: support including stdlib.h from config.h

Emacs includes in some situations, causing problems on macOS as described by Eli Zaretskii in: https://lists.gnu.org/r/emacs-devel/2024-12/msg00923.html Although this usage is not recommended, it is easier to support it for POSIX-required headers, than to fix Emacs. * doc/extern-inline.texi (exte

Re: supporting in the UTF-8 environment on native Windows

On 2024-12-23 Bruno Haible wrote: > Lasse Collin reported in > > that the setlocale() override from GNU libintl does not support the > UTF-8 environment of native Windows correctly. That setlocale() > override is based on the se

doc: Document mingw with MSVCRT vs. mingw with UCRT

On MSYS2, mingw can be used in two ways [1]: - with MSVCRT as runtime library (this is also what mingw on Cygwin does), - with UCRT as runtime library (same runtime library as used by MSVC). Comparing the config.cache values of a gnulib testdir in both cases, I see some small differences. For

Support several gnulib-tool invocations better

Gnulib supports multiple gnulib-tool invocations in the scope of the same configure.ac since 2021 (cf. 2021-04-11, 2021-04-17, 2021-06-13). Namely, the module indicator variable (@GNULIB_@) expand to something that depends on the gnulib-tool invocation. This is still not working right with some he