Hi Eli, > You are right that stdio-consolesafe.c might be required only for > lib-src/ programs such as etags; it is not needed by Emacs itself. > > However, we cannot use it as it is now, because it requires issymlink > and issymlinkat modules, and also stdio-h.
stdio-consolesafe.c is part of module 'stdio-h' because the functions fwrite(), fprintf() are so frequently used that Gnulib does not have an extra module for these functions. We _assume_ that any program that includes <stdio.h> is likely to use fwrite() and fprintf(). You don't need the 'issymlink' and 'issymlinkat' modules: $ ./gnulib-tool --extract-dependents issymlink chown lchmod lchown rename unlink utimens $ ./gnulib-tool --extract-dependents issymlinkat fchmodat lchmod renameatu unlinkat > building Emacs does not compile > stdio-consolesafe.c, and I cannot see why. Can you or Bruno explain > why this happens? > ... > In any case, I think we do want to compile and use > stdio-consolesafe.c, for the benefit of programs in lib-src/, but we > need to find a way of doing that without pulling in the above 3 > modules. That's because stdio-consolesafe.c is part of the 'stdio-h' module, which you have disabled. In this module we have the declarations gl_CONDITIONAL([GL_COND_OBJ_STDIO_CONSOLESAFE], [test $USES_MSVCRT = 1]) ... if GL_COND_OBJ_STDIO_CONSOLESAFE lib_SOURCES += stdio-consolesafe.c endif If you want stdio-consolesafe.c to be compiled although you don't import the 'stdio-h' module, you can do so by creating a module 'stdio-h-emacs' that includes just the appropriate definitions for this one source file. See https://www.gnu.org/software/gnulib/manual/html_node/Extending-Gnulib.html for this approach. > Bruno, can you suggest changes to Gnulib to do > that? Well, I could move stdio-consolesafe.c to an auxiliary module, but that would still depend on 'stdio-h'. Which means that you would still have to add a small amount of Autoconf code to emacs/configure.ac and a small amount of C declarations and C macro definitions to some emacs .h file. > There was one problem in this Gnulib merge which broke the MinGW build > of Emacs, and that's the change in acl_entries.c. Evidently, no one > envisioned that this file will be compiled in MinGW builds, but in > Emacs it is compiled Thanks for the report. Should be fixed by the patch below. 2025-11-05 Bruno Haible <[email protected]> acl-permissions: Fix compilation error (regression 2025-09-10). Reported by Eli Zaretskii <[email protected]> in <https://lists.gnu.org/archive/html/emacs-devel/2025-11/msg00155.html>. * lib/acl_entries.c (acl_entries): Restore a #if, mistakenly removed on 2025-09-10. diff --git a/lib/acl_entries.c b/lib/acl_entries.c index b78ba18a65..7b44e69489 100644 --- a/lib/acl_entries.c +++ b/lib/acl_entries.c @@ -22,7 +22,10 @@ #include "acl-internal.h" /* This file assumes POSIX-draft like ACLs - (Linux, FreeBSD, NetBSD >= 10, Mac OS X, Cygwin >= 2.5). */ + (Linux, FreeBSD, NetBSD >= 10, Mac OS X, Cygwin >= 2.5). + + It is compiled only on systems that do not have the acl_entries() function + (in libc or libacl). */ /* Return the number of entries in ACL. Return -1 and set errno upon failure to determine it. */ @@ -34,7 +37,8 @@ acl_entries (acl_t acl) if (acl != NULL) { -#if HAVE_ACL_TYPE_EXTENDED /* Mac OS X */ +#if HAVE_ACL_FIRST_ENTRY /* Linux, FreeBSD, NetBSD >= 10, Mac OS X, Cygwin >= 2.5 */ +# if HAVE_ACL_TYPE_EXTENDED /* Mac OS X */ /* acl_get_entry returns 0 when it successfully fetches an entry, and -1/EINVAL at the end. */ acl_entry_t ace; @@ -44,7 +48,7 @@ acl_entries (acl_t acl) got_one >= 0; got_one = acl_get_entry (acl, ACL_NEXT_ENTRY, &ace)) count++; -#else /* Linux, FreeBSD, NetBSD >= 10, Cygwin >= 2.5 */ +# else /* Linux, FreeBSD, NetBSD >= 10, Cygwin >= 2.5 */ /* acl_get_entry returns 1 when it successfully fetches an entry, and 0 at the end. */ acl_entry_t ace; @@ -56,6 +60,7 @@ acl_entries (acl_t acl) count++; if (got_one < 0) return -1; +# endif #endif }
