Re: x-to-1
On Thu, 9 Feb 2023 at 02:49, Bruno Haible wrote: > > > > In general, then, it would be good if x-to-1 ignored unknown options and > > passed them to help2man; would that be possible? > > Passing down additional options to help2man is a very good idea; > implemented > below. Ignoring unknown options is not such a good idea; not implemented. > Thanks very much for this. There's one final thing that would be useful for recode: to make the .x file optional. Recode (unlike all the other programs I use with help2man) does not need any extra information. I tried simply creating an empty .x file, but help2man gives an error.
Re: mkfifoat: Fix crash on macOS 12
And this patch fixes the code duplication in the last patch. 2023-02-10 Bruno Haible Fix code duplication in last commit. * m4/gnulib-common.m4 (gl_CHECK_FUNCS_DEFAULT_CASE, gl_CHECK_FUNCS_CASE_FOR_ANDROID, gl_CHECK_FUNCS_CASE_FOR_MACOS, gl_CHECK_FUNCS_SET_RESULTS): New macros, extracted from gl_CHECK_FUNCS_ANDROID, gl_CHECK_FUNCS_MACOS, gl_CHECK_FUNCS_ANDROID_MACOS. (gl_CHECK_FUNCS_ANDROID, gl_CHECK_FUNCS_MACOS, gl_CHECK_FUNCS_ANDROID_MACOS): Use them. diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4 index ff2ea3d4f6..c84a2afd9c 100644 --- a/m4/gnulib-common.m4 +++ b/m4/gnulib-common.m4 @@ -1095,6 +1095,113 @@ AC_DEFUN([gl_CONDITIONAL_HEADER], m4_popdef([gl_header_name]) ]) +dnl Preparations for gl_CHECK_FUNCS_MACOS. +AC_DEFUN([gl_PREPARE_CHECK_FUNCS_MACOS], +[ + AC_REQUIRE([AC_CANONICAL_HOST]) + AC_REQUIRE([gl_COMPILER_CLANG]) + AC_CACHE_CHECK([for compiler option needed when checking for future declarations], +[gl_cv_compiler_check_future_option], +[case "$host_os" in + dnl This is only needed on macOS. + darwin*) + if test $gl_cv_compiler_clang = yes; then + dnl Test whether the compiler supports the option + dnl '-Werror=unguarded-availability-new'. + save_ac_compile="$ac_compile" + ac_compile="$ac_compile -Werror=unguarded-availability-new" + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]],[[]])], + [gl_cv_compiler_check_future_option='-Werror=unguarded-availability-new'], + [gl_cv_compiler_check_future_option=none]) + ac_compile="$save_ac_compile" + else + gl_cv_compiler_check_future_option=none + fi + ;; + *) gl_cv_compiler_check_future_option=none ;; + esac +]) +]) + +dnl Pieces of the expansion of +dnl gl_CHECK_FUNCS_ANDROID +dnl gl_CHECK_FUNCS_MACOS +dnl gl_CHECK_FUNCS_ANDROID_MACOS + +AC_DEFUN([gl_CHECK_FUNCS_DEFAULT_CASE], +[ + *) + AC_CHECK_FUNC([$1]) + [gl_cv_onwards_func_][$1]=$[ac_cv_func_][$1] + ;; +]) + +AC_DEFUN([gl_CHECK_FUNCS_CASE_FOR_ANDROID], +[ + linux*-android*) + AC_CHECK_DECL([$1], , , [$2]) + if test $[ac_cv_have_decl_][$1] = yes; then + AC_CHECK_FUNC([[$1]]) + if test $[ac_cv_func_][$1] = yes; then + [gl_cv_onwards_func_][$1]=yes + else + dnl The function is declared but does not exist. This should not + dnl happen normally. But anyway, we know that a future version + dnl of Android will have the function. + [gl_cv_onwards_func_][$1]='future OS version' + fi + else + [gl_cv_onwards_func_][$1]='future OS version' + fi + ;; +]) + +AC_DEFUN([gl_CHECK_FUNCS_CASE_FOR_MACOS], +[ + darwin*) + if test "x$gl_cv_compiler_check_future_option" != "xnone"; then + dnl Use a compile test, not a link test. + save_ac_compile="$ac_compile" + ac_compile="$ac_compile $gl_cv_compiler_check_future_option" + save_ac_compile_for_check_decl="$ac_compile_for_check_decl" + ac_compile_for_check_decl="$ac_compile_for_check_decl $gl_cv_compiler_check_future_option" + unset [ac_cv_have_decl_][$1] + AC_CHECK_DECL([$1], , , [$2]) + ac_compile="$save_ac_compile" + ac_compile_for_check_decl="$save_ac_compile_for_check_decl" + [ac_cv_func_][$1]="$[ac_cv_have_decl_][$1]" + if test $[ac_cv_func_][$1] = yes; then + [gl_cv_onwards_func_][$1]=yes + else + unset [ac_cv_have_decl_][$1] + AC_CHECK_DECL([$1], , , [$2]) + if test $[ac_cv_have_decl_][$1] = yes; then + [gl_cv_onwards_func_][$1]='future OS version' + else + [gl_cv_onwards_func_][$1]=no + fi + fi + else + AC_CHECK_FUNC([$1]) + [gl_cv_onwards_func_][$1]=$[ac_cv_func_][$1] + fi + ;; +]) + +AC_DEFUN([gl_CHECK_FUNCS_SET_RESULTS], +[ + case "$[gl_cv_onwards_func_][$1]" in +future*) [ac_cv_func_][$1]=no ;; +*) [ac_cv_func_][$1]=$[gl_cv_onwards_func_][$1] ;; + esac + if test $[ac_cv_func_][$1] = yes; then +AC_DEFINE([HAVE_]m4_translit([[$1]], + [abcdefghijklmnopqrstuvwxyz], + [ABCDEFGHIJKLMNOPQRSTUVWXYZ]), + [1], [Define to 1 if you have the `$1' function.]) + fi +]) + dnl gl_CHECK_FUNCS_ANDROID([func], [[#include ]]) dnl is like AC_CHECK_FUNCS([func]), taking into account a portability problem dnl on Android. @@ -1137,67 +1244,12 @@ AC_DEFUN([gl_CHECK_FUNCS_ANDROID], [[gl_cv_onwards_func_][$1]], [gl_SILENT([ case "$host_os" in -
macOS 12 status
On the macOS 12 machine, a Gnulib testdir now compiles fine, and usually all tests pass. Usually, because sometimes the test-system-quote.sh test fails, reporting that a system() invocation failed with status 768 (= 0x0300). Sounds weird... Log is attached. Bruno for input = |a z |: system() command failed with status 768: ./test-system-quote-child a z for input = |a z |: popen() command failed with status 768: ./test-system-quote-child a z FAIL test-system-quote.sh (exit status: 1)
mkfifoat: Fix crash on macOS 12
Building a testdir on macOS 12.5, I see this test failure:
FAIL: test-mkfifoat
===
FAIL test-mkfifoat (exit status: 139)
What's going on, is that the function mkfifoat (and likewise mknodat) is only
available in macOS ≥ 13.0, and in older macOS versions the function call just
crashes.
See:
$ cat foo.c
#include
#include
#include
int main ()
{
int ret = mkfifoat (AT_FDCWD, "foo", 0600);
printf("ret=%d\n", ret);
return 0;
}
$ cc foo.c
foo.c:6:13: warning: 'mkfifoat' is only available on macOS 13.0 or newer
[-Wunguarded-availability-new]
int ret = mkfifoat (AT_FDCWD, "foo", 0600);
^~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/stat.h:394:9:
note: 'mkfifoat' has been marked as being introduced in macOS 13.0 here, but
the deployment target is macOS 12.0.0
int mkfifoat(int, const char *, mode_t) __API_AVAILABLE(macos(13.0),
ios(16.0), tvos(16.0), watchos(9.0));
^
foo.c:6:13: note: enclose 'mkfifoat' in a __builtin_available check to silence
this warning
int ret = mkfifoat (AT_FDCWD, "foo", 0600);
^~~~
1 warning generated.
Indeed, the macroexpanded declaration in looks like this:
int mkfifoat(int, const char *, mode_t)
__attribute__((availability(macos,introduced=13.0)))
__attribute__((availability(ios,introduced=16.0)))
__attribute__((availability(tvos,introduced=16.0)))
__attribute__((availability(watchos,introduced=9.0)));
On macOS (like for Android), it is possible to build binaries for a range
of OS versions, by specifying the minimum OS version. See
https://clang.llvm.org/docs/LanguageExtensions.html#objective-c-available
https://clang.llvm.org/docs/DiagnosticsReference.html#wunguarded-availability-new
In Android, the main effect of specifying the minimum Android version is to
make the function's declaration appear or disappear.
In macOS, the main effect of specifying the minimum macOS version is to
let the compiler evaluate whether the function should be usable or not;
the declaration stays the same regardless. So, one needs a compiler warning
(-Wunguarded-availability-new) in order to distinguish an available function
from a future function.
There's a related compiler built-in __builtin_available(), but it's better
to avoid it in Gnulib. See https://github.com/curl/curl/issues/4314 .
This patch fixes the issue, by changing the configure-time detection
checking for mkfifoat... yes
to
checking for mkfifoat... future OS version
and likewise for mknodat.
2023-02-10 Bruno Haible
mkfifoat: Fix crash on macOS 12.
* m4/gnulib-common.m4 (gl_PREPARE_CHECK_FUNCS_MACOS,
gl_CHECK_FUNCS_MACOS, gl_CHECK_FUNCS_ANDROID_MACOS): New macros.
* m4/mkfifoat.m4 (gl_FUNC_MKFIFOAT): Test for mknodat and mkfifoat using
gl_CHECK_FUNCS_ANDROID_MACOS instead of gl_CHECK_FUNCS_ANDROID.
diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4
index 1e6748ed8c..ff2ea3d4f6 100644
--- a/m4/gnulib-common.m4
+++ b/m4/gnulib-common.m4
@@ -1,4 +1,4 @@
-# gnulib-common.m4 serial 81
+# gnulib-common.m4 serial 82
dnl Copyright (C) 2007-2023 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -1172,6 +1172,202 @@ AC_DEFUN([gl_CHECK_FUNCS_ANDROID],
fi
])
+dnl Preparations for gl_CHECK_FUNCS_MACOS.
+AC_DEFUN([gl_PREPARE_CHECK_FUNCS_MACOS],
+[
+ AC_REQUIRE([AC_CANONICAL_HOST])
+ AC_REQUIRE([gl_COMPILER_CLANG])
+ AC_CACHE_CHECK([for compiler option needed when checking for future
declarations],
+[gl_cv_compiler_check_future_option],
+[case "$host_os" in
+ dnl This is only needed on macOS.
+ darwin*)
+ if test $gl_cv_compiler_clang = yes; then
+ dnl Test whether the compiler supports the option
+ dnl '-Werror=unguarded-availability-new'.
+ save_ac_compile="$ac_compile"
+ ac_compile="$ac_compile -Werror=unguarded-availability-new"
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]],[[]])],
+
[gl_cv_compiler_check_future_option='-Werror=unguarded-availability-new'],
+ [gl_cv_compiler_check_future_option=none])
+ ac_compile="$save_ac_compile"
+ else
+ gl_cv_compiler_check_future_option=none
+ fi
+ ;;
+ *) gl_cv_compiler_check_future_option=none ;;
+ esac
+])
+])
+
+dnl gl_CHECK_FUNCS_MACOS([func], [[#include ]])
+dnl is like AC_CHECK_FUNCS([func]), taking into account a portability problem
+dnl on macOS.
+dnl
+dnl When code is compiled on macOS, it is in the context of a certain minimum
+dnl macOS version, that can be set through the option '-mmacosx-version-min='.
+dnl In other words, you don't compile for a specific version of macOS. You
+dnl compile for all versions of macOS, onwards from the given version.
+dnl Thus, the question "does the OS have the function func" has three possible
+dnl answers:
+dnl - yes,
Re: [PATCH] fix typos like "the the" and "a a" in comment
ChuanGang Jiang wrote: > *lib/c32is-impl.h: s/the the/the/ > *lib/getopt-pfx-core.h: s/a a/a/ > *lib/term-style-control.h: s/the the/the/ > *lib/textstyle.in.h: s/the the/the/ Thanks. Applied. Bruno
[PATCH] fix typos like "the the" and "a a" in comment
*lib/c32is-impl.h: s/the the/the/
*lib/getopt-pfx-core.h: s/a a/a/
*lib/term-style-control.h: s/the the/the/
*lib/textstyle.in.h: s/the the/the/
---
lib/c32is-impl.h | 2 +-
lib/getopt-pfx-core.h| 2 +-
lib/term-style-control.h | 2 +-
lib/textstyle.in.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/c32is-impl.h b/lib/c32is-impl.h
index 5917348dc1..dba00b51ae 100644
--- a/lib/c32is-impl.h
+++ b/lib/c32is-impl.h
@@ -67,7 +67,7 @@ FUNC (wint_t wc)
return WCHAR_FUNC (wc);
# else
/* The char32_t encoding of a multibyte character is known to be UCS-4,
- different from the the wchar_t encoding. */
+ different from the wchar_t encoding. */
if (wc != WEOF)
return UCS_FUNC (wc);
else
diff --git a/lib/getopt-pfx-core.h b/lib/getopt-pfx-core.h
index 3a2fde5ad4..095e3930fe 100644
--- a/lib/getopt-pfx-core.h
+++ b/lib/getopt-pfx-core.h
@@ -47,7 +47,7 @@
# define optind __GETOPT_ID (optind)
# define optopt __GETOPT_ID (optopt)
-/* Work around a a problem on macOS, which declares getopt with a
+/* Work around a problem on macOS, which declares getopt with a
trailing __DARWIN_ALIAS(getopt) that would expand to something like
__asm("_" "rpl_getopt" "$UNIX2003") were it not for the following
hack to suppress the macOS declaration . */
diff --git a/lib/term-style-control.h b/lib/term-style-control.h
index 3f853bb941..4e14c7c5b1 100644
--- a/lib/term-style-control.h
+++ b/lib/term-style-control.h
@@ -37,7 +37,7 @@ typedef enum
be left in the default state when the program is
interrupted. */
TTYCTL_FULL /* Signal handling and disabling echo and
flush-upon-signal.
- Result: No garbled output, and the the terminal will
+ Result: No garbled output, and the terminal will
be left in the default state when the program is
interrupted. */
} ttyctl_t;
diff --git a/lib/textstyle.in.h b/lib/textstyle.in.h
index 111e1e10d3..38645bf6f8 100644
--- a/lib/textstyle.in.h
+++ b/lib/textstyle.in.h
@@ -392,7 +392,7 @@ typedef enum
be left in the default state when the program is
interrupted. */
TTYCTL_FULL /* Signal handling and disabling echo and
flush-upon-signal.
- Result: No garbled output, and the the terminal will
+ Result: No garbled output, and the terminal will
be left in the default state when the program is
interrupted. */
} ttyctl_t;
--
2.36.1
Re: [PATCH] Do not decorate symbols as dllexport on Cygwin
Corinna Vinschen wrote: > > In Cygwin projects using libtool, we always have to add -no-undefined > > in LDFLAGS. Likewise for AIX, IIRC. Reuben Thomas wrote: > > Patch is attached. It would be nice if that's ok for inclusion. > > > I did apply this patch, but just noticed that it broke the Mingwin build; > see: > > https://github.com/rrthomas/recode/actions/runs/4115515520/jobs/7104330023 > > I haven't had time to look into it yet; help welcome! It complains about the symbols defined in libiconv. This means, you need to invoke the Gnulib module 'iconv' and add $(LIBICONV) or $(LTLIBICONV) to the LDFLAGS. Bruno
Re: [PATCH] Do not decorate symbols as dllexport on Cygwin
On Tue, 7 Feb 2023 at 15:22, Corinna Vinschen wrote: > In Cygwin projects using libtool, we always have to add -no-undefined > iLDFLAGS. This is some old safe-guard in libtool to remind developers > that when creating Windows DLLs, all external symbols must be resolved. > > Fortunately, libtool allows this flags also on other platforms which > don't require its usage. > > Patch is attached. It would be nice if that's ok for inclusion. I did apply this patch, but just noticed that it broke the Mingwin build; see: https://github.com/rrthomas/recode/actions/runs/4115515520/jobs/7104330023 I haven't had time to look into it yet; help welcome! -- https://rrt.sc3d.org
chown, lchown, fchownat tests: Avoid test failure on macOS 12
On macOS 12.5, I see these 3 test failures:
FAIL: test-chown
../../gltests/test-chown.h:75: assertion 'st1.st_gid == getegid ()' failed
FAIL test-chown (exit status: 134)
FAIL: test-fchownat
===
../../gltests/test-chown.h:75: assertion 'st1.st_gid == getegid ()' failed
FAIL test-fchownat (exit status: 134)
FAIL: test-lchown
=
../../gltests/test-lchown.h:83: assertion 'st1.st_gid == getegid ()' failed
FAIL test-lchown (exit status: 134)
It is a particular situation, I guess, probably due to being logged in through
ssh: getgid() and getegid() both return (gid_t)(-1). But the st_gid of
freshly created files is reasonable.
This patch avoids the test failures. I could also make the entire test SKIPped,
but that would be exaggerated.
2023-02-10 Bruno Haible
chown, lchown, fchownat tests: Avoid test failure on macOS 12.
* tests/test-chown.h (test_chown): Skip some assertions if
getgid() == (gid_t)-1.
* tests/test-lchown.h (test_lchown): Likewise.
diff --git a/tests/test-chown.h b/tests/test-chown.h
index e8c3d49ff9..4c7b6eec33 100644
--- a/tests/test-chown.h
+++ b/tests/test-chown.h
@@ -72,7 +72,10 @@ test_chown (int (*func) (char const *, uid_t, gid_t), bool
print)
ASSERT (stat (BASE "dir/file", ) == 0);
ASSERT (st1.st_uid != (uid_t) -1);
ASSERT (st1.st_gid != (gid_t) -1);
- ASSERT (st1.st_gid == getegid ());
+ /* On macOS 12, when logged in through ssh, getgid () and getegid () are both
+ == (gid_t) -1. */
+ if (getgid () != (gid_t) -1)
+ASSERT (st1.st_gid == getegid ());
/* Sanity check of error cases. */
errno = 0;
@@ -132,7 +135,8 @@ test_chown (int (*func) (char const *, uid_t, gid_t), bool
print)
if (1 < gids_count)
{
ASSERT (gids[1] != st1.st_gid);
- ASSERT (gids[1] != (gid_t) -1);
+ if (getgid () != (gid_t) -1)
+ASSERT (gids[1] != (gid_t) -1);
ASSERT (lstat (BASE "dir/link", ) == 0);
ASSERT (st1.st_uid == st2.st_uid);
ASSERT (st1.st_gid == st2.st_gid);
@@ -156,7 +160,8 @@ test_chown (int (*func) (char const *, uid_t, gid_t), bool
print)
ASSERT (func (BASE "dir/link2", -1, gids[1]) == 0);
ASSERT (stat (BASE "dir/file", ) == 0);
ASSERT (st1.st_uid == st2.st_uid);
- ASSERT (gids[1] == st2.st_gid);
+ if (getgid () != (gid_t) -1)
+ASSERT (gids[1] == st2.st_gid);
ASSERT (lstat (BASE "dir/link", ) == 0);
ASSERT (st1.st_uid == st2.st_uid);
ASSERT (st1.st_gid == st2.st_gid);
diff --git a/tests/test-lchown.h b/tests/test-lchown.h
index 1e5dffef7f..1c68f4a1ba 100644
--- a/tests/test-lchown.h
+++ b/tests/test-lchown.h
@@ -80,7 +80,10 @@ test_lchown (int (*func) (char const *, uid_t, gid_t), bool
print)
ASSERT (stat (BASE "dir/file", ) == 0);
ASSERT (st1.st_uid != (uid_t) -1);
ASSERT (st1.st_gid != (gid_t) -1);
- ASSERT (st1.st_gid == getegid ());
+ /* On macOS 12, when logged in through ssh, getgid () and getegid () are both
+ == (gid_t) -1. */
+ if (getgid () != (gid_t) -1)
+ASSERT (st1.st_gid == getegid ());
/* Sanity check of error cases. */
errno = 0;
@@ -150,7 +153,8 @@ test_lchown (int (*func) (char const *, uid_t, gid_t), bool
print)
if (1 < gids_count)
{
ASSERT (gids[1] != st1.st_gid);
- ASSERT (gids[1] != (gid_t) -1);
+ if (getgid () != (gid_t) -1)
+ASSERT (gids[1] != (gid_t) -1);
ASSERT (lstat (BASE "dir/link", ) == 0);
ASSERT (st1.st_uid == st2.st_uid);
ASSERT (st1.st_gid == st2.st_gid);
@@ -180,7 +184,8 @@ test_lchown (int (*func) (char const *, uid_t, gid_t), bool
print)
ASSERT (st1.st_gid == st2.st_gid);
ASSERT (lstat (BASE "dir/link2", ) == 0);
ASSERT (st1.st_uid == st2.st_uid);
- ASSERT (gids[1] == st2.st_gid);
+ if (getgid () != (gid_t) -1)
+ASSERT (gids[1] == st2.st_gid);
/* Trailing slash follows through to directory. */
ASSERT (lstat (BASE "dir/link3", ) == 0);
@@ -196,7 +201,8 @@ test_lchown (int (*func) (char const *, uid_t, gid_t), bool
print)
ASSERT (st1.st_gid == st2.st_gid);
ASSERT (lstat (BASE "dir/sub", ) == 0);
ASSERT (st1.st_uid == st2.st_uid);
- ASSERT (gids[1] == st2.st_gid);
+ if (getgid () != (gid_t) -1)
+ASSERT (gids[1] == st2.st_gid);
}
else if (!CHOWN_CHANGE_TIME_BUG || HAVE_LCHMOD)
{
Re: nullptr in C++ mode on macOS
Jeffrey Walton wrote: > Then you have Apple's version of Clang. They are probably C++03 for > compatibility reasons for Xcode developers. So even if LLVM moved to > C++11, Apple's Clang may stay at C++03. Ah, that explains the nullptr issue with this compiler, and also why we have to test __apple_build_version__ (or __APPLE_CC__) in a couple of places. > > I don't know how to proceed here. C++ is such a waste of time!! > > In the projects I work on, I use a library specific define. In > Gnulib's case, it would be GNULIB_NULLPTR. Then I have a feature test > to set GNULIB_NULLPTR to either nullptr or NULL. The strategy works > well for me. > > #if defined(HAVE_CXX11_NULLPTR) > # define GNULIB_NULLPTR nullptr > #else > # define GNULIB_NULLPTR NULL > #endif In Gnulib, we started with this coding style many years ago. Then switched to the today's style where the programmer can use exactly the identifiers from the relevant standards (POSIX, ISO C, ISO C++), without some 'gnulib_' or 'gl_' prefixes in most of the cases. Bruno
Re: nullptr in C++ mode on macOS
Paul Eggert wrote: > Let's treat C++ overloading like we already treat C _Generic, that is, > as a documented limitation of the substitute nullptr macro. This should > be good enough for Gnulib itself. I installed the attached to document > that, and to work around the Apple clang 14 incompatibility with it in mind. It should also be good enough for real C++ packages such as groff and octave, which both use nullptr but not nullptr_t. > Yes, but all that's needed here is to implement Gnulib's limited > substitute well enough to work with Apple clang 14 and any other > compilers that have similar incompatibilities with current C++. It works fine. Clever. Thank you!! Thank you Arsen, for the proposal. I prefer Paul's approach because it avoids getting deeper and deeper into the C++ swamp of complicated inconsistencies. Bruno
