|
From: | Paul Eggert |
Subject: | bug#33847: 27.0.50; emacsclient does not find server socket |
Date: | Sat, 24 Jul 2021 00:48:25 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
On 7/23/21 11:23 PM, Eli Zaretskii wrote:
why in conjunction with this particular issue?
It's typically better to sync to a single coherent version of Gnulib, than to take bits and pieces from different versions of Gnulib. That way one needn't worry about version mismatch.
Although I fixed the glitches Eli noted, the other Gnulib changes may need further changes to Emacs's Microsoft-related code.Which of the Gnulib changes might need that, please?
I said that more as boilerplate than as careful analysis. But in looking at the patch more carefully, there may be issues in nt/gnulib-cfg.mk where you have to set the following appropriately for MS-Windows:
OMIT_GNULIB_MODULE_realloc-gnu OMIT_GNULIB_MODULE_realloc-posixThe realloc-posix module supplies a 'realloc' that conforms to POSIX (i.e., it sets errno when it fails, and it refuses to allocate anything larger than PTRDIFF_MAX in size).
The realloc-gnu module in addition makes sure that 'realloc' is compatible with GNU realloc (i.e., realloc (NULL, 0) returns nonnull when it succeeds).
The new file lib/realloc.c arranges for a replacement realloc on platforms where realloc-posix and/or realloc-gnu discover that the system realloc doesn't match glibc realloc in behavior.
The msdos directory may need to do something similar. Also, it may need to change "GNULIB_" to "GL_GNULIB_" for identifiers like GNULIB_GETLOADAVG.
There may be other issues, but these are the ones that jump out at me.Hmm, come to think of it, does Emacs already arrange to avoid the problematic realloc behavior areas? If so, we can avoid using realloc-gnu and realloc-posix, which would simplify the patch a bit.
[Prev in Thread] | Current Thread | [Next in Thread] |