Re: strftime-induced linker errors on Android API 35.

On 2025-05-08 17:50, Po Lu wrote: I will be unable to merge this update into Emacs for several days yet as my attention is currently concentrated elsewhere, but if anyone does it will be automatically tested within 24 hours. I merged it.

Re: strftime-induced linker errors on Android API 35.

Bruno Haible writes: > B) Always use the C locale. This is suitable because the C locale is the > only one supported on Android. (See bionic/libc/tzcode/strftime.c .) [...] > I went for approach B, because it is the simplest one. > > > 2025-05-08 Bruno Haible > > nstrftime: Fix a

Re: MSYS2 and mingw

Reuben Thomas wrote: > Also it would be nice to have some advice on what to use instead. Bruno > outlined to me that there are at least 3 options for developing for MinGW: > > 1. Cross-compile from GNU/Linux, use WINE to run compiled programs. > 2. Use MSYS2 (but we don't like this) > 3. Use Cygwi

Re: MSYS2 and mingw

Reuben Thomas writes: > 1. Cross-compile from GNU/Linux, use WINE to run compiled programs. > 2. Use MSYS2 (but we don't like this) > 3. Use Cygwin with mingw packages > > My problem is that I'm trying to build and test portable packages on native > Windows. Therefore, option 1 is rather weak (it

Re: MSYS2 and mingw

Collin Funk wrote: > Since the whole MSYS2 thing has caused repeated confusion, including to > me [1], maybe we should add a section to the Gnulib manual. I agree with you that the best way to fix this confusion is through documentation. But not in the Gnulib manual, since the confusion is unrelat

Re: MSYS2 and mingw

Hi Bruno, Bruno Haible via Gnulib discussion list writes: > That is the MSYS2 environment, and in particular with an augmented PATH > that contains tools for producing mingw binaries that are linked to > the Microsoft 'MSVCRT' runtime library. > > Whereas the other one, that MSYS2 calls "UCRT64"

Re: z/OS access

Bruno Haible writes: >> This reminds me. I recently found out IBM allows you to request access >> to z/OS to "Develop and test open source on z/OS" or "Set up an open >> source CI/CD pipeline on z/OS" [1]. > > There's also a similar option to request access to Linux/s390x hardware [4]. [...] > [4

Re: MSYS2 and mingw

On Thu, 8 May 2025 at 22:37, Collin Funk wrote: > Since the whole MSYS2 thing has caused repeated confusion, including to > me [1], maybe we should add a section to the Gnulib manual. > Also it would be nice to have some advice on what to use instead. Bruno outlined to me that there are at least

Re: MSYS2 and mingw

Reuben Thomas wrote: > I am not using MSYS2 per se, I am using the Mingw64 environment There is no such thing as "the Mingw64 environment". Better be careful about the terms. We need to distinguish * mingw - which is a toolchain (set of runtime libraries, together with a customized

Re: relocatable failure on mingw owing to command-line argument processing by GCC

On Thu, 8 May 2025 at 17:01, Bruno Haible wrote: > Hi Reuben, > > Reuben Thomas wrote: > > ... > > The problem appears to be that INSTALLDIR is passed to the compiler on > the > > command line, and something in the mingw64 machinery says "aha! it's a > > path!" and transforms it to Windows style.

Re: relocatable failure on mingw owing to command-line argument processing by GCC

Hi Reuben, Reuben Thomas wrote: > ... > The problem appears to be that INSTALLDIR is passed to the compiler on the > command line, and something in the mingw64 machinery says "aha! it's a > path!" and transforms it to Windows style. Yes, this is the same problem for which I am writing in the INST

relocatable failure on mingw owing to command-line argument processing by GCC

I was noticing that relocate() was failing to produce a sensible answer on MSYS2's mingw64 for library paths (relocatable-lib-lgpl). On investigation, compute_curr_prefix was returning NULL, because orig_installprefix was /mingw64, while orig_installdir was C:/msys64/ming64/bin: that is, the forme

Re: strftime-induced linker errors on Android API 35.

So, the situation is: * timezone_t exists * The functions tzalloc, tzfree, mktime_z, localtime_rz exist timezone_t _Nullable tzalloc(const char* _Nullable __id) __INTRODUCED_IN(35); void tzfree(timezone_t _Nullable __tz) __INTRODUCED_IN(35); time_t mktime_z(timezone_t _Nonnull __t

Re: [PATCH] Fix some ungrammatical uses of "allows to"

Paul Eggert wrote: > diff --git a/m4/libgcrypt.m4 b/m4/libgcrypt.m4 This change will be reverted by Karl's next autoupdate; see config/srclist.txt. Upstream libgcrypt.m4 is at https://dev.gnupg.org/source/libgcrypt.git . Bruno

[PATCH] Fix some ungrammatical uses of "allows to"

This buys back some comment changes from Emacs, and fixes other instances I noticed. --- ChangeLog| 6 +++--- build-aux/announce-gen | 4 ++-- build-aux/prefix-gnulib-mk | 4 ++-- build-aux/useless-if-before-free | 4 ++-- doc/posix-functions/utimes.texi