Re: [PATCH] Add cross-compilation guesses for Midipix
Ørjan Malde wrote: > > So, will config.sub stay as it is, and the pattern to check for is midipix* > > ? > > > > The triplet naming is out of my control, it's integrated with tools new > and existing, and personally I like it the way it is. OK, then the pattern is midipix*. I'm committing this patch. This handles all references to musl in m4/*, except for m4/canonicalize.m4:164:*-musl*) gl_cv_func_realpath_works="guessing nearly" ;; m4/chmod.m4:65: *-gnu* | gnu* | *-musl* | darwin* | freebsd* | midnightbsd* | netbsd* | openbsd* | solaris* | haiku* | cygwin*) m4/chown.m4:117: *-musl*) gl_cv_func_chown_slash_works="guessing yes" ;; m4/chown.m4:156: *-musl*) gl_cv_func_chown_ctime_works="guessing yes" ;; m4/d-ino.m4:46: linux*-musl*) gl_cv_struct_dirent_d_ino="guessing yes" ;; m4/futimens.m4:56:*-musl*) gl_cv_func_futimens_works="guessing no" ;; m4/getcwd.m4:55:*-musl*) gl_cv_func_getcwd_null="guessing yes";; m4/getgroups.m4:44: *-musl*) ac_cv_func_getgroups_works="guessing yes" ;; m4/getgroups.m4:98: *-musl*) gl_cv_func_getgroups_works="guessing yes" ;; m4/link-follow.m4:92: linux*-musl*) gl_cv_func_link_follows_symlink="guessing no" ;; m4/mkdir.m4:69: *-musl*) gl_cv_func_mkdir_trailing_dot_works="guessing yes" ;; m4/ptsname.m4:34:*-musl*) gl_cv_func_ptsname_sets_errno="guessing yes" ;; m4/sleep.m4:52: *-musl*) gl_cv_func_sleep_works="guessing yes" ;; m4/usleep.m4:35: *-musl*) gl_cv_func_usleep_works="guessing yes" ;; m4/utimes.m4:148: *-musl*) gl_cv_func_working_utimes="guessing yes" ;; 2023-02-17 Bruno Haible Improve cross-compilation from midipix. Reported by Ørjan Malde at <https://lists.gnu.org/archive/html/bug-gnulib/2023-02/msg00131.html>. Since midipix consists of musl libc based on an emulation of Linux system calls, for pure libc functionality it can be treated like musl libc. * m4/calloc.m4 (_AC_FUNC_CALLOC_IF): Treat midipix like systems with musl libc. * m4/cbrtl.m4 (gl_FUNC_CBRTL): Likewise. * m4/ceil.m4 (gl_FUNC_CEIL): Likewise. * m4/ceilf.m4 (gl_FUNC_CEILF): Likewise. * m4/ceill.m4 (gl_FUNC_CEILL): Likewise. * m4/exp2l.m4 (gl_FUNC_EXP2L): Likewise. * m4/expl.m4 (gl_FUNC_EXPL): Likewise. * m4/expm1.m4 (gl_FUNC_EXPM1): Likewise. * m4/expm1f.m4 (gl_FUNC_EXPM1F): Likewise. * m4/expm1l.m4 (gl_FUNC_EXPM1L): Likewise. * m4/fclose.m4 (gl_FUNC_FCLOSE_STDIN): Likewise. * m4/fdopendir.m4 (gl_FUNC_FDOPENDIR): Likewise. * m4/ffsll.m4 (gl_FUNC_FFSLL): Likewise. * m4/floor.m4 (gl_FUNC_FLOOR): Likewise. * m4/floorf.m4 (gl_FUNC_FLOORF): Likewise. * m4/fmod.m4 (gl_FUNC_FMOD): Likewise. * m4/fmodf.m4 (gl_FUNC_FMODF): Likewise. * m4/fmodl.m4 (gl_FUNC_FMODL): Likewise. * m4/fnmatch.m4 (gl_FUNC_FNMATCH_POSIX): Likewise. * m4/fopen.m4 (gl_FUNC_FOPEN_GNU): Likewise. * m4/fpurge.m4 (gl_FUNC_FPURGE): Likewise. * m4/getdelim.m4 (gl_FUNC_GETDELIM): Likewise. * m4/getline.m4 (gl_FUNC_GETLINE): Likewise. * m4/hypot.m4 (gl_FUNC_HYPOT): Likewise. * m4/hypotf.m4 (gl_FUNC_HYPOTF): Likewise. * m4/hypotl.m4 (gl_FUNC_HYPOTL): Likewise. * m4/iconv_open-utf.m4 (gl_FUNC_ICONV_OPEN_UTF_SUPPORT): Likewise. * m4/log.m4 (gl_FUNC_LOG): Likewise. * m4/log10.m4 (gl_FUNC_LOG10): Likewise. * m4/log10f.m4 (gl_FUNC_LOG10F): Likewise. * m4/log10l.m4 (gl_FUNC_LOG10L_WORKS): Likewise. * m4/log1p.m4 (gl_FUNC_LOG1P): Likewise. * m4/log1pf.m4 (gl_FUNC_LOG1PF): Likewise. * m4/log1pl.m4 (gl_FUNC_LOG1PL, gl_FUNC_LOG1PL_WORKS): Likewise. * m4/log2.m4 (gl_FUNC_LOG2): Likewise. * m4/log2f.m4 (gl_FUNC_LOG2F): Likewise. * m4/log2l.m4 (gl_FUNC_LOG2L_WORKS): Likewise. * m4/logf.m4 (gl_FUNC_LOGF): Likewise. * m4/logl.m4 (gl_FUNC_LOGL_WORKS): Likewise. * m4/malloc.m4 (_AC_FUNC_MALLOC_IF): Likewise. * m4/mkstemp.m4 (gl_FUNC_MKSTEMP): Likewise. * m4/modf.m4 (gl_FUNC_MODF): Likewise. * m4/modff.m4 (gl_FUNC_MODFF): Likewise. * m4/modfl.m4 (gl_FUNC_MODFL): Likewise. * m4/musl.m4 (gl_MUSL_LIBC): Likewise. * m4/perror.m4 (gl_FUNC_PERROR): Likewise. * m4/posix_spawn.m4 (gl_POSIX_SPAWN_SECURE, gl_FUNC_POSIX_SPAWN_FILE_ACTIONS_ADDCLOSE, gl_FUNC_POSIX_SPAWN_FILE_ACTIONS_ADDDUP2, gl_FUNC_POSIX_SPAWN_FILE_ACTIONS_ADDOPEN): Likewise. * m4/printf.m4 (gl_PRINTF_SIZES_C99, gl_PRINTF_
Re: gnulib does not always detect need for iconv() hack on musl
On Mon, Oct 18, 2021 at 02:27:38AM +0200, Bruno Haible wrote:
> > The current code in config.guess is a heuristic (that has been working
> > on Alpine Linux up to 3.13)
>
> It works also in Alpine Linux 3.14.2. Which distro are you using?
I'm trying to use it on NixOS. I think I tracked it down to infelicity
of bootstrap environment.
For most packages config.guess returns correct value:
$ nix develop -f. pkgsMusl.bison
$ unpackPhase
$ cd bison-3.7.6
$ ./build-aux/config.guess
x86_64-pc-linux-musl
But for packages that use bootstrap toolchain the detection fails:
# don't know how to get better environment against bootstrap toolchain
$ nix develop /nix/store/iwlhpwbfmr6v5mh0g6iabl3161am5gdd-bison-3.8.2.drv
$ unpackPhase
$ cd bison-3.8.2
$ ./build-aux/config.guess
x86_64-pc-linux-gnu
When I compare the two the difference is in expansion of
#include
(exactly what 'config.guess' probes).
In a good case 'stdarg.h' from musl is used:
$ echo '#include ' | gcc -E - | unnix
# 1 ""
# 1 ""
# 1 ""
# 1 "/<>/musl-1.2.2-dev/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 ""
# 1 "/<>/musl-1.2.2-dev/include/stdarg.h" 1 3 4
# 10 "/<>/musl-1.2.2-dev/include/stdarg.h" 3 4
# 1 "/<>/musl-1.2.2-dev/include/bits/alltypes.h" 1 3 4
# 326 "/<>/musl-1.2.2-dev/include/bits/alltypes.h" 3 4
# 326 "/<>/musl-1.2.2-dev/include/bits/alltypes.h" 3 4
typedef __builtin_va_list va_list;
# 11 "/<>/musl-1.2.2-dev/include/stdarg.h" 2 3 4
# 2 "" 2
In a bad case we use gcc's wrapper of 'stdarg.h':
$ echo '#include ' | gcc -E - | unnix
# 1 ""
# 1 ""
# 1 ""
# 1 "/<>/bootstrap-tools/include-libc/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 ""
# 1
"/<>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include/stdarg.h"
1 3
# 40
"/<>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include/stdarg.h"
3
# 40
"/<>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include/stdarg.h"
3
typedef __builtin_va_list __gnuc_va_list;
# 99
"/<>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include/stdarg.h"
3
typedef __gnuc_va_list va_list;
# 1 "" 2
I think it happens because NixOS's bootstrap toolchain uses slightly
different include orders:
Good case:
/<>/gcc-10.3.0/include
/<>/musl-1.2.2-dev/include
# ^ <<<- picked 'stdarg.h' from here, musl version
/<>/gcc-10.3.0/lib/gcc/x86_64-unknown-linux-musl/10.3.0/include
/<>/gcc-10.3.0/lib/gcc/x86_64-unknown-linux-musl/10.3.0/include-fixed
Bad case:
/<>/bootstrap-tools/bin/../lib/gcc/x86_64-unknown-linux-musl/7.3.0/include
# ^ <<<- picked stdarg from here, gcc version
/<>/bootstrap-tools/bin/../lib/gcc/../../include
/<>/bootstrap-stage0-musl-bootstrap/include
/<>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include-fixed
Perhaps "Bad case" is more natural include order as 'gcc' tries hard
nowadays to isolate standard headers from accidental namespace
pollution (like '__DEFINED_va_list' define config.guess searches for).
I'll bring it to NixOS first to find out what is intended order here first.
--
Sergei
Re: [PATCH] Add cross-compilation guesses for Midipix
--- Original Message --- On Friday, February 17th, 2023 at 4:31 PM, Bruno Haible wrote: > Ørjan Malde wrote: > > > > So, will config.sub stay as it is, and the pattern to check for is > > > midipix* ? > > > > The triplet naming is out of my control, it's integrated with tools new > > and existing, and personally I like it the way it is. > > > OK, then the pattern is midipix*. > > I'm committing this patch. This handles all references to musl > in m4/, except for > Awesome! Thank you very much:-) Once the remaining few tests pass natively I'll submit another patch. from the list below, I know realpath, chmod, d-ino, mkdir, sleep and usleep are already correct. > m4/canonicalize.m4:164: -musl) gl_cv_func_realpath_works="guessing nearly" ;; > m4/chmod.m4:65: -gnu | gnu | -musl | darwin* | freebsd* | midnightbsd* | > netbsd* | openbsd* | solaris* | haiku* | cygwin*) > m4/chown.m4:117: -musl) gl_cv_func_chown_slash_works="guessing yes" ;; > m4/chown.m4:156: -musl) gl_cv_func_chown_ctime_works="guessing yes" ;; > m4/d-ino.m4:46: linux*-musl*) gl_cv_struct_dirent_d_ino="guessing yes" ;; > m4/futimens.m4:56: -musl) gl_cv_func_futimens_works="guessing no" ;; > m4/getcwd.m4:55: -musl) gl_cv_func_getcwd_null="guessing yes";; > m4/getgroups.m4:44: -musl) ac_cv_func_getgroups_works="guessing yes" ;; > m4/getgroups.m4:98: -musl) gl_cv_func_getgroups_works="guessing yes" ;; > m4/link-follow.m4:92: linux*-musl*) gl_cv_func_link_follows_symlink="guessing > no" ;; > m4/mkdir.m4:69: -musl) gl_cv_func_mkdir_trailing_dot_works="guessing yes" ;; > m4/ptsname.m4:34: -musl) gl_cv_func_ptsname_sets_errno="guessing yes" ;; > m4/sleep.m4:52: -musl) gl_cv_func_sleep_works="guessing yes" ;; > m4/usleep.m4:35: -musl) gl_cv_func_usleep_works="guessing yes" ;; > m4/utimes.m4:148: -musl) gl_cv_func_working_utimes="guessing yes" ;; > > > 2023-02-17 Bruno Haible br...@clisp.org > > > Improve cross-compilation from midipix. > Reported by Ørjan Malde r...@foxi.me at > > https://lists.gnu.org/archive/html/bug-gnulib/2023-02/msg00131.html. > > Since midipix consists of musl libc based on an emulation of Linux system > calls, for pure libc functionality it can be treated like musl libc. > * m4/calloc.m4 (_AC_FUNC_CALLOC_IF): Treat midipix like systems with > musl libc. > * m4/cbrtl.m4 (gl_FUNC_CBRTL): Likewise. > * m4/ceil.m4 (gl_FUNC_CEIL): Likewise. > * m4/ceilf.m4 (gl_FUNC_CEILF): Likewise. > * m4/ceill.m4 (gl_FUNC_CEILL): Likewise. > * m4/exp2l.m4 (gl_FUNC_EXP2L): Likewise. > * m4/expl.m4 (gl_FUNC_EXPL): Likewise. > * m4/expm1.m4 (gl_FUNC_EXPM1): Likewise. > * m4/expm1f.m4 (gl_FUNC_EXPM1F): Likewise. > * m4/expm1l.m4 (gl_FUNC_EXPM1L): Likewise. > * m4/fclose.m4 (gl_FUNC_FCLOSE_STDIN): Likewise. > * m4/fdopendir.m4 (gl_FUNC_FDOPENDIR): Likewise. > * m4/ffsll.m4 (gl_FUNC_FFSLL): Likewise. > * m4/floor.m4 (gl_FUNC_FLOOR): Likewise. > * m4/floorf.m4 (gl_FUNC_FLOORF): Likewise. > * m4/fmod.m4 (gl_FUNC_FMOD): Likewise. > * m4/fmodf.m4 (gl_FUNC_FMODF): Likewise. > * m4/fmodl.m4 (gl_FUNC_FMODL): Likewise. > * m4/fnmatch.m4 (gl_FUNC_FNMATCH_POSIX): Likewise. > * m4/fopen.m4 (gl_FUNC_FOPEN_GNU): Likewise. > * m4/fpurge.m4 (gl_FUNC_FPURGE): Likewise. > * m4/getdelim.m4 (gl_FUNC_GETDELIM): Likewise. > * m4/getline.m4 (gl_FUNC_GETLINE): Likewise. > * m4/hypot.m4 (gl_FUNC_HYPOT): Likewise. > * m4/hypotf.m4 (gl_FUNC_HYPOTF): Likewise. > * m4/hypotl.m4 (gl_FUNC_HYPOTL): Likewise. > * m4/iconv_open-utf.m4 (gl_FUNC_ICONV_OPEN_UTF_SUPPORT): Likewise. > * m4/log.m4 (gl_FUNC_LOG): Likewise. > * m4/log10.m4 (gl_FUNC_LOG10): Likewise. > * m4/log10f.m4 (gl_FUNC_LOG10F): Likewise. > * m4/log10l.m4 (gl_FUNC_LOG10L_WORKS): Likewise. > * m4/log1p.m4 (gl_FUNC_LOG1P): Likewise. > * m4/log1pf.m4 (gl_FUNC_LOG1PF): Likewise. > * m4/log1pl.m4 (gl_FUNC_LOG1PL, gl_FUNC_LOG1PL_WORKS): Likewise. > * m4/log2.m4 (gl_FUNC_LOG2): Likewise. > * m4/log2f.m4 (gl_FUNC_LOG2F): Likewise. > * m4/log2l.m4 (gl_FUNC_LOG2L_WORKS): Likewise. > * m4/logf.m4 (gl_FUNC_LOGF): Likewise. > * m4/logl.m4 (gl_FUNC_LOGL_WORKS): Likewise. > * m4/malloc.m4 (_AC_FUNC_MALLOC_IF): Likewise. > * m4/mkstemp.m4 (gl_FUNC_MKSTEMP): Likewise. > * m4/modf.m4 (gl_FUNC_MODF): Likewise. > * m4/modff.m4 (gl_FUNC_MODFF): Likewise. > * m4/modfl.m4 (gl_FUNC_MODFL): Likewise. > * m4/musl.m4 (gl_MUSL_LIBC): Likewise. > * m4/perror.m4 (gl_FUNC_PERROR): Likewise. > * m4/posix_spawn.m4 (gl_POSIX_SPAWN_SECURE, > gl_FUNC_POSIX_SPAWN_FILE_ACTIONS_ADDCLOSE, > gl_FUNC_POSIX_SPAWN_FILE_ACTIONS_ADDDUP2, > gl_FUNC_POSIX_SPAWN_FILE_ACTIONS_ADDOPEN): Li
expl: Document musl libc bug
expl lacks precision musl libc 1.2.2/arm64, musl libc 1.2.2/s390x.
Fortunately the configure test meant for NetBSD already catches it.
2021-01-31 Bruno Haible
expl: Document musl libc bug.
* doc/posix-functions/expl.texi: Document musl libc bug.
* m4/expl.m4 (gl_FUNC_EXPL): Update comment and cross
compilation guess.
diff --git a/doc/posix-functions/expl.texi b/doc/posix-functions/expl.texi
index d0810b2..f70589f 100644
--- a/doc/posix-functions/expl.texi
+++ b/doc/posix-functions/expl.texi
@@ -23,7 +23,7 @@ MSVC 14.
@item
This function produces results which are accurate to only 16 digits on some
platforms:
-NetBSD 9.0.
+musl libc 1.2.2/arm64, musl libc 1.2.2/s390x, NetBSD 9.0.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/m4/expl.m4 b/m4/expl.m4
index 0ed62ab..9e7bfa7 100644
--- a/m4/expl.m4
+++ b/m4/expl.m4
@@ -1,4 +1,4 @@
-# expl.m4 serial 17
+# expl.m4 serial 18
dnl Copyright (C) 2010-2021 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -129,7 +129,7 @@ int main (int argc, char *argv[])
if (isnan (expl (x1)) || isnan (expl (x2)) || isnan (expl (x3)))
result |= 2;
}
- /* This test fails on NetBSD 9.0. */
+ /* This test fails on musl 1.2.2/arm64, musl 1.2.2/s390x, NetBSD 9.0. */
{
const long double TWO_LDBL_MANT_DIG = /* 2^LDBL_MANT_DIG */
(long double) (1U << ((LDBL_MANT_DIG - 1) / 5))
@@ -150,8 +150,8 @@ int main (int argc, char *argv[])
[case "$host_os" in
# Guess yes on glibc systems.
*-gnu* | gnu*) gl_cv_func_expl_works="guessing yes" ;;
- # Guess yes on musl systems.
- *-musl*) gl_cv_func_expl_works="guessing yes" ;;
+ # Guess no on musl systems.
+ *-musl*) gl_cv_func_expl_works="guessing no" ;;
# Guess yes on native Windows.
mingw*)gl_cv_func_expl_works="guessing yes" ;;
# If we don't know, obey --enable-cross-guesses.
expm1l: Document musl libc bug
expm1l lacks precision on musl libc 1.2.2/arm64, musl libc 1.2.2/s390x.
Fortunately the configure test meant for Mac OS X and NetBSD already catches it.
2021-01-31 Bruno Haible
expm1l: Document musl libc bug.
* doc/posix-functions/expm1l.texi: Document musl libc bug.
* m4/expm1l.m4 (gl_FUNC_EXPM1L): Update comment and cross
compilation guess.
diff --git a/doc/posix-functions/expm1l.texi b/doc/posix-functions/expm1l.texi
index 4cd58a8..059d5fc 100644
--- a/doc/posix-functions/expm1l.texi
+++ b/doc/posix-functions/expm1l.texi
@@ -17,7 +17,7 @@ IRIX 6.5.
@item
This function produces results which are accurate to only 16 digits on some
platforms:
-Mac OS X 10.5, NetBSD 8.0.
+musl libc 1.2.2/arm64, musl libc 1.2.2/s390x, Mac OS X 10.5, NetBSD 8.0.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/m4/expm1l.m4 b/m4/expm1l.m4
index 8fe31b5..ec0d907 100644
--- a/m4/expm1l.m4
+++ b/m4/expm1l.m4
@@ -1,4 +1,4 @@
-# expm1l.m4 serial 8
+# expm1l.m4 serial 9
dnl Copyright (C) 2010-2021 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -123,7 +123,8 @@ int main (int argc, char *argv[])
{
long double (* volatile my_expm1l) (long double) = argc ? expm1l : dummy;
int result = 0;
- /* This test fails on Mac OS X 10.5, NetBSD 8.0. */
+ /* This test fails on musl 1.2.2/arm64, musl 1.2.2/s390x, Mac OS X 10.5,
+ NetBSD 8.0. */
{
const long double TWO_LDBL_MANT_DIG = /* 2^LDBL_MANT_DIG */
(long double) (1U << ((LDBL_MANT_DIG - 1) / 5))
@@ -147,8 +148,8 @@ int main (int argc, char *argv[])
[case "$host_os" in
# Guess yes on glibc systems.
*-gnu* | gnu*) gl_cv_func_expm1l_works="guessing yes" ;;
- # Guess yes on musl systems.
- *-musl*) gl_cv_func_expm1l_works="guessing yes" ;;
+ # Guess no on musl systems.
+ *-musl*) gl_cv_func_expm1l_works="guessing no" ;;
# Guess yes on native Windows.
mingw*)gl_cv_func_expm1l_works="guessing yes" ;;
# If we don't know, obey --enable-cross-guesses.
logl: Document musl libc bug
logl lacks precision on musl libc 1.2.2/arm64, musl libc 1.2.2/s390x.
Fortunately the configure test meant for NetBSD already catches it.
2021-01-31 Bruno Haible
logl: Document musl libc bug.
* doc/posix-functions/logl.texi: Document musl libc bug.
* m4/logl.m4 (gl_FUNC_LOGL_WORKS): Update comment and cross
compilation guess.
diff --git a/doc/posix-functions/logl.texi b/doc/posix-functions/logl.texi
index 1e7918b..e0d04b5 100644
--- a/doc/posix-functions/logl.texi
+++ b/doc/posix-functions/logl.texi
@@ -20,7 +20,7 @@ glibc 2.7 on Linux/SPARC64.
@item
This function produces results which are accurate to only 16 digits on some
platforms:
-NetBSD 9.0.
+musl libc 1.2.2/arm64, musl libc 1.2.2/s390x, NetBSD 9.0.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/m4/logl.m4 b/m4/logl.m4
index 128170a..7dcdac1 100644
--- a/m4/logl.m4
+++ b/m4/logl.m4
@@ -1,4 +1,4 @@
-# logl.m4 serial 14
+# logl.m4 serial 15
dnl Copyright (C) 2010-2021 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -166,7 +166,7 @@ int main (int argc, char *argv[])
if (!(gy + gy == gy))
result |= 1;
}
- /* This test fails on NetBSD 9.0. */
+ /* This test fails on musl 1.2.2/arm64, musl 1.2.2/s390x, NetBSD 9.0. */
{
const long double TWO_LDBL_MANT_DIG = /* 2^LDBL_MANT_DIG */
(long double) (1U << ((LDBL_MANT_DIG - 1) / 5))
@@ -188,8 +188,8 @@ int main (int argc, char *argv[])
[case "$host_os" in
# Guess yes on glibc systems.
*-gnu* | gnu*) gl_cv_func_logl_works="guessing yes" ;;
- # Guess yes on musl systems.
- *-musl*) gl_cv_func_logl_works="guessing yes" ;;
+ # Guess no on musl systems.
+ *-musl*) gl_cv_func_logl_works="guessing no" ;;
# Guess yes on native Windows.
mingw*)gl_cv_func_logl_works="guessing yes" ;;
# If we don't know, obey --enable-cross-guesses.
log10l: Document musl libc bug
log10l lacks precision on musl libc 1.2.2/arm64, musl libc 1.2.2/s390x.
Fortunately the configure test meant for NetBSD already catches it.
2021-01-31 Bruno Haible
log10l: Document musl libc bug.
* doc/posix-functions/log10l.texi: Document musl libc bug.
* m4/log10l.m4 (gl_FUNC_LOG10L_WORKS): Update comment and cross
compilation guess.
diff --git a/doc/posix-functions/log10l.texi b/doc/posix-functions/log10l.texi
index 7dd6f49..ffddbcb 100644
--- a/doc/posix-functions/log10l.texi
+++ b/doc/posix-functions/log10l.texi
@@ -26,7 +26,7 @@ IRIX 6.5.
@item
This function produces results which are accurate to only 16 digits on some
platforms:
-NetBSD 9.0.
+musl libc 1.2.2/arm64, musl libc 1.2.2/s390x, NetBSD 9.0.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/m4/log10l.m4 b/m4/log10l.m4
index c594f6b..57aa1ba 100644
--- a/m4/log10l.m4
+++ b/m4/log10l.m4
@@ -1,4 +1,4 @@
-# log10l.m4 serial 9
+# log10l.m4 serial 10
dnl Copyright (C) 2011-2021 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -126,7 +126,7 @@ int main (int argc, char *argv[])
if (!(gy + gy == gy))
result |= 1;
}
- /* This test fails on NetBSD 9.0. */
+ /* This test fails on musl 1.2.2/arm64, musl 1.2.2/s390x, NetBSD 9.0. */
{
const long double TWO_LDBL_MANT_DIG = /* 2^LDBL_MANT_DIG */
(long double) (1U << ((LDBL_MANT_DIG - 1) / 5))
@@ -147,8 +147,8 @@ int main (int argc, char *argv[])
[case "$host_os" in
# Guess yes on glibc systems.
*-gnu* | gnu*) gl_cv_func_log10l_works="guessing yes" ;;
- # Guess yes on musl systems.
- *-musl*) gl_cv_func_log10l_works="guessing yes" ;;
+ # Guess no on musl systems.
+ *-musl*) gl_cv_func_log10l_works="guessing no" ;;
# Guess yes on native Windows.
mingw*)gl_cv_func_log10l_works="guessing yes" ;;
# If we don't know, obey --enable-cross-guesses.
Re: While cross compiling, assume the gcc signbit support for the musl as well
>From 56482aa68e71f2ef17ef42163023d78b3ffd35e8 Mon Sep 17 00:00:00 2001 From: Necktwi Ozfghua Date: Sat, 16 Mar 2019 22:34:17 +0530 Subject: [PATCH] m4/signbit.m4: signbit support is assumed with musl while cross building, signbit support is assumed with glibc so should be with musl. Signed-off-by: Necktwi Ozfghua --- m4/signbit.m4 | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/m4/signbit.m4 b/m4/signbit.m4 index bf5bce594..2aefb2598 100644 --- a/m4/signbit.m4 +++ b/m4/signbit.m4 @@ -30,7 +30,9 @@ AC_DEFUN([gl_SIGNBIT], [gl_cv_func_signbit=no], [case "$host_os" in # Guess yes on glibc systems. - *-gnu* | gnu*) gl_cv_func_signbit="guessing yes" ;; + *-gnu* | gnu*\ + | *musl* |\ + musl* | *musl) gl_cv_func_signbit="guessing yes" ;; # Guess yes on native Windows. mingw*)gl_cv_func_signbit="guessing yes" ;; # If we don't know, assume the worst. @@ -61,7 +63,9 @@ AC_DEFUN([gl_SIGNBIT], [gl_cv_func_signbit_gcc=no], [case "$host_os" in # Guess yes on glibc systems. - *-gnu* | gnu*) gl_cv_func_signbit_gcc="guessing yes" ;; + *-gnu* | gnu*\ + | *musl* |\ + *musl | musl*) gl_cv_func_signbit_gcc="guessing yes" ;; # Guess yes on mingw, no on MSVC. mingw*)if test -n "$GCC"; then gl_cv_func_signbit_gcc="guessing yes"
Re: Android NDK r26 and utmpx
Hi Po Lu,
> utmpx.h is provided by this new release of the Android NDK, defining
> functions as nonfunctional as utmp.h does.
So, HAVE_UTMPX_H now is 1.
And utmpname exists but utmpxname does not exist. Therefore UTMP_NAME_FUNCTION
is no longer defined.
> The more pressing problem is that its presence suppresses the definition
> of UTMP_NAME_FUNCTION when a program is built with an __ANDROID_API__
> lower than 34, where the utmpx* series of functions were introduced,
> because the conditional for HAVE_UTMPX_H in readutmp.h does not search
> for a `utmpname' function if `utmpxname' is unavailable, with the result
> that get_android_boot_time is never invoked. Here are the relevant
> portions of config.log:
>
> configure:9462: checking for utmpx.h
> configure:9462:
> /opt/android/ndk/android-ndk-r26/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android22-clang
> -c -O2 -g3 -Werror=implicit-function-declaration conftest.c >&5
> configure:9462: $? = 0
> configure:9462: result: yes
>
> configure:16416:
> /opt/android/ndk/android-ndk-r26/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android22-clang
> -o conftest -O2 -g3 -Werror=implicit-function-declaration conftest.c
> >&5
> ld.lld: error: undefined symbol: utmpxname
> >>> referenced by conftest.c:116
> >>> /tmp/conftest-c4f4cf.o:(main)
> >>> did you mean: utmpname
> >>> defined in:
> >>> /opt/android/ndk/android-ndk-r26/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/lib/aarch64-linux-android/22/libc.so
>
> I will install a workaround in Emacs, but it ought to be fixed at the
> source.
This patch should fix it, in the simplest possible way. Committing it.
2024-01-21 Bruno Haible
readutmp, boot-time: Port to Android NDK r26.
Reported by Po Lu in
<https://lists.gnu.org/archive/html/bug-gnulib/2024-01/msg00063.html>.
* lib/readutmp.h: Update comments.
(UTMP_NAME_FUNCTION): Define as a no-op for Android with HAVE_UTMPX_H.
diff --git a/lib/readutmp.h b/lib/readutmp.h
index b62eb3beaa..dcfd44dbbc 100644
--- a/lib/readutmp.h
+++ b/lib/readutmp.h
@@ -114,21 +114,21 @@ enum { UT_HOST_SIZE = -1 };
FieldType Platforms
-- -- -
- ⎡ ut_user char[] glibc, musl, macOS, FreeBSD, AIX,
HP-UX, IRIX, Solaris, Cygwin
+ ⎡ ut_user char[] glibc, musl, macOS, FreeBSD, AIX,
HP-UX, IRIX, Solaris, Cygwin, Android
⎣ ut_name char[] NetBSD, Minix
- ut_id char[] glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin
- ut_line char[] glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin
- ut_pid pid_t glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin
- ut_type short glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin
- ⎡ ut_tv struct glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin
+ ut_idchar[] glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin, Android
+ ut_line char[] glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin, Android
+ ut_pid pid_t glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin, Android
+ ut_type short glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin, Android
+ ⎡ ut_tvstruct glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin, Android
⎢ { tv_sec; tv_usec; }
⎣ ut_time time_t Cygwin
- ut_host char[] glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin
- ut_exit struct glibc, musl, NetBSD, Minix,
HP-UX, IRIX, Solaris
+ ut_host char[] glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin, Android
+ ut_exit struct glibc, musl, NetBSD, Minix,
HP-UX, IRIX, Solaris, Android
{ e_termination; e_exit; }
- ut_session [long] int glibc, musl, NetBSD, Minix, IRIX,
Solaris
+ ut_session [long] int glibc, musl, NetBSD, Minix, IRIX,
Solaris, Android
⎡ ut_addr [long] int HP-UX, Cygwin
- ⎢ ut_addr_v6 [u]int[4] glibc, musl
+ ⎢ ut_addr_v6 [u]int[4]
[PATCH] Add cross-compilation guesses for Midipix
* m4/calloc.m4: When cross-compiling, use the result from native compilation. * m4/canonicalize.m4: Likewise. * m4/cbrtl.m4: Likewise. * m4/ceil.m4: Likewise. * m4/ceilf.m4: Likewise. * m4/ceill.m4: Likewise. * m4/chmod.m4: Likewise. * m4/d-ino.m4: Likewise. * m4/exp2l.m4: Likewise. * m4/expm1.m4: Likewise. * m4/expm1f.m4: Likewise. * m4/fchdir.m4: Likewise. * m4/fclose.m4: Likewise. * m4/fdopendir.m4: Likewise. * m4/ffsll.m4: Likewise. * m4/floor.m4: Likewise. * m4/floorf.m4: Likewise. * m4/fmod.m4: Likewise. * m4/fmodf.m4: Likewise. * m4/fmodl.m4: Likewise. * m4/fopen.m4: Likewise. * m4/fpurge.m4: Likewise. * m4/getcwd.m4: Likewise. * m4/getdelim.m4: Likewise. * m4/getline.m4: Likewise. * m4/hypot.m4: Likewise. * m4/hypotf.m4: Likewise. * m4/hypotl.m4: Likewise. * m4/iconv_open-utf.m4: Likewise. * m4/link.m4: Likewise. * m4/linkat.m4: Likewise. * m4/log.m4: Likewise. * m4/log10.m4: Likewise. * m4/log10f.m4: Likewise. * m4/log1p.m4: Likewise. * m4/log1pf.m4: Likewise. * m4/log1pl.m4: Likewise. * m4/log2.m4: Likewise. * m4/log2f.m4: Likewise. * m4/logf.m4: Likewise. * m4/lstat.m4: Likewise. * m4/malloc.m4: Likewise. * m4/mkdir.m4: Likewise. * m4/mkstemp.m4: Likewise. * m4/modf.m4: Likewise. * m4/modff.m4: Likewise. * m4/modfl.m4: Likewise. * m4/perror.m4: Likewise. * m4/printf.m4: Likewise. * m4/pselect.m4: Likewise. * m4/ptsname.m4: Likewise. * m4/putenv.m4: Likewise. * m4/readlink.m4: Likewise. * m4/realloc.m4: Likewise. * m4/remainder.m4: Likewise. * m4/remainderf.m4: Likewise. * m4/remainderl.m4: Likewise. * m4/rename.m4: Likewise. * m4/rintl.m4: Likewise. * m4/rmdir.m4: Likewise. * m4/round.m4: Likewise. * m4/roundf.m4: Likewise. * m4/roundl.m4: Likewise. * m4/select.m4: Likewise. * m4/setenv.m4: Likewise. * m4/sleep.m4: Likewise. * m4/stat.m4: Likewise. * m4/stpncpy.m4: Likewise. * m4/strerror.m4: Likewise. * m4/strtod.m4: Likewise. * m4/strtold.m4: Likewise. * m4/symlink.m4: Likewise. * m4/symlinkat.m4: Likewise. * m4/trunc.m4: Likewise. * m4/truncf.m4: Likewise. * m4/truncl.m4: Likewise. * m4/ungetc.m4: Likewise. * m4/unlink.m4: Likewise. * m4/usleep.m4: Likewise. * m4/wcwidth.m4: Likewise. --- m4/calloc.m4 | 2 ++ m4/canonicalize.m4 | 2 ++ m4/cbrtl.m4 | 2 ++ m4/ceil.m4 | 2 ++ m4/ceilf.m4 | 2 ++ m4/ceill.m4 | 2 ++ m4/chmod.m4 | 4 ++-- m4/d-ino.m4 | 2 ++ m4/exp2l.m4 | 4 m4/expm1.m4 | 2 ++ m4/expm1f.m4 | 2 ++ m4/fchdir.m4 | 2 ++ m4/fclose.m4 | 2 ++ m4/fdopendir.m4 | 14 -- m4/ffsll.m4 | 2 ++ m4/floor.m4 | 2 ++ m4/floorf.m4 | 2 ++ m4/fmod.m4 | 2 ++ m4/fmodf.m4 | 2 ++ m4/fmodl.m4 | 2 ++ m4/fopen.m4 | 4 ++-- m4/fpurge.m4 | 10 ++ m4/getcwd.m4 | 2 ++ m4/getdelim.m4 | 5 +++-- m4/getline.m4| 5 +++-- m4/hypot.m4 | 2 ++ m4/hypotf.m4 | 2 ++ m4/hypotl.m4 | 2 ++ m4/iconv_open-utf.m4 | 1 + m4/link.m4 | 2 ++ m4/linkat.m4 | 2 ++ m4/log.m4| 2 ++ m4/log10.m4 | 2 ++ m4/log10f.m4 | 2 ++ m4/log1p.m4 | 2 ++ m4/log1pf.m4 | 2 ++ m4/log1pl.m4 | 2 ++ m4/log2.m4 | 2 ++ m4/log2f.m4 | 2 ++ m4/logf.m4 | 2 ++ m4/lstat.m4 | 3 +++ m4/malloc.m4 | 2 +- m4/mkdir.m4 | 4 m4/mkstemp.m4| 2 ++ m4/modf.m4 | 2 ++ m4/modff.m4 | 2 ++ m4/modfl.m4 | 2 ++ m4/perror.m4 | 14 -- m4/printf.m4 | 20 m4/pselect.m4| 2 ++ m4/ptsname.m4| 2 ++ m4/putenv.m4 | 2 ++ m4/readlink.m4 | 6 ++ m4/realloc.m4| 2 +- m4/remainder.m4 | 2 ++ m4/remainderf.m4 | 2 ++ m4/remainderl.m4 | 2 ++ m4/rename.m4 | 6 ++ m4/rintl.m4 | 2 ++ m4/rmdir.m4 | 2 ++ m4/round.m4 | 2 ++ m4/roundf.m4 | 2 ++ m4/roundl.m4 | 2 ++ m4/select.m4 | 2 ++ m4/setenv.m4 | 12 m4/sleep.m4 | 2 ++ m4/stat.m4 | 2 ++ m4/stpncpy.m4| 5 +++-- m4/strerror.m4 | 4 m4/strtod.m4 | 12 +++- m4/strtold.m4| 12 +++- m4/symlink.m4| 2 ++ m4/symlinkat.m4 | 2 ++ m4/trunc.m4 | 2 ++ m4/truncf.m4 | 2 ++ m4/truncl.m4 | 2 ++ m4/ungetc.m4 | 2 ++ m4/unlink.m4 | 2 ++ m4/usleep.m4 | 2 ++ m4/wcwidth.m4| 2 ++ 80 files changed, 225 insertions(+), 42 deletions(-) diff --git a/m4/calloc.m4 b/m4/calloc.m4 index 23c0dd9f3f..c63edcc47c 100644 --- a/m4/calloc.m4 +++ b/m4/calloc.m4 @@ -40,6 +40,8 @@ AC_DEFUN([_AC_FUNC_CALLOC_IF], *-gnu* | gnu*) ac_cv_func_calloc_0_nonnull="guessing yes" ;; # Guess yes on mu
Re: localename: add support for musl libc
Hello Bruno, On Sat, Feb 24, 2018 at 01:01:07PM +0100, Bruno Haible wrote: > On Alpine Linux 3.7.0, which uses musl libc, I see this test failure: [...] > diff --git a/lib/localename.c b/lib/localename.c > index 2133cbc..74c8ee0 100644 > --- a/lib/localename.c > +++ b/lib/localename.c > @@ -40,7 +40,7 @@ > # if defined __APPLE__ && defined __MACH__ > # include > # endif > -# if (__GLIBC__ >= 2 && !defined __UCLIBC__) || defined __CYGWIN__ > +# if (__GLIBC__ >= 2 && !defined __UCLIBC__) || (defined __linux__ && > HAVE_LANGINFO_H) || defined __CYGWIN__ > # include > # endif > # if !defined IN_LIBINTL > @@ -2703,6 +2703,9 @@ gl_locale_name_thread_unsafe (int category, const char > *categoryname) > nl_langinfo (_NL_LOCALE_NAME (category)). */ >name = thread_locale->__names[category]; > return name; > +# elif defined __linux__ && HAVE_LANGINFO_H && defined NL_LOCALE_NAME > +/* musl libc */ > +return nl_langinfo_l (NL_LOCALE_NAME (category), thread_locale); A tiny comment about the comment :) You wrote "musl libc", but what the "elif defined ..." is something like "linux but not glibc, with langinfo.h" - which could (in theory) be something other than musl-libc. Specifically, musl people purposefully object to adding any kind of preprocessor #define value that would enable detection of musl: http://www.openwall.com/lists/musl/2013/02/08/9 And in a sense, this is exactly what we're detecting here. Perhaps it's worth expanding the comment to say "glibc not detected, assuming this is musl libc" ? regards, -assaf
Re: gnulib does not always detect need for iconv() hack on musl
Hello Sergei, Sergei Trofimovich wrote: > The following fails bison-3.8.2 tests: > $ ./configure && make && make check > The following succeeds: > $ ./configure --host=x86_64-unknown-linux-musl && make && make check > > The failure happens due to unexpected '*' output in report logs instead > of '%empty' on 'ASCII' locales. > > These unexpected '*' pop back again because gnulib relies on '--host=' > parameter for './configure' to detect musl target (for lack of better > signal?): > > https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/musl.m4#n16 > > case "$host_os" in > *-musl*) AC_DEFINE([MUSL_LIBC], [1], [Define to 1 on musl libc.]) ;; > > https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/unicodeio.c#n151 > > /* FreeBSD iconv(), NetBSD iconv(), and Solaris 11 iconv() insert >a '?' if they cannot convert. */ > # if !defined _LIBICONV_VERSION > || (res > 0 && outptr - outbuf == 1 && *outbuf == '?') > # endif > /* musl libc iconv() inserts a '*' if it cannot convert. */ > # if !defined _LIBICONV_VERSION && MUSL_LIBC > || (res > 0 && outptr - outbuf == 1 && *outbuf == '*') > # endif > ) > return failure (code, NULL, callback_arg); > > What do you think of enabling the workaround regardless of MUSL_LIBC > define? The MUSL_LIBC symbol is supposed to be set on musl platforms; this is what musl.m4 is for. The difference between your two invocations is that in the first case, it used a $host triple inferred by config.guess, while in the second case, it used the $host that you specified on the command line. When I try your two commands (just the configure step), the first one prints checking for host system type... x86_64-pc-linux-musl while the second one prints checking for host system type... x86_64-unknown-linux-musl The next steps of the investigation are: In the first case, - What did the "checking for host system type..." line look like? - Which of the environment variables CC_FOR_BUILD, HOST_CC, CC, CONFIG_SITE did you have defined, and to which values? > Or perhaps gnulib should perform runtime testing to detect the need for > a hack? Here is how musl mangles symbols: > > https://git.musl-libc.org/cgit/musl/tree/src/locale/iconv.c#n545 > > case US_ASCII: > if (c > 0x7f) subst: x++, c='*'; > > Below implements unconditional workaround. Thanks for the suggestion. But we try to limit the performance implications of hacks/workarounds needed for one platform (here: musl) on other platforms (especially glibc platforms). Bruno
hard-locale tests: make it easy to reuse the musl test
Some other tests may need to conditionalize on musl libc, in the future. 2020-01-25 Bruno Haible hard-locale tests: Make it easy to reuse the musl test. * m4/musl.m4: New file, extracted from modules/hard-locale-tests. * modules/hard-locale-tests (Files): Add it. (configure.ac): Invoke gl_MUSL_LIBC. diff --git a/m4/musl.m4 b/m4/musl.m4 new file mode 100644 index 000..252054c --- /dev/null +++ b/m4/musl.m4 @@ -0,0 +1,18 @@ +# musl.m4 serial 1 +dnl Copyright (C) 2019-2020 Free Software Foundation, Inc. +dnl This file is free software; the Free Software Foundation +dnl gives unlimited permission to copy and/or distribute it, +dnl with or without modifications, as long as this notice is preserved. + +# Test for musl libc, despite the musl libc authors don't like it +# <https://wiki.musl-libc.org/faq.html> +# <https://lists.gnu.org/archive/html/bug-gnulib/2018-02/msg00079.html>. +# From Bruno Haible. + +AC_DEFUN_ONCE([gl_MUSL_LIBC], +[ + AC_REQUIRE([AC_CANONICAL_HOST]) + case "$host_os" in +*-musl*) AC_DEFINE([MUSL_LIBC], [1], [Define to 1 on musl libc.]) ;; + esac +]) diff --git a/modules/hard-locale-tests b/modules/hard-locale-tests index ac7fcb2..7ed8575 100644 --- a/modules/hard-locale-tests +++ b/modules/hard-locale-tests @@ -1,14 +1,12 @@ Files: tests/test-hard-locale.c tests/locale.c +m4/musl.m4 Depends-on: configure.ac: -AC_REQUIRE([AC_CANONICAL_HOST]) -case "$host_os" in - *-musl*) AC_DEFINE([MUSL_LIBC], [1], [Define to 1 on musl libc.]) ;; -esac +gl_MUSL_LIBC dnl Distinguish OpenBSD >= 6.2 from OpenBSD < 6.2. AC_CHECK_FUNCS_ONCE([duplocale])
gnulib does not always detect need for iconv() hack on musl
Hi gnulib! The problem: The following fails bison-3.8.2 tests: $ ./configure && make && make check The following succeeds: $ ./configure --host=x86_64-unknown-linux-musl && make && make check The failure happens due to unexpected '*' output in report logs instead of '%empty' on 'ASCII' locales. These unexpected '*' pop back again because gnulib relies on '--host=' parameter for './configure' to detect musl target (for lack of better signal?): https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/musl.m4#n16 case "$host_os" in *-musl*) AC_DEFINE([MUSL_LIBC], [1], [Define to 1 on musl libc.]) ;; https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/unicodeio.c#n151 /* FreeBSD iconv(), NetBSD iconv(), and Solaris 11 iconv() insert a '?' if they cannot convert. */ # if !defined _LIBICONV_VERSION || (res > 0 && outptr - outbuf == 1 && *outbuf == '?') # endif /* musl libc iconv() inserts a '*' if it cannot convert. */ # if !defined _LIBICONV_VERSION && MUSL_LIBC || (res > 0 && outptr - outbuf == 1 && *outbuf == '*') # endif ) return failure (code, NULL, callback_arg); What do you think of enabling the workaround regardless of MUSL_LIBC define? Or perhaps gnulib should perform runtime testing to detect the need for a hack? Here is how musl mangles symbols: https://git.musl-libc.org/cgit/musl/tree/src/locale/iconv.c#n545 case US_ASCII: if (c > 0x7f) subst: x++, c='*'; Below implements unconditional workaround. Thank you! --- a/lib/unicodeio.c +++ b/lib/unicodeio.c @@ -148,7 +148,7 @@ unicode_to_mb (unsigned int code, || (res > 0 && outptr - outbuf == 1 && *outbuf == '?') # endif /* musl libc iconv() inserts a '*' if it cannot convert. */ -# if !defined _LIBICONV_VERSION && MUSL_LIBC +# if !defined _LIBICONV_VERSION || (res > 0 && outptr - outbuf == 1 && *outbuf == '*') # endif )
Re: While cross compiling, assume the gcc signbit support for the musl as well
Hi, > while cross building, signbit support is assumed with glibc > so should be with musl. You are right that gnulib should care about cross-compilation to musl systems. Reason: It's one of the main options when using 'buildroot', see https://buildroot.org/downloads/manual/manual.html#_cross_compilation_toolchain (Btw, I like buildroot: it allowed me to create a self-hosting riscv32 environment, while I couldn't find a working VM image for download.) But several things are suboptimal with your patch: - You cannot just assume that musl libc works like glibc. These implementations have no code in common. - Case clauses like | *musl* | musl* | *musl are redundant. - The starting point must be to determine the "$host_os" value. It is 'linux-musl', but one should be prepared to see version numbers in there, such as linux5.0-musl1.0. - It's best to handle all modules at once, not just one. Create a testdir with the relevant modules (all modules that contain a .m4 files that has an AC_RUN_IFELSE invocation), and run this testdir on a system which has a musl libc. I'm using an Alpine Linux 3.7 system for this purpose. I'm committing this patch as the result. 2019-03-23 Bruno Haible Support cross-compilation to musl libc. Reported by Necktwi Ozfguah . * m4/calloc.m4 (_AC_FUNC_CALLOC_IF): Add cross-compilation guesses for musl libc. * m4/canonicalize.m4 (gl_FUNC_REALPATH_WORKS): Likewise. * m4/cbrtl.m4 (gl_FUNC_CBRTL): Likewise. * m4/ceil.m4 (gl_FUNC_CEIL): Likewise. * m4/ceilf.m4 (gl_FUNC_CEILF): Likewise. * m4/ceill.m4 (gl_FUNC_CEILL): Likewise. * m4/chown.m4 (gl_FUNC_CHOWN): Likewise. * m4/d-ino.m4 (gl_CHECK_TYPE_STRUCT_DIRENT_D_INO): Likewise. * m4/exp2l.m4 (gl_FUNC_EXP2L): Likewise. * m4/expl.m4 (gl_FUNC_EXPL): Likewise. * m4/expm1.m4 (gl_FUNC_EXPM1): Likewise. * m4/expm1l.m4 (gl_FUNC_EXPM1L): Likewise. * m4/fdopendir.m4 (gl_FUNC_FDOPENDIR): Likewise. * m4/floor.m4 (gl_FUNC_FLOOR): Likewise. * m4/floorf.m4 (gl_FUNC_FLOORF): Likewise. * m4/fmod.m4 (gl_FUNC_FMOD): Likewise. * m4/fmodf.m4 (gl_FUNC_FMODF): Likewise. * m4/fmodl.m4 (gl_FUNC_FMODL): Likewise. * m4/fnmatch.m4 (gl_FUNC_FNMATCH_POSIX): Likewise. * m4/fpurge.m4 (gl_FUNC_FPURGE): Likewise. * m4/getcwd.m4 (gl_FUNC_GETCWD_NULL): Likewise. * m4/getcwd-abort-bug.m4 (gl_FUNC_GETCWD_ABORT_BUG): Likewise. * m4/getdelim.m4 (gl_FUNC_GETDELIM): Likewise. * m4/getgroups.m4 (AC_FUNC_GETGROUPS, gl_FUNC_GETGROUPS): Likewise. * m4/getline.m4 (gl_FUNC_GETLINE): Likewise. * m4/gettimeofday.m4 (gl_FUNC_GETTIMEOFDAY_CLOBBER): Likewise. * m4/hypot.m4 (gl_FUNC_HYPOT): Likewise. * m4/hypotf.m4 (gl_FUNC_HYPOTF): Likewise. * m4/hypotl.m4 (gl_FUNC_HYPOTL): Likewise. * m4/iconv_open-utf.m4 (gl_FUNC_ICONV_OPEN_UTF_SUPPORT): Likewise. * m4/link-follow.m4 (gl_FUNC_LINK_FOLLOWS_SYMLINK): Likewise. * m4/log.m4 (gl_FUNC_LOG): Likewise. * m4/logf.m4 (gl_FUNC_LOGF): Likewise. * m4/logl.m4 (gl_FUNC_LOGL_WORKS): Likewise. * m4/log10.m4 (gl_FUNC_LOG10): Likewise. * m4/log10f.m4 (gl_FUNC_LOG10F): Likewise. * m4/log10l.m4 (gl_FUNC_LOG10L): Likewise. * m4/log1p.m4 (gl_FUNC_LOG1P): Likewise. * m4/log1pf.m4 (gl_FUNC_LOG1PF): Likewise. * m4/log1pl.m4 (gl_FUNC_LOG1PL): Likewise. * m4/log2.m4 (gl_FUNC_LOG2): Likewise. * m4/log2f.m4 (gl_FUNC_LOG2F): Likewise. * m4/malloc.m4 (_AC_FUNC_MALLOC_IF): Likewise. * m4/mkdir.m4 (gl_FUNC_MKDIR): Likewise. * m4/mkstemp.m4 (gl_FUNC_MKSTEMP): Likewise. * m4/modf.m4 (gl_FUNC_MODF): Likewise. * m4/modff.m4 (gl_FUNC_MODFF): Likewise. * m4/modfl.m4 (gl_FUNC_MODFL): Likewise. * m4/perror.m4 (gl_FUNC_PERROR): Likewise. * m4/printf.m4 (gl_PRINTF_SIZES_C99, gl_PRINTF_INFINITE, gl_PRINTF_INFINITE_LONG_DOUBLE, gl_PRINTF_DIRECTIVE_A, gl_PRINTF_DIRECTIVE_F, gl_PRINTF_FLAG_ZERO, gl_SNPRINTF_TRUNCATION_C99, gl_SNPRINTF_RETVAL_C99, gl_SNPRINTF_DIRECTIVE_N, gl_VSNPRINTF_ZEROSIZE_C99): Likewise. * m4/ptsname.m4 (gl_FUNC_PTSNAME): Likewise. * m4/putenv.m4 (gl_FUNC_PUTENV): Likewise. * m4/realloc.m4 (_AC_FUNC_REALLOC_IF): Likewise. * m4/remainder.m4 (gl_FUNC_REMAINDER): Likewise. * m4/remainderf.m4 (gl_FUNC_REMAINDERF): Likewise. * m4/remainderl.m4 (gl_FUNC_REMAINDERL): Likewise. * m4/rintl.m4 (gl_FUNC_RINTL): Likewise. * m4/round.m4 (gl_FUNC_ROUND): Likewise. * m4/roundf.m4 (gl_FUNC_ROUNDF): Likewise. * m4/roundl.m4 (gl_FUNC_ROUNDL): Likewise. * m4/setenv.m4 (gl_FUNC_SETENV): Likewise. * m4/signbit.m4 (gl_SIGNBI
Re: musl, printf out-of-memory test
Rich Felker wrote: > > Replacements of *printf, because of > > [...] > > checking whether printf survives out-of-memory conditions... no > > No idea. Copying out the test and running it directly, it passes just > fine for me. Maybe gnulib has already replaced printf with its own > malloc-using version by the time it gets to this test?? Strange indeed. With a testdir of all of gnulib, I got configure:17615: checking whether printf survives out-of-memory conditions configure:17786: /arch/x86-linux/inst-musl/bin/musl-gcc -std=gnu99 -o conftest -g -O2 -Wall conftest.c >&5 configure:17789: $? = 0 configure:17837: result: yes but with a testdir of only the POSIX related modules of gnulib, I got configure:13657: checking whether printf survives out-of-memory conditions configure:13828: /arch/x86-linux/inst-musl/bin/musl-gcc -std=gnu99 -o conftest -g -O2 -Wall conftest.c >&5 configure:13831: $? = 0 configure:13879: result: no The '$? = 0' line prints only the linker's exit code, not the runtime exit code. I'm adding a second output line for the runtime exit code. Then I get: configure:8919: checking whether printf survives out-of-memory conditions configure:9090: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2 -Wall conftest.c >&5 configure:9093: $? = 0 configure:9097: $? = 1 configure:9142: result: no After adding a printf to stderr: Once I get configure:8919: checking whether printf survives out-of-memory conditions configure:9093: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2 -Wall conftest.c >&5 configure:9096: $? = 0 printf's return value = 502, errno = 0 configure:9100: $? = 0 configure:9145: result: yes In another configure run I get: configure:8919: checking whether printf survives out-of-memory conditions configure:9093: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2 -Wall conftest.c >&5 configure:9096: $? = 0 configure:9100: $? = 1 configure:9145: result: no So, the exit code 1 must have come from the crash handler. Without this crash handler: 7x I get configure:8919: checking whether printf survives out-of-memory conditions configure:8979: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2 -Wall conftest.c >&5 configure:8982: $? = 0 printf's return value = 502, errno = 0 configure:8986: $? = 0 configure:9031: result: yes but once I get configure:8979: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2 -Wall conftest.c >&5 configure:8982: $? = 0 configure:8986: $? = 139 configure:9031: result: no So, apparently, under memory stress, musl's printf has a probability of between 10% and 50% of crashing with SIGSEGV (139 = 128 + 11). Bruno 2012-06-19 Bruno Haible *printf-posix: Put more info into config.log. * m4/printf.m4 (gl_PRINTF_ENOMEM): Emit conftest's error output and exit code into config.log. --- m4/printf.m4.orig Tue Jun 19 12:41:56 2012 +++ m4/printf.m4Tue Jun 19 12:41:53 2012 @@ -1,4 +1,4 @@ -# printf.m4 serial 48 +# printf.m4 serial 49 dnl Copyright (C) 2003, 2007-2012 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -1028,8 +1028,9 @@ changequote([,])dnl ])]) if AC_TRY_EVAL([ac_link]) && test -s conftest$ac_exeext; then -(./conftest +(./conftest 2>&AS_MESSAGE_LOG_FD result=$? + _AS_ECHO_LOG([\$? = $result]) if test $result != 0 && test $result != 77; then result=1; fi exit $result ) >/dev/null 2>/dev/null
log2l: Work around musl libc bug
log2l lacks precision on musl libc 1.2.2/arm64, musl libc 1.2.2/s390x.
This patch adds a configure test, that enables a gnulib workaround.
2021-01-31 Bruno Haible
log2l: Work around musl libc bugs.
* doc/posix-functions/log2l.texi: Document musl libc bugs.
* m4/log2l.m4 (gl_FUNC_LOG2L_WORKS): Add more tests. Update cross
compilation guess.
diff --git a/doc/posix-functions/log2l.texi b/doc/posix-functions/log2l.texi
index 24e367c..563a67e 100644
--- a/doc/posix-functions/log2l.texi
+++ b/doc/posix-functions/log2l.texi
@@ -14,6 +14,13 @@ FreeBSD 6.0, NetBSD 9.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1,
HP-UX 11, older IRIX
@item
This function is not declared on some platforms:
IRIX 6.5.
+@item
+This function produces results which are accurate to only 16 digits on some
+platforms:
+musl libc 1.2.2/arm64, musl libc 1.2.2/s390x.
+@item
+This function returns Infinity for some large finite arguments on some
platforms:
+musl libc 1.2.2/arm64, musl libc 1.2.2/s390x.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/m4/log2l.m4 b/m4/log2l.m4
index 4776543..cd8e984 100644
--- a/m4/log2l.m4
+++ b/m4/log2l.m4
@@ -1,4 +1,4 @@
-# log2l.m4 serial 2
+# log2l.m4 serial 3
dnl Copyright (C) 2010-2021 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -69,6 +69,7 @@ AC_DEFUN([gl_FUNC_LOG2L],
dnl Test whether log2l() works.
dnl On OSF/1 5.1, log2l(-0.0) is NaN.
+dnl On musl 1.2.2/{arm64,s390x}, the result is accurate to only 16 digits.
AC_DEFUN([gl_FUNC_LOG2L_WORKS],
[
AC_REQUIRE([AC_PROG_CC])
@@ -77,7 +78,40 @@ AC_DEFUN([gl_FUNC_LOG2L_WORKS],
[
AC_RUN_IFELSE(
[AC_LANG_SOURCE([[
+#ifndef __NO_MATH_INLINES
+# define __NO_MATH_INLINES 1 /* for glibc */
+#endif
+#include
#include
+/* Override the values of , like done in float.in.h. */
+#if defined __i386__ && (defined __BEOS__ || defined __OpenBSD__)
+# undef LDBL_MANT_DIG
+# define LDBL_MANT_DIG 64
+# undef LDBL_MIN_EXP
+# define LDBL_MIN_EXP(-16381)
+# undef LDBL_MAX_EXP
+# define LDBL_MAX_EXP16384
+#endif
+#if defined __i386__ && (defined __FreeBSD__ || defined __DragonFly__)
+# undef LDBL_MANT_DIG
+# define LDBL_MANT_DIG 64
+# undef LDBL_MIN_EXP
+# define LDBL_MIN_EXP(-16381)
+# undef LDBL_MAX_EXP
+# define LDBL_MAX_EXP16384
+#endif
+#if (defined _ARCH_PPC || defined _POWER) && defined _AIX && (LDBL_MANT_DIG ==
106) && defined __GNUC__
+# undef LDBL_MIN_EXP
+# define LDBL_MIN_EXP DBL_MIN_EXP
+#endif
+#if defined __sgi && (LDBL_MANT_DIG >= 106)
+# undef LDBL_MANT_DIG
+# define LDBL_MANT_DIG 106
+# if defined __GNUC__
+# undef LDBL_MIN_EXP
+# define LDBL_MIN_EXP DBL_MIN_EXP
+# endif
+#endif
#ifndef log2l /* for AIX */
extern
#ifdef __cplusplus
@@ -85,25 +119,59 @@ extern
#endif
long double log2l (long double);
#endif
-volatile long double x;
-volatile long double y;
-int main ()
+static long double dummy (long double x) { return 0; }
+volatile long double gx;
+volatile long double gy;
+int main (int argc, char *argv[])
{
+ long double (* volatile my_log2l) (long double) = argc ? log2l : dummy;
+ int result = 0;
/* This test fails on OSF/1 5.1. */
- x = -0.0L;
- y = log2l (x);
- if (!(y + y == y))
-return 1;
- return 0;
+ {
+gx = -0.0L;
+gy = my_log2l (gx);
+if (!(gy + gy == gy))
+ result |= 1;
+ }
+ /* This test fails on musl 1.2.2/arm64, musl 1.2.2/s390x. */
+ {
+const long double TWO_LDBL_MANT_DIG = /* 2^LDBL_MANT_DIG */
+ (long double) (1U << ((LDBL_MANT_DIG - 1) / 5))
+ * (long double) (1U << ((LDBL_MANT_DIG - 1 + 1) / 5))
+ * (long double) (1U << ((LDBL_MANT_DIG - 1 + 2) / 5))
+ * (long double) (1U << ((LDBL_MANT_DIG - 1 + 3) / 5))
+ * (long double) (1U << ((LDBL_MANT_DIG - 1 + 4) / 5));
+long double x = 11.358L;
+long double y = my_log2l (x);
+long double z = my_log2l (1.0L / x);
+long double err = (y + z) * TWO_LDBL_MANT_DIG;
+if (!(err >= -1.0L && err <= 1.0L))
+ result |= 2;
+ }
+ /* This test fails on musl 1.2.2/arm64, musl 1.2.2/s390x. */
+ if (DBL_MAX_EXP < LDBL_MAX_EXP)
+{
+ long double x = ldexpl (1.0L, DBL_MAX_EXP); /* finite! */
+ long double y = my_log2l (x);
+ if (y > 0 && y + y == y) /* infinite? */
+result |= 4;
+}
+ return result;
}
]])],
[gl_cv_func_log2l_works=yes],
[gl_cv_func_log2l_works=no],
[case "$host_os" in
- osf*) gl_cv_func_log2l_works="guessing no" ;;
- # Guess yes on native Windows.
- mingw*) gl_cv_func_log2l_works="guessing yes" ;;
- *) gl_cv_func_log2l_works="guessing yes" ;;
+ # Guess yes on glibc s
Re: localename: add support for musl libc
On Sun, Feb 25, 2018 at 11:17:08AM +0100, Bruno Haible wrote: > Hi Assaf, > > > > +# elif defined __linux__ && HAVE_LANGINFO_H && defined NL_LOCALE_NAME > > > +/* musl libc */ > > > > A tiny comment about the comment :) > > > > You wrote "musl libc", but what the "elif defined ..." is something like > > "linux but not glibc, with langinfo.h" - which could (in theory) be > > something other than musl-libc. > > Yes, that's it. The refusal of the musl people to define a symbol such > as __MUSL__ [1] makes it hard to write future-proof code. If someone else The existence of it would not help futureproof and would promote writing of non-futureproof code by hardcoding specific assumptions about a specific version of musl rather than configure-time or preprocessor-time detection of features. > creates a platform that shares the same superficial characteristics > (runs on Linux, has and NL_LOCALE_NAME) but behaves > differently, we will accidentally run into the code intended for musl > on that platform. Whereas the fallback code (return "" in this case) > would be safer: it would make the unit test fail, but it would not > lead to a compilation error or to a code dump. > > And if that platform does not have an identifiying macro either, we > really got a problem how to distinguish the two. The comment /* musl */ above is wrong and should not have been added. Really use of NL_LOCALE_NAME should always be preferred if it's available, since it's a clean public interface for the functionality desired rather than a hack poking at implementation internals. But if you really like poking at internals for other implementations, it also works to leave it as the fallback case after the hardcoded list of assumptions about particular known platforms. It should just be called something more reasonable like /* otherwise, use public NL_LOCALE_NAME interface if the system has it */ instead of /* musl */. Rich
Re: localename: add support for musl libc
Hi Assaf, > > +# elif defined __linux__ && HAVE_LANGINFO_H && defined NL_LOCALE_NAME > > +/* musl libc */ > > A tiny comment about the comment :) > > You wrote "musl libc", but what the "elif defined ..." is something like > "linux but not glibc, with langinfo.h" - which could (in theory) be > something other than musl-libc. Yes, that's it. The refusal of the musl people to define a symbol such as __MUSL__ [1] makes it hard to write future-proof code. If someone else creates a platform that shares the same superficial characteristics (runs on Linux, has and NL_LOCALE_NAME) but behaves differently, we will accidentally run into the code intended for musl on that platform. Whereas the fallback code (return "" in this case) would be safer: it would make the unit test fail, but it would not lead to a compilation error or to a code dump. And if that platform does not have an identifiying macro either, we really got a problem how to distinguish the two. Bruno [1] https://wiki.musl-libc.org/faq.html
Re: gnulib does not always detect need for iconv() hack on musl
On Sun, Oct 17, 2021 at 07:18:51PM +0200, Bruno Haible wrote: > Hello Sergei, > > Sergei Trofimovich wrote: > > The following fails bison-3.8.2 tests: > > $ ./configure && make && make check > > The following succeeds: > > $ ./configure --host=x86_64-unknown-linux-musl && make && make check > > > > The failure happens due to unexpected '*' output in report logs instead > > of '%empty' on 'ASCII' locales. > > > > These unexpected '*' pop back again because gnulib relies on '--host=' > > parameter for './configure' to detect musl target (for lack of better > > signal?): > > > > https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/musl.m4#n16 > > > > case "$host_os" in > > *-musl*) AC_DEFINE([MUSL_LIBC], [1], [Define to 1 on musl libc.]) ;; > > > > https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/unicodeio.c#n151 > > > > /* FreeBSD iconv(), NetBSD iconv(), and Solaris 11 iconv() insert > >a '?' if they cannot convert. */ > > # if !defined _LIBICONV_VERSION > > || (res > 0 && outptr - outbuf == 1 && *outbuf == '?') > > # endif > > /* musl libc iconv() inserts a '*' if it cannot convert. */ > > # if !defined _LIBICONV_VERSION && MUSL_LIBC > > || (res > 0 && outptr - outbuf == 1 && *outbuf == '*') > > # endif > > ) > > return failure (code, NULL, callback_arg); > > > > What do you think of enabling the workaround regardless of MUSL_LIBC > > define? > > The MUSL_LIBC symbol is supposed to be set on musl platforms; this is > what musl.m4 is for. The difference between your two invocations is that > in the first case, it used a $host triple inferred by config.guess, > while in the second case, it used the $host that you specified on the > command line. > > When I try your two commands (just the configure step), the first one > prints > checking for host system type... x86_64-pc-linux-musl > while the second one prints > checking for host system type... x86_64-unknown-linux-musl > > The next steps of the investigation are: In the first case, > - What did the "checking for host system type..." line look like? > - Which of the environment variables CC_FOR_BUILD, HOST_CC, CC, > CONFIG_SITE did you have defined, and to which values? Aha, 'config.guess' clearly detects wrong libc here: checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu I did not realize 'config.guess' has the code to detect libc but it clearly does. I'll dig from there and complain elsewhere. Thank you! -- Sergei
Re: [musl] Re: localename: add support for musl libc
On Sun, Feb 25, 2018 at 10:19:06PM +0100, Bruno Haible wrote: > Hi Rich, > > > Really use of NL_LOCALE_NAME should always be preferred if it's > > available, since it's a clean public interface for the functionality > > desired rather than a hack poking at implementation internals. But if > > you really like poking at internals for other implementations ... > > In a perfect world, what you say would make sense. > > However, not all libc versions that define _NL_LOCALE_NAME also have > a _NL_LOCALE_NAME that *works* [1]. It's not that I "really like poking > at internals". It's that I want my code to actually work. Which ones does it not work on, and what happens when it doesn't work? If there are libcs that advertise a feature in their headers but don't actually support it, it sounds like they're the ones that need special-casing. (I think it's old glibc, or some mismatched version of glibc headers and .so, in which case it's already special-cased, right?) But probably it's just a clean failure at runtime (like returning a null pointer) where you can try something else if it failed. > > The comment /* musl */ above is wrong and should not have been added. > > How can you judge that a comment in gnulib code is adequate, when you > are not familiar with the way gnulib is developed? > > The comment /* musl */ says two things: > - If a developer makes changes to these piece of code, they should > test in on a system with musl libc. > - If a developer sees that this code is being compiled/executed on > a system without musl libc, they should review the #if chain, to > make sure no mistake was introduced in #ifs. OK. I think it would have been clearer as: /* Known to work and used on musl libc. Also present * but not always working on [glibc?] so we use the * above case... */ If /* musl */ is fine for conveying that to the people who work on your code, that's one thing, but I still think it's misleading to others who come across and read it, because this is not an interface musl invented but rather one we adopted because glibc, and maybe other systems, already invented something that looked clean & reasonable to solve a problem that had no other clean solution. > Now back to my comment that you haven't addressed, regarding lack of > __MUSL__: > > If someone else > creates a platform that shares the same superficial characteristics > (runs on Linux, has and NL_LOCALE_NAME) but behaves > differently, we will accidentally run into the code intended for musl > on that platform. Whereas the fallback code (return "" in this case) > would be safer: it would make the unit test fail, but it would not > lead to a compilation error or to a code dump. I disagree with the characterization of this code as "intended for musl". It's possible that this is someone's intent, but it's not a programming model musl aims to support. Rather I would see it as code "intended for systems that provide the NL_LOCALE_NAME langinfo item to query the name of the active locale". Whether musl is such a system is version-dependent (1.1.17 or later) and easily determined via configure- or preprocessor-time tests. As for failure on other systems, it's testable at configure time that NL_LOCALE_NAME is a macro accepting locale category macros as arguments and producing an integer result, demonstrating that it won't produce a compile error. In that case the worst thing that happens, unless nl_langinfo is buggy, is returning an empty string or some string that's not the locale name. (I know at one point in the past musl erroneously returned null for undefined items, so it might be worth checking for that too; other implementations might also have had that bug at some point.) > And if that platform does not have an identifiying macro either, we > really got a problem how to distinguish the two. I'm not clear what further distinguishing is needed. We've discussed before and are open to designing an approach to advertise extended functionality via macros defined in the standard headers -- something like the _POSIX_* macros unistd.h defines, but for extensions. But not just an "I am musl, go assume whatever was true in the version of musl you looked at" macro. But in order for this to move forward there should really be some interest in collaboration between implementations (I think glibc would be open to it now, maybe one or more BSDs too) and input from application programers (the consumers of the macros) on what would be useful to them. Rich
Re: Why require SLOW_BUT_NO_HACKS for stubs?
On 06/09/2012 11:05 PM, Isaac Dunham wrote: > Is there any reason not to merge Performance, surely. But if there's consensus that performance does not matter that much with musl, perhaps we should default to the slow version with musl. Is there any simple way to tell at compile-time, or at configure-time, that musl is being used? That would help us distinguish musl (where being slow is acceptable) from other platforms (which may not want that).
Re: [musl] Re: parse-datetime test failure
On 11/11/20 8:07 PM, Rich Felker wrote: Thanks. I believe you've just re-discovered a known bug that's fixed in musl commit 8ebc853d37c80f0f236cc7a92cb0acc6aace, which will be included in the upcoming 1.2.2 release. Yes, thanks, that looks exactly right. It's *so* nice to have bugs fixed before I even report them! Here's a URL for the musl patch, for the record: https://git.musl-libc.org/cgit/musl/commit/?id=8ebc853d37c80f0f236cc7a92cb0acc6aace
Re: stdioext on musl
Rich, > Then Bruno came back to us with this monstrosity of a patch that > insists, for no good reason, on trying to detect musl specifically, > thereby increasing the amount of broken special-cased non-portable > code in gnulib rather than modernizing it. > ... > What is my business is that Bruno wants to start poking at internals > of musl in a way that WILL BREAK in nearly every single application > that's using gnulib, and that will have users coming to us with bug > reports when gnulib is the code at fault. I can't and won't work with > that. If it's your final decision to do things that way ... There is a big misunderstanding here. I don't want to commit that large patch with lots of "#ifdef __MUSL__" if there will soon be a better way to do, after some changes have gone into musl. The purpose of the patch was 1. to get down from the "gnulib is unportable" discussion, and provide a patch that provides the interoperability today, 2. give you some hints about which kinds of primitives in musl would be needed for gnulib to get rid of these "#ifdef __MUSL__". I am writing to you precisely to make the plan that Eric outlined more concrete. I have told you constructively what our needs are: 1) a macro like __MUSL__ 2) the 4 functions __freadahead, __freadptr, __freadptrinc, __fseterr. Now it's your turn. Please consider implementing these needs or parts of these needs in musl. (Even if you don't agree that these are or should be needs of gnulib. Just believe me and Paul that we need this.) Then I, on the gnulib side, will see to which extent the (admittedly large) patch can be reduced to something more reasonable. Once again: My goal here is to support all the stdioext functions on future versions of musl, with as little #ifdef as possible. The result depends on what will go into <http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl>. Bruno
log1pl: Work around musl libc bug
log1pl lacks precision on musl libc 1.2.2/arm64, musl libc 1.2.2/s390x.
This patch adds a configure test, that enables a gnulib workaround.
2021-01-31 Bruno Haible
log1pl: Work around musl libc bug.
* doc/posix-functions/log1pl.texi: Document musl libc bug.
* m4/log1pl.m4 (gl_FUNC_LOG1PL_WORKS): New macro.
(gl_FUNC_LOG1PL): Invoke it.
diff --git a/doc/posix-functions/log1pl.texi b/doc/posix-functions/log1pl.texi
index 802c2e6..be81d60 100644
--- a/doc/posix-functions/log1pl.texi
+++ b/doc/posix-functions/log1pl.texi
@@ -11,6 +11,10 @@ Portability problems fixed by either Gnulib module
@code{log1pl} or @code{log1pl
@item
This function is missing on some platforms:
FreeBSD 6.0, NetBSD 9.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX
6.5, Solaris 9, Cygwin 1.7.x, MSVC 9, Android 4.4.
+@item
+This function produces results which are accurate to only 16 digits on some
+platforms:
+musl libc 1.2.2/arm64, musl libc 1.2.2/s390x.
@end itemize
Portability problems fixed by Gnulib module @code{log1pl-ieee}:
diff --git a/m4/log1pl.m4 b/m4/log1pl.m4
index 7d95aac..bd9d63d 100644
--- a/m4/log1pl.m4
+++ b/m4/log1pl.m4
@@ -1,4 +1,4 @@
-# log1pl.m4 serial 8
+# log1pl.m4 serial 9
dnl Copyright (C) 2012-2021 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -22,6 +22,16 @@ AC_DEFUN([gl_FUNC_LOG1PL],
LIBS="$save_LIBS"
if test $ac_cv_func_log1pl = yes; then
LOG1PL_LIBM="$LOG1P_LIBM"
+
+save_LIBS="$LIBS"
+LIBS="$LIBS $LOG1PL_LIBM"
+gl_FUNC_LOG1PL_WORKS
+LIBS="$save_LIBS"
+case "$gl_cv_func_log1pl_works" in
+ *yes) ;;
+ *) REPLACE_LOG1PL=1 ;;
+esac
+
m4_ifdef([gl_FUNC_LOG1PL_IEEE], [
if test $gl_log1pl_required = ieee && test $REPLACE_LOG1PL = 0; then
AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles
@@ -99,3 +109,93 @@ int main (int argc, char *argv[])
fi
AC_SUBST([LOG1PL_LIBM])
])
+
+dnl Test whether log1pl() works.
+dnl On musl 1.2.2/{arm64,s390x}, the result is accurate to only 16 digits.
+AC_DEFUN([gl_FUNC_LOG1PL_WORKS],
+[
+ AC_REQUIRE([AC_PROG_CC])
+ AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles
+ AC_CACHE_CHECK([whether log1pl works], [gl_cv_func_log1pl_works],
+[
+ AC_RUN_IFELSE(
+[AC_LANG_SOURCE([[
+#ifndef __NO_MATH_INLINES
+# define __NO_MATH_INLINES 1 /* for glibc */
+#endif
+#include
+#include
+/* Override the values of , like done in float.in.h. */
+#if defined __i386__ && (defined __BEOS__ || defined __OpenBSD__)
+# undef LDBL_MANT_DIG
+# define LDBL_MANT_DIG 64
+# undef LDBL_MIN_EXP
+# define LDBL_MIN_EXP(-16381)
+# undef LDBL_MAX_EXP
+# define LDBL_MAX_EXP16384
+#endif
+#if defined __i386__ && (defined __FreeBSD__ || defined __DragonFly__)
+# undef LDBL_MANT_DIG
+# define LDBL_MANT_DIG 64
+# undef LDBL_MIN_EXP
+# define LDBL_MIN_EXP(-16381)
+# undef LDBL_MAX_EXP
+# define LDBL_MAX_EXP16384
+#endif
+#if (defined _ARCH_PPC || defined _POWER) && defined _AIX && (LDBL_MANT_DIG ==
106) && defined __GNUC__
+# undef LDBL_MIN_EXP
+# define LDBL_MIN_EXP DBL_MIN_EXP
+#endif
+#if defined __sgi && (LDBL_MANT_DIG >= 106)
+# undef LDBL_MANT_DIG
+# define LDBL_MANT_DIG 106
+# if defined __GNUC__
+# undef LDBL_MIN_EXP
+# define LDBL_MIN_EXP DBL_MIN_EXP
+# endif
+#endif
+#undef log1pl
+extern
+#ifdef __cplusplus
+"C"
+#endif
+long double log1pl (long double);
+static long double dummy (long double x) { return 0; }
+int main (int argc, char *argv[])
+{
+ long double (* volatile my_log1pl) (long double) = argc ? log1pl : dummy;
+ int result = 0;
+ /* This test fails on musl 1.2.2/arm64, musl 1.2.2/s390x. */
+ {
+const long double TWO_LDBL_MANT_DIG = /* 2^LDBL_MANT_DIG */
+ (long double) (1U << ((LDBL_MANT_DIG - 1) / 5))
+ * (long double) (1U << ((LDBL_MANT_DIG - 1 + 1) / 5))
+ * (long double) (1U << ((LDBL_MANT_DIG - 1 + 2) / 5))
+ * (long double) (1U << ((LDBL_MANT_DIG - 1 + 3) / 5))
+ * (long double) (1U << ((LDBL_MANT_DIG - 1 + 4) / 5));
+long double x = 11.358L;
+long double y = my_log1pl (x);
+long double z = my_log1pl (- x / (1.0L + x));
+long double err = (y + z) * TWO_LDBL_MANT_DIG;
+if (!(err >= -900.0L && err <= 900.0L))
+ result |= 1;
+ }
+
+ return result;
+}
+]])],
+[gl_cv_func_log1pl_works=yes],
+[gl_cv_func_log1pl_works=no],
+[case "$host_os" in
+ # Guess yes on glibc systems.
+ *-gnu* | gnu*) gl_cv_func_log1pl_works="guessing yes" ;;
+ # Guess no on musl systems.
+ *-musl*) gl_cv_func_log1pl_works="guessing no" ;;
+ # Guess yes on native W
Re: Building Bison 3.7 with musl (was Re: portability issues with unicodeio)
[CCing bug-gnulib. Dropping musl list from CC.]
A. Wilcox wrote in <https://www.openwall.com/lists/musl/2020/07/29/2>:
> Seeing some weird behaviour here building Bison 3.7 on musl libc.
>
> Something seems to be "intelligent" enough to know that \u2022 is a
> bullet character, and is replacing it with "*" instead of ".", causing
> all the tests to fail:
>
> awilcox on gwyn [17] bison: LC_ALL=C /bin/printf '\u2022\n' | od -t x1
> 000 2a 0a
> 002
Thanks for the report. I see that the recently added 'unicodeio' unit test
fails on musl libc. This patch fixes it.
2020-07-29 Bruno Haible
unicodeio: Fix wrong result on musl libc.
Reported by A. Wilcox in
<https://www.openwall.com/lists/musl/2020/07/29/2>.
* lib/unicodeio.c (unicode_to_mb): Handle asterisk fallback characters
on musl libc.
* m4/unicodeio.m4 (gl_UNICODEIO): Invoke gl_MUSL_LIBC.
* modules/unicodeio (Files): Add m4/musl.m4.
diff --git a/lib/unicodeio.c b/lib/unicodeio.c
index b616e3d..7d5e1fb 100644
--- a/lib/unicodeio.c
+++ b/lib/unicodeio.c
@@ -130,7 +130,7 @@ unicode_to_mb (unsigned int code,
(ICONV_CONST char **)&inptr, &inbytesleft,
&outptr, &outbytesleft);
if (inbytesleft > 0 || res == (size_t)(-1)
- /* Irix iconv() inserts a NUL byte if it cannot convert. */
+ /* Irix iconv() inserts a NUL byte if it cannot convert. */
# if !defined _LIBICONV_VERSION && (defined sgi || defined __sgi)
|| (res > 0 && code != 0 && outptr - outbuf == 1 && *outbuf == '\0')
# endif
@@ -139,6 +139,10 @@ unicode_to_mb (unsigned int code,
# if !defined _LIBICONV_VERSION && (defined __NetBSD__ || defined __sun)
|| (res > 0 && outptr - outbuf == 1 && *outbuf == '?')
# endif
+ /* musl libc iconv() inserts a '*' if it cannot convert. */
+# if !defined _LIBICONV_VERSION && MUSL_LIBC
+ || (res > 0 && outptr - outbuf == 1 && *outbuf == '*')
+# endif
)
return failure (code, NULL, callback_arg);
diff --git a/m4/unicodeio.m4 b/m4/unicodeio.m4
index 11bcd18..a2e9bf0 100644
--- a/m4/unicodeio.m4
+++ b/m4/unicodeio.m4
@@ -1,4 +1,4 @@
-# unicodeio.m4 serial 2
+# unicodeio.m4 serial 3
dnl Copyright (C) 2002-2003, 2009-2020 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -6,6 +6,6 @@ dnl with or without modifications, as long as this notice is
preserved.
AC_DEFUN([gl_UNICODEIO],
[
- dnl No prerequisites of lib/unicodeio.c.
- :
+ dnl Prerequisites of lib/unicodeio.c.
+ gl_MUSL_LIBC
])
diff --git a/modules/unicodeio b/modules/unicodeio
index 51721db..d7a3a4a 100644
--- a/modules/unicodeio
+++ b/modules/unicodeio
@@ -5,6 +5,7 @@ Files:
lib/unicodeio.h
lib/unicodeio.c
m4/unicodeio.m4
+m4/musl.m4
Depends-on:
unistr/u8-uctomb
Re: bug#70104: "FAIL: test-canonicalize" coreutils v9.5 on musl libc
On 3/31/24 05:22, Pádraig Brady wrote: On 31/03/2024 10:02, Adept's Lab wrote: test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed ^ the only error log message I get. Fail was not presented with previous stable versions. This is on musl 1.1.24 as detailed at: https://github.com/coreutils/coreutils/issues/83T Does this behavior (of whether / and // are the same directory) depend on musl version, or on how musl is configured?
Re: [PATCH] getusershell: Add tests.
Hi Collin, > I remember you saying a few days ago saying that "every function is > worth testing", so here is more evidence. :) :-) > It appears that musl doesn't check for comments which explains that > failure [2]. > > It also looks like musl will return empty lines (getline () with > length 1), which I believe is incorrect from the FreeBSD man page > description. So, once you have a musl libc VM yourself, you are ready for reporting your first musl libc bug. The reporting address is . Bruno
Re: Behaviour of strverscmp(3)
Thanks for report, Dmitry. I am slowly coming back to this. I have
noticed that Cygwin (via MSYS2) has the same strverscmp as musl:
https://cygwin.com/cgit/newlib-cygwin/tree/newlib/libc/string/strverscmp.c
Compare against musl strverscmp:
https://git.musl-libc.org/cgit/musl/tree/src/string/strverscmp.c
Since gsasl (and many other projects) gets strverscmp() from gnulib, I'm
cc'ing the bug-gnulib list. I think gnulib should detect and work
around this buggy strverscmp. The documentation says the function is
missing on all non-glibc platforms, but this is not the case, see:
https://www.gnu.org/software/gnulib/manual/html_node/strverscmp.html
I don't have time to work on a patch for gnulib now, but this e-mail
will serve as a reminder... but happy if someone else has ideas on how
to resolve it in gnulib. See reproducer below; I recall seeing other
problems too such as strverscmp("1.7", "1.7") behaving different.
Compare to the glibc/gnulib implementation:
https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/strverscmp.c
/Simon
Dmitry Bogatov writes:
> Hello.
>
> While trying to building gsasl statically with musl library as part of
> Nixpkgs distribution, I noticed that test built from tests/version.c
> fails when built with musl library. After a bit of troubleshooting, I
> can pinpoint the reason -- different behaviour of "strverscmp" from
> glibc and musl.
>
> Example code:
>
> #include
> #include
>
> int main()
> {
> int value = strverscmp("UNKNOWN", "2.2.0");
> printf("%d\n", value);
> return 0;
> }
>
> Under glibc value "35" is printed (positive), under musl value "-1" is
> printed (negative). Not sure what is the correct solution for the
> issue, so I cross-post into two lists.
>
> For now I plan to patch-out this particular test. Thank you.
>
>
signature.asc
Description: PGP signature
readutmp: Revisit portability
It wasn't clear to me, from looking it readutmp.h, that programs could
portably rely on the UT->ut_line member. To clarify this, here are some
doc updates.
Also, since there's no system that has 'struct utmp.ut_exit.ut_*', let me
remove these configure tests. (The only platform that has
'struct utmpx.ut_exit.ut_*' is OSF/1.)
2023-07-31 Bruno Haible
readutmp: Revisit portability.
* m4/readutmp.m4 (gl_READUTMP): Don't test for struct utmp.ut_exit.ut_*,
since no platform has these.
* lib/readutmp.h (UT_EXIT_E_TERMINATION): Don't test
HAVE_STRUCT_UTMP_UT_EXIT_UT_TERMINATION.
(UT_EXIT_E_EXIT): Don't test HAVE_STRUCT_UTMP_UT_EXIT_UT_EXIT.
* doc/posix-headers/utmpx.texi: Update platforms list. Mention
portability problems of specific 'struct utmpx' fields.
* doc/glibc-headers/utmp.texi: Update platforms list. Mention
portability problems of specific 'struct utmp' fields.
diff --git a/doc/glibc-headers/utmp.texi b/doc/glibc-headers/utmp.texi
index 1e9d3757cb..f45037ae74 100644
--- a/doc/glibc-headers/utmp.texi
+++ b/doc/glibc-headers/utmp.texi
@@ -23,7 +23,7 @@
@itemize
@item
This header file is missing on some platforms:
-FreeBSD 13.0, mingw, MSVC 14.
+FreeBSD 13.2, mingw, MSVC 14.
@item
@code{} is a prerequisite of @code{} on some platforms:
FreeBSD 8.0, OpenBSD 7.2.
@@ -32,6 +32,26 @@
Portability problems not fixed by Gnulib:
@itemize
@item
+While some platforms have the @code{struct utmp} field @code{ut_user},
+older platforms have the field @code{ut_name}.
+@item
+The @code{struct utmp} fields @code{ut_id}, @code{ut_pid}, @code{ut_type}
+do not exist on some platforms:
+macOS, old FreeBSD, NetBSD, OpenBSD, Minix.
+@item
+The @code{struct utmp} field @code{ut_host} does not exist on some platforms:
+IRIX, Solaris.
+@item
+The @code{struct utmp} field @code{ut_exit} does not exist on some platforms:
+macOS, old FreeBSD, NetBSD, OpenBSD, Minix, Cygwin.
+@item
+The @code{struct utmp} field @code{ut_session} does not exist on some
platforms:
+macOS, old FreeBSD, NetBSD, OpenBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin.
+@item
+The @code{struct utmp} field @code{ut_addr} or @code{ut_addr_v6} does not exist
+on some platforms:
+macOS, old FreeBSD, NetBSD, OpenBSD, Minix, AIX, IRIX, Solaris.
+@item
On some platforms, this API does not support timestamps past the
year 2038:
glibc 2.38 on 32-bit platforms like x86 and ARM where @code{time_t}
diff --git a/doc/posix-headers/utmpx.texi b/doc/posix-headers/utmpx.texi
index fd3d4d6ab7..40efca3b64 100644
--- a/doc/posix-headers/utmpx.texi
+++ b/doc/posix-headers/utmpx.texi
@@ -13,7 +13,21 @@
@itemize
@item
This header file is missing on some platforms:
-FreeBSD 6.0, OpenBSD 6.7, Minix 3.1.8, mingw, MSVC 14, Android 9.0.
+FreeBSD 8.4, OpenBSD 7.2, Minix 3.1.8, mingw, MSVC 14, Android 13.0.
+@item
+While some platforms have the @code{struct utmpx} field @code{ut_user},
+older platforms have the field @code{ut_name}.
+@item
+The @code{struct utmpx} field @code{ut_exit} does not exist on some platforms:
+macOS, FreeBSD, AIX, Cygwin.
+@item
+The @code{struct utmpx} field @code{ut_session} does not exist
+on some platforms:
+macOS, FreeBSD, AIX, HP-UX, Cygwin.
+@item
+The @code{struct utmpx} field @code{ut_addr} or @code{ut_addr_v6} or
+@code{ut_ss} does not exist on some platforms:
+macOS, FreeBSD, AIX, IRIX, Solaris.
@item
On some platforms, this API does not support timestamps past the
year 2038:
diff --git a/lib/readutmp.h b/lib/readutmp.h
index 0ddd724c22..271dd4921a 100644
--- a/lib/readutmp.h
+++ b/lib/readutmp.h
@@ -39,6 +39,28 @@
# if HAVE_UTMPX_H
+/* defines 'struct utmpx' with the following fields:
+
+ FieldType Platforms
+ -- -- -
+ ⎡ ut_user char[] glibc, musl, macOS, FreeBSD, AIX,
HP-UX, IRIX, Solaris, Cygwin
+ ⎣ ut_name char[] NetBSD, Minix
+ ut_idchar[] glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin
+ ut_line char[] glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin
+ ut_pid pid_t glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin
+ ut_type short glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin
+ ⎡ ut_tvstruct glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin
+ ⎢ { tv_sec; tv_usec; }
+ ⎣ ut_time time_t Cygwin
+ ut_host char[] glibc, musl, macOS, FreeBSD,
NetBSD, Minix, AIX, HP-UX, IRIX, Solaris, Cygwin
+ ut_exit struct glibc, musl, N
Re: [PATCH] getusershell: Work around musl bugs.
Collin Funk wrote: > + getusershell: Work around musl bugs. > + Reported by Bruno Haible in > + <https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00261.html>. > + * doc/glibc-functions/getusershell.texi: Mention the musl bug. > + * lib/unistd.in.h (getusershell, setusershell, endusershell): Allow the > + functions to be declared with the rpl_ prefix. > + * m4/getusershell.m4 (gl_FUNC_GETUSERSHELL): Prepare functions to be > + replaced on musl systems. > + (gl_PREREQ_GETUSERSHELL): New macro. > + * m4/unistd_h.m4 (gl_UNISTD_H_DEFAULTS): Initialize > + REPLACE_GETUSERSHELL. > + * modules/getusershell (Depends-on): Update module conditions to account > + for the function being available but replaced by Gnulib. > + (configure.ac): Likewise. Invoke gl_PREREQ_GETUSERSHELL. Perfect. Thanks a lot! Bruno
Re: stdioext on musl
On 06/17/2012 02:56 PM, Rich Felker wrote: >> 1) Currently, gnulib has to go to a great length to detect musl. >>It uses the presence of __stdio_read and __stdio_write as an indicator; > That's not valid. These are internal functions that could be renamed > or disappear (e.g. be changed to visibility=hidden) at any time. OK, so why not change musl to define a symbol like __MUSL__ that will make gnulib's job easier? The arguments given so far against such a symbol seem to be based primarily on theoretical objections, which don't have much practical force. The argument for having a symbol is based on real code that we need to write. > will configure even find them? Yes, it can be made to find them, as part of gnulib. > a big part of musl's design goal has been to avoid implementation > lock-in caused by exposing internals to applications. And a big part of gnulib's design goal is to provide useful functionality that is portable and efficient on practical systems. These goals clash. Sorry, but that's life. Now, we have to decide what to do about it. To us, conforming to the standard is merely a means towards writing portable and efficient software. If not-conforming to the standard achieves the goal better, then we will fail to conform to the standard. For us, standards are our servants, not our masters. This is a pragmatic approach that works well in practice. Bruno has ported it to musl too, which is a good thing. It would be nicer if the port used "approved" musl interfaces, but if musl can't or won't do that we'll just have to continue to poke under musl's covers to get the behavior that we want, just like we do with many other libraries. If these libraries change in the future, gnulib will too. But it would be better if musl provided better interfaces for this useful functionality; as that would make gnulib-based applications more likely to port to future musl implementations without hassle.
Re: stdioext on musl
On Sun, Jun 17, 2012 at 03:44:16PM -0700, Paul Eggert wrote: > > will configure even find them? > > Yes, it can be made to find them, as part of gnulib. I mean will it find them without needing a special macro like __MUSL__? > This is a pragmatic approach that works well in practice. Bruno has > ported it to musl too, which is a good thing. It would be nicer if > the port used "approved" musl interfaces, but if musl can't or won't I already said, if gnulib can find and use these interfaces by testing that they exist and work, rather than by asking "is this musl?", I'm (reluctantly) willing to add them. Mainly because I'd like to be done with the "fighting with gnulib" issue that's made trouble for me and my userbase from day one... > do that we'll just have to continue to poke under musl's covers to get > the behavior that we want, just like we do with many other libraries. > If these libraries change in the future, gnulib will too. But it would Please don't do this. I'd rather just keep private interfaces private by having civil discussions with developers who try to use them and finding a mutually agreeable alternative, but if software starts seriously trying to use musl internals, I'm going to update the build process to make them all hidden and then a new solution will be required anyway. This isn't for the sake of fighting; it's because I don't want users' systems to break when they upgrade libc and suddenly a lot of software aborts with dynamic linking errors because it was using a private symbol that was exposed for a long time then later changed or removed... > be better if musl provided better interfaces for this useful functionality; > as that would make gnulib-based applications more likely to port to > future musl implementations without hassle. Can you explain what you mean? By "better interfaces" do you mean the 4 already-mentioned stdio extension functions, or something else? Rich
Re: Alpine: useless-if-before-free: Exec format error
>Since xargs happens to use execvp(), the executable gets executed by "a >known command interpreter". This command interpreter might be sh, python, >emacs, or whatever. > > So, the *omission* of #! renders a script non-portable, when that script is > invoked like an executable. Anyway, there seems to be an agreement that execvp() needs to execute scripts through a command interpreter, unlike execv(). * The glibc source code does so, see glibc/posix/execvpe.c. Also the description of this commit: https://sourceware.org/git/?p=glibc.git;a=commit;h=283d98512272a12cb84e7798c23edbdf1adb287d * The musl author agrees as well: https://www.openwall.com/lists/musl/2018/03/09/1 https://www.openwall.com/lists/musl/2018/03/09/2 https://www.openwall.com/lists/musl/2018/03/11/1 So, the ENOEXEC error is a bug in musl. But POSIX does not specify that the command interpreter for scripts without shebang is /bin/sh; therefore IMHO it would be good not to make this assumption. Bruno
Re: [musl] Re: musl, printf out-of-memory test
On Tue, Jun 19, 2012 at 12:45:50PM +0200, Bruno Haible wrote: > So, the exit code 1 must have come from the crash handler. Without this crash > handler: 7x I get > > configure:8919: checking whether printf survives out-of-memory conditions > configure:8979: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2 > -Wall conftest.c >&5 > configure:8982: $? = 0 > printf's return value = 502, errno = 0 > configure:8986: $? = 0 > configure:9031: result: yes > > but once I get > > configure:8979: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2 > -Wall conftest.c >&5 > configure:8982: $? = 0 > configure:8986: $? = 139 > configure:9031: result: no > > So, apparently, under memory stress, musl's printf has a probability of > between 10% and 50% of crashing with SIGSEGV (139 = 128 + 11). musl's printf does not do anything with memory except using a small constant amount of stack space (a few hundred bytes for non-float, somewhere around 5-7k for floating point). This is completely independent of the width/padding/precision; the implementation actually goes to a good bit of trouble to ensure that it can print any amount of padding efficiently without large or unbounded stack space usage. Is there any way the rlimits put in place could be preventing the stack from expanding beyond even one page the current number of pages, etc.? Rich
remainderl: Work around musl libc bug
remainderl lacks precision on musl libc 1.2.2/arm64, musl libc 1.2.2/s390x.
This leads to a test failure:
../../gltests/test-remainder.h:54: assertion '(z > - L_(2.0) * L_(16.0) /
TWO_MANT_DIG && z < L_(2.0) * L_(16.0) / TWO_MANT_DIG) || (z > y - L_(2.0) *
L_(16.0) / TWO_MANT_DIG && z < y + L_(2.0) * L_(16.0) / TWO_MANT_DIG) || (z > -
y - L_(2.0) * L_(16.0) / TWO_MANT_DIG && z < - y + L_(2.0) * L_(16.0) /
TWO_MANT_DIG)' failed
Aborted
FAIL test-remainderl (exit status: 134)
This patch adds a configure test, that enables a gnulib workaround.
2021-01-31 Bruno Haible
remainderl: Work around musl libc bug.
* doc/posix-functions/remainderl.texi: Document musl libc bug.
* m4/remainderl.m4 (gl_FUNC_REMAINDERL_WORKS): Add more tests. Update
cross compilation guess.
diff --git a/doc/posix-functions/remainderl.texi
b/doc/posix-functions/remainderl.texi
index e1b439f..1a8f625 100644
--- a/doc/posix-functions/remainderl.texi
+++ b/doc/posix-functions/remainderl.texi
@@ -17,6 +17,10 @@ IRIX 6.5.
@item
This function returns completely wrong values on some platforms:
OpenBSD 5.1/SPARC.
+@item
+This function produces results which are accurate to only 16 digits on some
+platforms:
+musl libc 1.2.2/arm64, musl libc 1.2.2/s390x.
@end itemize
Portability problems fixed by Gnulib module @code{remainderl-ieee}:
diff --git a/m4/remainderl.m4 b/m4/remainderl.m4
index 395ad2a..4867f9c 100644
--- a/m4/remainderl.m4
+++ b/m4/remainderl.m4
@@ -1,4 +1,4 @@
-# remainderl.m4 serial 12
+# remainderl.m4 serial 13
dnl Copyright (C) 2012-2021 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -153,6 +153,7 @@ int main (int argc, char *argv[])
dnl Test whether remainderl() works.
dnl It produces completely wrong values on OpenBSD 5.1/SPARC.
+dnl On musl 1.2.2/{arm64,s390x}, the result is accurate to only 16 digits.
AC_DEFUN([gl_FUNC_REMAINDERL_WORKS],
[
AC_REQUIRE([AC_PROG_CC])
@@ -164,33 +165,90 @@ AC_DEFUN([gl_FUNC_REMAINDERL_WORKS],
#ifndef __NO_MATH_INLINES
# define __NO_MATH_INLINES 1 /* for glibc */
#endif
+#include
#include
+/* Override the values of , like done in float.in.h. */
+#if defined __i386__ && (defined __BEOS__ || defined __OpenBSD__)
+# undef LDBL_MANT_DIG
+# define LDBL_MANT_DIG 64
+# undef LDBL_MIN_EXP
+# define LDBL_MIN_EXP(-16381)
+# undef LDBL_MAX_EXP
+# define LDBL_MAX_EXP16384
+#endif
+#if defined __i386__ && (defined __FreeBSD__ || defined __DragonFly__)
+# undef LDBL_MANT_DIG
+# define LDBL_MANT_DIG 64
+# undef LDBL_MIN_EXP
+# define LDBL_MIN_EXP(-16381)
+# undef LDBL_MAX_EXP
+# define LDBL_MAX_EXP16384
+#endif
+#if (defined _ARCH_PPC || defined _POWER) && defined _AIX && (LDBL_MANT_DIG ==
106) && defined __GNUC__
+# undef LDBL_MIN_EXP
+# define LDBL_MIN_EXP DBL_MIN_EXP
+#endif
+#if defined __sgi && (LDBL_MANT_DIG >= 106)
+# undef LDBL_MANT_DIG
+# define LDBL_MANT_DIG 106
+# if defined __GNUC__
+# undef LDBL_MIN_EXP
+# define LDBL_MIN_EXP DBL_MIN_EXP
+# endif
+#endif
extern
#ifdef __cplusplus
"C"
#endif
long double remainderl (long double, long double);
-volatile long double x;
-volatile long double y;
-long double z;
-int main ()
+static long double dummy (long double x, long double y) { return 0; }
+volatile long double gx;
+volatile long double gy;
+long double gz;
+int main (int argc, char *argv[])
{
+ long double (* volatile my_remainderl) (long double, long double) =
+argc ? remainderl : dummy;
+ int result = 0;
/* This test fails on OpenBSD 5.1/SPARC. */
- x = 9.245907126L;
- y = 3.141592654L;
- z = remainderl (x, y);
- if (z >= 0.0L)
-return 1;
- return 0;
+ {
+gx = 9.245907126L;
+gy = 3.141592654L;
+ gz = remainderl (gx, gy);
+if (gz >= 0.0L)
+ result |= 1;
+ }
+ /* This test fails on musl 1.2.2/arm64, musl 1.2.2/s390x. */
+ {
+const long double TWO_LDBL_MANT_DIG = /* 2^LDBL_MANT_DIG */
+ (long double) (1U << ((LDBL_MANT_DIG - 1) / 5))
+ * (long double) (1U << ((LDBL_MANT_DIG - 1 + 1) / 5))
+ * (long double) (1U << ((LDBL_MANT_DIG - 1 + 2) / 5))
+ * (long double) (1U << ((LDBL_MANT_DIG - 1 + 3) / 5))
+ * (long double) (1U << ((LDBL_MANT_DIG - 1 + 4) / 5));
+long double x = 11.357996098166760874793827872740874983168L;
+long double y = 0.486497838502717923110029188864352615388L;
+long double z = my_remainderl (x, y) - (x - 23 * y);
+long double err = z * TWO_LDBL_MANT_DIG;
+if (!(err >= -32.0L && err <= 32.0L))
+ result |= 2;
+ }
+ return result;
}
]])],
[gl_cv_func_remainderl_works=yes],
[gl_cv_func_remainderl_works=no],
[case "$host_os" in
- openbsd*) gl_cv_func_remainderl_works="guessing
Re: [PATCH] getusershell: Add tests.
On 5/17/24 6:45 AM, Bruno Haible wrote: >> It also looks like musl will return empty lines (getline () with >> length 1), which I believe is incorrect from the FreeBSD man page >> description. > > So, once you have a musl libc VM yourself, you are ready for reporting > your first musl libc bug. The reporting address is . Sounds good, thanks for the link. I'll experiment with the behavior on GNU/Linux and FreeBSD when '/etc/shells' has an empty line too. I didn't add a check for that but assuming everyone but musl passes then I'll add it. Collin
patch: stdio fiex for UnixWare
I've attached a patch to address the fact that UnixWare does not have
stdio_ext.h but has some __X() stdio helper functions.
Wrap "#include " in HAVE_STDIO_EXT_H insead of HAVE___X
--
Tim RiceMultitalents
t...@multitalents.net
diff --git a/ChangeLog b/ChangeLog
index 5c4d8f849..51e074bd3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2020-09-24 Tim Rice
+ UnixWare does not have stdio_ext.h but has some __X() stdio
+ helper functions.
+ * lib/fbufmode.c: Wrap "#include " in HAVE_STDIO_EXT_H
+ * lib/fpurge.c: Likewise.
+ * lib/freadable.h: Likewise.
+ * lib/freadahead.h: Likewise.
+ * lib/freading.h: Likewise.
+ * lib/freadptr.h: Likewise.
+ * lib/fseterr.h: Likewise.
+ * lib/fwritable.h: Likewise.
+ * lib/fwriting.h: Likewise.
+
2020-09-23 Paul Eggert
regex: fix ignore-case Turkish bug
diff --git a/lib/fbufmode.c b/lib/fbufmode.c
index 65a5cfc82..ec8afd510 100644
--- a/lib/fbufmode.c
+++ b/lib/fbufmode.c
@@ -19,7 +19,7 @@
/* Specification. */
#include "fbufmode.h"
-#if HAVE___FLBF
+#if HAVE_STDIO_EXT_H
# include
#endif
@@ -61,7 +61,7 @@ fbufmode (FILE *fp)
else
return _IONBF;
# else
-# if HAVE___FLBF /* Solaris >= 7 */
+# if HAVE___FLBF /* Solaris >= 7, UnixWare 7.1.4 >= MP4 */
if (__flbf (fp))
return _IOLBF;
# else
diff --git a/lib/fpurge.c b/lib/fpurge.c
index f05da5abb..2af81a605 100644
--- a/lib/fpurge.c
+++ b/lib/fpurge.c
@@ -19,7 +19,7 @@
/* Specification. */
#include
-#if HAVE___FPURGE /* glibc >= 2.2, Haiku, Solaris >= 7,
Android API >= 23 */
+#if HAVE_STDIO_EXT_H/* glibc >= 2.2, Haiku, Solaris >= 7,
Android API >= 23 */
# include
#endif
#include
@@ -29,7 +29,7 @@
int
fpurge (FILE *fp)
{
-#if HAVE___FPURGE /* glibc >= 2.2, Haiku, Solaris >= 7,
Android API >= 23, musl libc */
+#if HAVE___FPURGE /* glibc >= 2.2, Haiku, Solaris >= 7,
Android API >= 23, musl libc, UnixWare 7.1.4 >= MP4 */
__fpurge (fp);
/* The __fpurge function does not have a return value. */
diff --git a/lib/freadable.h b/lib/freadable.h
index 5a17e4a03..c664b7d26 100644
--- a/lib/freadable.h
+++ b/lib/freadable.h
@@ -22,9 +22,11 @@
STREAM must not be wide-character oriented.
The result doesn't change until the stream is closed or re-opened. */
-#if HAVE___FREADABLE /* glibc >= 2.2, Solaris >= 7, Android API >= 23, musl
libc */
+#if HAVE___FREADABLE /* glibc >= 2.2, Solaris >= 7, Android API >= 23, musl
libc, UnixWare 7.1.4 >= MP4 */
-# include
+# if HAVE_STDIO_EXT_H
+# include
+# endif
# define freadable(stream) (__freadable (stream) != 0)
#else
diff --git a/lib/freadahead.h b/lib/freadahead.h
index b971d5a06..d76b306ac 100644
--- a/lib/freadahead.h
+++ b/lib/freadahead.h
@@ -29,7 +29,9 @@
#if HAVE___FREADAHEAD /* musl libc */
-# include
+# if HAVE_STDIO_EXT_H
+# include
+# endif
# define freadahead(stream) __freadahead (stream)
#else
diff --git a/lib/freading.h b/lib/freading.h
index 6c5592ec0..11deadc2d 100644
--- a/lib/freading.h
+++ b/lib/freading.h
@@ -33,9 +33,11 @@
STREAM must not be wide-character oriented. */
#if HAVE___FREADING && (!defined __GLIBC__ || defined __UCLIBC__ || __GLIBC__
> 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 7))
-/* Solaris >= 7, Android API >= 29, not glibc >= 2.2, but glibc >= 2.7, or
musl libc */
+/* Solaris >= 7, Android API >= 29, not glibc >= 2.2, but glibc >= 2.7, or
musl libc, UnixWare 7.1.4 >= MP4 */
-# include
+# if HAVE_STDIO_EXT_H
+# include
+# endif
# define freading(stream) (__freading (stream) != 0)
#else
diff --git a/lib/freadptr.h b/lib/freadptr.h
index 07d2d727d..fc91a0b32 100644
--- a/lib/freadptr.h
+++ b/lib/freadptr.h
@@ -30,7 +30,9 @@
#if HAVE___FREADPTR /* musl libc */
-# include
+# if HAVE_STDIO_EXT_H
+# include
+# endif
# define freadptr(stream,sizep) __freadptr (stream, sizep)
#else
diff --git a/lib/fseterr.h b/lib/fseterr.h
index bbeb6619f..81ca5b4d2 100644
--- a/lib/fseterr.h
+++ b/lib/fseterr.h
@@ -25,7 +25,9 @@
#if HAVE___FSETERR /* musl libc */
-# include
+# if HAVE_STDIO_EXT_H
+# include
+# endif
# define fseterr(fp) __fseterr (fp)
#else
diff --git a/lib/fwritable.h b/lib/fwritable.h
index 44c760cf3..d8a705d34 100644
--- a/lib/fwritable.h
+++ b/lib/fwritable.h
@@ -22,9 +22,11 @@
STREAM must not be wide-character oriented.
The result doesn't change until the stream is closed or re-opened. */
-#if HAVE___FWRITABLE /* glibc >= 2.2, Solaris >= 7, Android API >= 23, musl
libc */
+#if HAVE___FWRITABLE /* glibc >= 2.2, Solaris >= 7, Android API >= 23, musl
libc, UnixWare 7.1.4 >= MP4 */
-# include
+# if HAVE_STD
vasnwprintf: Fix test failures on musl libc
On musl libc, test-vasnwprintf-posix fails. This is due to two musl libc bugs:
https://www.openwall.com/lists/musl/2023/03/19/1
https://www.openwall.com/lists/musl/2023/03/20/1
As a workaround, on this platform, vasnwprintf needs to
- avoid %n,
- do the padding itself, instead of leaving it to the swprintf primitive.
2023-03-19 Bruno Haible
vasnwprintf: Fix test failures on musl libc.
* m4/vasnprintf.m4 (gl_PREREQ_VASNWPRINTF): Invoke gl_MUSL_LIBC.
* lib/vasnprintf.c (VASNPRINTF): On musl libc, when WIDE_CHAR_VERSION,
- force pad_ourselves to be 1,
- don't use %n.
Fix zero-padding when the result starts with a prefix "0x" or "0b".
* modules/vasnwprintf (Files): Add musl.m4.
* doc/posix-functions/swprintf.texi: Mention two musl libc bugs.
diff --git a/doc/posix-functions/swprintf.texi
b/doc/posix-functions/swprintf.texi
index 906ee521aa..a87bc06c86 100644
--- a/doc/posix-functions/swprintf.texi
+++ b/doc/posix-functions/swprintf.texi
@@ -26,11 +26,21 @@
glibc when used with @code{_FORTIFY_SOURCE >= 2} (set by default on Ubuntu),
macOS 11.1, MSVC 14.
@item
+This function sometimes returns a wrong value through the @samp{n} directive
+on some platforms:
+@c https://www.openwall.com/lists/musl/2023/03/19/1
+musl libc 1.2.3.
+@item
On Windows and 32-bit AIX platforms, @code{wchar_t} is a 16-bit type and
therefore cannot
accommodate all Unicode characters.
@item
On Windows, this function does not take a buffer size as second argument.
@item
+This function ignores the minimum field width in the @samp{lc} directive
+on some platforms:
+@c https://www.openwall.com/lists/musl/2023/03/20/1
+musl libc 1.2.3.
+@item
This function does not support the @samp{b} directive, required by ISO C23,
on some platforms:
glibc 2.34, musl libc, macOS 12.5, FreeBSD 13.1, NetBSD 9.0, OpenBSD 7.2,
diff --git a/lib/vasnprintf.c b/lib/vasnprintf.c
index c2f10cb0c4..50ff2e64dd 100644
--- a/lib/vasnprintf.c
+++ b/lib/vasnprintf.c
@@ -4932,7 +4932,7 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
{
arg_type type = a.arg[dp->arg_index].type;
int flags = dp->flags;
-#if !DCHAR_IS_TCHAR || ENABLE_UNISTDIO || NEED_PRINTF_FLAG_LEFTADJUST ||
NEED_PRINTF_FLAG_ZERO || NEED_PRINTF_UNBOUNDED_PRECISION
+#if (WIDE_CHAR_VERSION && MUSL_LIBC) || !DCHAR_IS_TCHAR || ENABLE_UNISTDIO ||
NEED_PRINTF_FLAG_LEFTADJUST || NEED_PRINTF_FLAG_ZERO ||
NEED_PRINTF_UNBOUNDED_PRECISION
int has_width;
#endif
#if !USE_SNPRINTF || WIDE_CHAR_VERSION || !HAVE_SNPRINTF_RETVAL_C99 ||
USE_MSVC__SNPRINTF || !DCHAR_IS_TCHAR || ENABLE_UNISTDIO ||
NEED_PRINTF_FLAG_LEFTADJUST || NEED_PRINTF_FLAG_ZERO ||
NEED_PRINTF_UNBOUNDED_PRECISION
@@ -4947,7 +4947,7 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
#else
# define prec_ourselves 0
#endif
-#if NEED_PRINTF_FLAG_LEFTADJUST
+#if (WIDE_CHAR_VERSION && MUSL_LIBC) || NEED_PRINTF_FLAG_LEFTADJUST
# define pad_ourselves 1
#elif !DCHAR_IS_TCHAR || ENABLE_UNISTDIO || NEED_PRINTF_FLAG_ZERO ||
NEED_PRINTF_UNBOUNDED_PRECISION
int pad_ourselves;
@@ -4964,7 +4964,7 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
TCHAR_T *tmp;
#endif
-#if !DCHAR_IS_TCHAR || ENABLE_UNISTDIO || NEED_PRINTF_FLAG_LEFTADJUST ||
NEED_PRINTF_FLAG_ZERO || NEED_PRINTF_UNBOUNDED_PRECISION
+#if (WIDE_CHAR_VERSION && MUSL_LIBC) || !DCHAR_IS_TCHAR || ENABLE_UNISTDIO ||
NEED_PRINTF_FLAG_LEFTADJUST || NEED_PRINTF_FLAG_ZERO ||
NEED_PRINTF_UNBOUNDED_PRECISION
has_width = 0;
#endif
#if !USE_SNPRINTF || WIDE_CHAR_VERSION || !HAVE_SNPRINTF_RETVAL_C99 ||
USE_MSVC__SNPRINTF || !DCHAR_IS_TCHAR || ENABLE_UNISTDIO ||
NEED_PRINTF_FLAG_LEFTADJUST || NEED_PRINTF_FLAG_ZERO ||
NEED_PRINTF_UNBOUNDED_PRECISION
@@ -4995,7 +4995,7 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
width = xsum (xtimes (width, 10), *digitp++ - '0');
while (digitp != dp->width_end);
}
-#if !DCHAR_IS_TCHAR || ENABLE_UNISTDIO || NEED_PRINTF_FLAG_LEFTADJUST ||
NEED_PRINTF_FLAG_ZERO || NEED_PRINTF_UNBOUNDED_PRECISION
+#if (WIDE_CHAR_VERSION && MUSL_LIBC) || !DCHAR_IS_TCHAR || ENABLE_UNISTDIO ||
NEED_PRINTF_FLAG_LEFTADJUST || NEED_PRINTF_FLAG_ZERO ||
NEED_PRINTF_UNBOUNDED_PRECISION
has_width = 1;
#endif
}
@@ -5050,7 +5050,7 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
#endif
/* Decide whether to perform the padding ourselves. */
-#if !NEED_PRINTF_FLAG_LEFTADJUST && (!DCHAR_IS_TCHAR || ENABLE_UNISTDIO ||
NEED_PRINTF_FLAG_ZERO || NEED_PRINTF_UNBOUNDED_PRECISION)
+#if !((WIDE_CHAR_VERSION && MUSL_LIBC) || NEED_PRINTF_FLAG_LEFTADJUST) &&
(!DCHAR_IS_TCHAR || ENABLE_UNISTDIO || NEED_PRINTF_FLAG_ZERO |
posix_spawn_file_actions_add* functions on musl libc
The gnulib configure test in m4/posix_spawn.m4, when run on Alpine Linux 3.7,
determines that the posix_spawn_file_actions_add* functions do not fail as
expected for an out-of-range file descriptor.
Let me document this in gnulib and update the cross-compilation guess
accordingly.
Rich, FYI: These are the test programs:
#include
int main ()
{
posix_spawn_file_actions_t actions;
if (posix_spawn_file_actions_init (&actions) != 0)
return 1;
if (posix_spawn_file_actions_addclose (&actions, 1000) == 0)
return 2;
return 0;
}
#include
int main ()
{
posix_spawn_file_actions_t actions;
if (posix_spawn_file_actions_init (&actions) != 0)
return 1;
if (posix_spawn_file_actions_adddup2 (&actions, 1000, 2) == 0)
return 2;
return 0;
}
#include
#include
int main ()
{
posix_spawn_file_actions_t actions;
if (posix_spawn_file_actions_init (&actions) != 0)
return 1;
if (posix_spawn_file_actions_addopen (&actions, 1000, "foo", 0, O_RDONLY)
== 0)
return 2;
return 0;
}
2019-03-23 Bruno Haible
posix_spawn_file_actions_*: Document musl libc bugs.
* doc/posix-functions/posix_spawn_file_actions_addclose.texi: Mention
the bug.
* doc/posix-functions/posix_spawn_file_actions_adddup2.texi: Likewise.
* doc/posix-functions/posix_spawn_file_actions_addopen.texi: Likewise.
* m4/posix_spawn.m4 (gl_FUNC_POSIX_SPAWN_FILE_ACTIONS_ADDCLOSE): When
cross-compiling to a musl system, guess no.
(gl_FUNC_POSIX_SPAWN_FILE_ACTIONS_ADDDUP2): Likewise.
(gl_FUNC_POSIX_SPAWN_FILE_ACTIONS_ADDOPEN): Likewise.
diff --git a/doc/posix-functions/posix_spawn_file_actions_addclose.texi
b/doc/posix-functions/posix_spawn_file_actions_addclose.texi
index 199daa1..80418db 100644
--- a/doc/posix-functions/posix_spawn_file_actions_addclose.texi
+++ b/doc/posix-functions/posix_spawn_file_actions_addclose.texi
@@ -13,7 +13,7 @@ This function is missing on some platforms:
Mac OS X 10.4, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1,
HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 9, Cygwin, mingw, MSVC 14, Interix 3.5,
BeOS, Android 8.1.
@item
This function does not reject a too large file descriptor on some platforms:
-Solaris 11.4.
+musl libc, Solaris 11.4.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/doc/posix-functions/posix_spawn_file_actions_adddup2.texi
b/doc/posix-functions/posix_spawn_file_actions_adddup2.texi
index e515715..985d6bc 100644
--- a/doc/posix-functions/posix_spawn_file_actions_adddup2.texi
+++ b/doc/posix-functions/posix_spawn_file_actions_adddup2.texi
@@ -13,7 +13,7 @@ This function is missing on some platforms:
Mac OS X 10.4, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1,
HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 9, Cygwin, mingw, MSVC 14, Interix 3.5,
BeOS, Android 8.1.
@item
This function does not reject a too large file descriptor on some platforms:
-Solaris 11.4.
+musl libc, Solaris 11.4.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/doc/posix-functions/posix_spawn_file_actions_addopen.texi
b/doc/posix-functions/posix_spawn_file_actions_addopen.texi
index a7809cf..eea56e3 100644
--- a/doc/posix-functions/posix_spawn_file_actions_addopen.texi
+++ b/doc/posix-functions/posix_spawn_file_actions_addopen.texi
@@ -13,7 +13,7 @@ This function is missing on some platforms:
Mac OS X 10.4, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1,
HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 9, Cygwin, mingw, MSVC 14, Interix 3.5,
BeOS, Android 8.1.
@item
This function does not reject a too large file descriptor on some platforms:
-Solaris 11.4.
+musl libc, Solaris 11.4.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/m4/posix_spawn.m4 b/m4/posix_spawn.m4
index 1e2533c..d50dcc9 100644
--- a/m4/posix_spawn.m4
+++ b/m4/posix_spawn.m4
@@ -1,4 +1,4 @@
-# posix_spawn.m4 serial 15
+# posix_spawn.m4 serial 16
dnl Copyright (C) 2008-2019 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -422,8 +422,8 @@ AC_DEFUN([gl_FUNC_POSIX_SPAWN_FILE_ACTIONS_ADDCLOSE],
if test $REPLACE_POSIX_SPAWN = 1; then
REPLACE_POSIX_SPAWN_FILE_ACTIONS_ADDCLOSE=1
else
-dnl On Solaris 11.0, posix_spawn_file_actions_addclose succeeds even
-dnl if the fd argument is out of range.
+dnl On musl libc and Solaris 11.0, posix_spawn_file_actions_addclose
+dnl succeeds even if the fd argument is out of range.
AC_CACHE_CHECK([whether posix_spawn_file_actions_addclose works],
[gl_cv_func_posix_spawn_file_actions_addclose_works],
[AC_RUN_IFELSE(
@@ -440,8 +440,9 @@ int main ()
}]])],
[gl_cv_func_posix_spawn_file_actions_addclose_works=yes],
[gl_cv_func_posix_spawn_file_actions_addclose_works=no],
- [# Guess no on Solaris, yes otherw
vasnwprintf-posix: Work around two musl libc bugs
The attached three patches fix
1) a few wrong cross-compilation guesses,
2) a test-vasnwprintf-posix failure on Alpine Linux 3.18 (musl libc 1.2.4):
FAIL: test-vasnwprintf-posix
../../gltests/test-vasnwprintf-posix.c:3999: assertion 'result != NULL' failed
Aborted
FAIL test-vasnwprintf-posix (exit status: 134)
3) another failure of test-vasnwprintf-posix on Alpine Linux 3.18 (musl libc
1.2.4), once the previous one is fixed:
FAIL: test-vasnwprintf-posix
../../gltests/test-vasnwprintf-posix.c:4074: assertion 'result != NULL' failed
Aborted
FAIL test-vasnwprintf-posix (exit status: 134)
These two failures occurred in with musl libc 1.2.4 but not with
musl libc 1.2.3 because in 1.2.4 HAVE_WORKING_SWPRINTF gets defined
to 1 and thus the vasnwprintf implementation is based on swprintf rather
than snprintf. In other words, The vasnwprintf implementation now takes
a different code path, one that is sensitive to all kinds of swprintf
bugs.
2023-06-12 Bruno Haible
vasnwprintf-posix: Work around another musl libc bug.
* m4/printf.m4 (gl_SWPRINTF_DIRECTIVE_LC): New macro.
* m4/vasnprintf.m4 (gl_PREREQ_VASNWPRINTF): Invoke it, and set
NEED_WPRINTF_DIRECTIVE_LC if the %lc test failed.
* lib/vasnprintf.c (VASNPRINTF): If NEED_WPRINTF_DIRECTIVE_LC is set, do
the processing for %lc and %ls ourselves.
(local_wcslen): Update condition.
* doc/posix-functions/swprintf.texi: Mention the %lc problem.
2023-06-12 Bruno Haible
vasnwprintf-posix: Work around a musl libc bug.
* m4/vasnprintf.m4 (gl_PREREQ_VASNWPRINTF): Test also whether swprintf
in the C locale is free of encoding errors, and set
NEED_WPRINTF_DIRECTIVE_C if not.
* doc/posix-functions/swprintf.texi: Clarify the list of platforms for
the %c problem.
2023-06-12 Bruno Haible
vasnwprintf: Fix some cross-compilation results.
* m4/printf.m4 (gl_SWPRINTF_WORKS): Fix cross-compilation result for
musl.
(gl_SWPRINTF_DIRECTIVE_LA): Fix cross-compilation result for Android.
>From 8f0241490d9cd2b3a1eb43a0d2680fe857b7fc8d Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Mon, 12 Jun 2023 15:07:40 +0200
Subject: [PATCH 1/3] vasnwprintf: Fix some cross-compilation results.
* m4/printf.m4 (gl_SWPRINTF_WORKS): Fix cross-compilation result for
musl.
(gl_SWPRINTF_DIRECTIVE_LA): Fix cross-compilation result for Android.
---
ChangeLog| 7 +++
m4/printf.m4 | 10 +-
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 32b21f1a93..406170ce6d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2023-06-12 Bruno Haible
+
+ vasnwprintf: Fix some cross-compilation results.
+ * m4/printf.m4 (gl_SWPRINTF_WORKS): Fix cross-compilation result for
+ musl.
+ (gl_SWPRINTF_DIRECTIVE_LA): Fix cross-compilation result for Android.
+
2023-06-12 Bruno Haible
warnings: Save memory and CPU time when inhibiting all warnings.
diff --git a/m4/printf.m4 b/m4/printf.m4
index efb85a57af..509f3affb7 100644
--- a/m4/printf.m4
+++ b/m4/printf.m4
@@ -1,4 +1,4 @@
-# printf.m4 serial 82
+# printf.m4 serial 83
dnl Copyright (C) 2003, 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,
@@ -1906,7 +1906,7 @@ AC_DEFUN([gl_SWPRINTF_WORKS]
int main()
{
int result = 0;
- { /* This test fails on musl, FreeBSD, NetBSD, OpenBSD, macOS, AIX. */
+ { /* This test fails on musl libc 1.2.3, FreeBSD, NetBSD, OpenBSD, macOS, AIX. */
wchar_t buf[5] = { 0xBEEF, 0xBEEF, 0xBEEF, 0xBEEF, 0xBEEF };
int ret = swprintf (buf, 4, L"%cz", '\0');
/* Expected result:
@@ -1937,7 +1937,7 @@ AC_DEFUN([gl_SWPRINTF_WORKS]
# Guess yes on glibc systems.
*-gnu* | gnu*) gl_cv_func_swprintf_works="guessing yes";;
# Guess no on musl systems.
- *-musl* | midipix*) gl_cv_func_swprintf_works="guessing yes";;
+ *-musl* | midipix*) gl_cv_func_swprintf_works="guessing no";;
# Guess no on FreeBSD, NetBSD, OpenBSD, macOS, AIX.
freebsd* | midnightbsd* | netbsd* | openbsd* | darwin* | aix*)
gl_cv_func_swprintf_works="guessing no";;
@@ -1999,8 +1999,8 @@ AC_DEFUN([gl_SWPRINTF_DIRECTIVE_LA]
# Guess yes on musl systems.
*-musl* | midipix*) gl_cv_func_swprintf_directive_la="guessing yes";;
# Guess yes on Android.
- linux*-android*) gl_cv_func_swprintf_directive_la="guessing no";;
- # Guess yes on native Windows.
+ linux*-android*)
Re: [musl] Re: parse-datetime test failure
On Wed, Nov 11, 2020 at 07:38:00PM -0800, Paul Eggert wrote: > On 11/11/20 8:20 AM, Bruno Haible wrote: > >It works fine on Alpine Linux 3.7 (32-bit, 64-bit) and 3.9 (64-bit). > > > >On Alpine Linux 3.10 and 3.12 (64-bit) it fails: > >../../gltests/test-parse-datetime.c:448: assertion 'result.tv_sec == 1 * 60 > >* 60 + 2 * 60 + 3 && result.tv_nsec == 123456789' failed > >Aborted > > > >So, to me it looks like a regression between Alpine Linux 3.9 and 3.10. > > It's arguably a bug in the test case, since Alpine uses musl libc > which does not support time zone abbreviations longer than 6 bytes, > whereas the test case uses an time zone abbreviation of 2000 bytes > (to test a bug in an old Gnulib version when running on GNU/Linux). > POSIX does not define behavior if you go over the limit. > > I worked around the problem by changing the test case to not go over > the limit as determined by sysconf (_SC_TZNAME_MAX), in the first > attached patch. Plus I refactored and/or slightly improved the > Gnulib overflow checking while I was in the neighborhood (last two > attached patches). > > Arguably this is a quality-of-implementation issue here, since > Alpine and/or musl goes beserk with long timezone abbreviations > whereas every other implementation I know of either works or > silently substitutes localtime or UTC (which is good enough for this > test case). But I'll leave that issue to the Alpine and/or musl libc > folks. > > I'll cc this to the musl bug reporting list. Although the Gnulib > test failure has been fixed, it may be the symptom of a more-severe > bug in musl. For those new to the problem, this thread starts here: > > https://lists.gnu.org/r/bug-gnulib/2020-11/msg00039.html Thanks. I believe you've just re-discovered a known bug that's fixed in musl commit 8ebc853d37c80f0f236cc7a92cb0acc6aace, which will be included in the upcoming 1.2.2 release. Rich
Add test case from a past musl libc bug
There was a bug in the 'strstr' in musl libc, fixed in 2014. I'm adding
the test case to the test suite here, just in case someone copied the old
musl libc code and is still using it somewhere.
2023-03-27 Bruno Haible
Add test case from a past musl libc bug.
* tests/test-strstr.c (main): Add test of periodic needle.
* tests/test-strcasestr.c (main): Likewise.
* tests/test-c-strstr.c (main): Likewise.
* tests/test-c-strcasestr.c (main): Likewise.
* tests/test-memmem.c (main): Likewise.
diff --git a/tests/test-c-strcasestr.c b/tests/test-c-strcasestr.c
index 818f5a994b..4f0a6c262a 100644
--- a/tests/test-c-strcasestr.c
+++ b/tests/test-c-strcasestr.c
@@ -238,6 +238,14 @@ main ()
free (haystack);
}
+ /* Test case from Yves Bastide.
+ <https://www.openwall.com/lists/musl/2014/04/18/2> */
+ {
+const char input[] = "playing PLAY play PLAY always";
+const char *result = c_strcasestr (input, "play PLAY play");
+ASSERT (result == input + 8);
+ }
+
/* Test long needles. */
{
size_t m = 1024;
diff --git a/tests/test-c-strstr.c b/tests/test-c-strstr.c
index d8f8465b29..30070d70a4 100644
--- a/tests/test-c-strstr.c
+++ b/tests/test-c-strstr.c
@@ -212,6 +212,14 @@ main ()
free (haystack);
}
+ /* Test case from Yves Bastide.
+ <https://www.openwall.com/lists/musl/2014/04/18/2> */
+ {
+const char input[] = "playing play play play always";
+const char *result = c_strstr (input, "play play play");
+ASSERT (result == input + 8);
+ }
+
/* Test long needles. */
{
size_t m = 1024;
diff --git a/tests/test-memmem.c b/tests/test-memmem.c
index 0daf3b07e7..589210f4a2 100644
--- a/tests/test-memmem.c
+++ b/tests/test-memmem.c
@@ -292,6 +292,14 @@ main (int argc, char *argv[])
free (haystack);
}
+ /* Test case from Yves Bastide.
+ <https://www.openwall.com/lists/musl/2014/04/18/2> */
+ {
+const char input[] = "playing play play play always";
+const char *result = memmem (input, strlen (input), "play play play", 14);
+ASSERT (result == input + 8);
+ }
+
/* Test long needles. */
{
size_t m = 1024;
diff --git a/tests/test-strcasestr.c b/tests/test-strcasestr.c
index 192e1569f8..c0f5111b4a 100644
--- a/tests/test-strcasestr.c
+++ b/tests/test-strcasestr.c
@@ -252,6 +252,14 @@ main ()
free (haystack);
}
+ /* Test case from Yves Bastide.
+ <https://www.openwall.com/lists/musl/2014/04/18/2> */
+ {
+const char input[] = "playing PLAY play PLAY always";
+const char *result = strcasestr (input, "play PLAY play");
+ASSERT (result == input + 8);
+ }
+
/* Test long needles. */
{
size_t m = 1024;
diff --git a/tests/test-strstr.c b/tests/test-strstr.c
index b2e00c526c..1ff9953d31 100644
--- a/tests/test-strstr.c
+++ b/tests/test-strstr.c
@@ -275,6 +275,14 @@ main (int argc, char *argv[])
free (haystack);
}
+ /* Test case from Yves Bastide.
+ <https://www.openwall.com/lists/musl/2014/04/18/2> */
+ {
+const char input[] = "playing play play play always";
+const char *result = strstr (input, "play play play");
+ASSERT (result == input + 8);
+ }
+
/* Test long needles. */
{
size_t m = 1024;
Re: musl compatibility
On 8 June 2012 11:19, Pedro Alves wrote: > I've heard such rants as well. The rants are IMO, misdirected. For instance, > IIRC, gnulib's freadahead use is caused by musl's printf not being posix > compliant, causing gnulib to pull in its printf replacement, which doesn't > work > on musl. A library that is new, actively maintained, and that calls itself > a "C/POSIX standard library" should really address that by making it's printf > posix compliant, so that gnulib's fallback doesn't even get built. It seems > that > nobody who is interested in musl has looked at gnulib's config.log to > understand > why does gnulib think musl's printf is not good enough. Thanks; I'll report that to the musl development list. -- http://rrt.sc3d.org
Re: posix_spawn_file_actions_add* functions on musl libc
On Sat, Mar 23, 2019 at 09:46:28PM +0100, Bruno Haible wrote:
> The gnulib configure test in m4/posix_spawn.m4, when run on Alpine Linux 3.7,
> determines that the posix_spawn_file_actions_add* functions do not fail as
> expected for an out-of-range file descriptor.
The POSIX "shall fail" requirement is for >=OPEN_MAX, which is not
defined (variable limit). It's not clear to me whether it's supposed
to apply if the fd number is >= the current dynamic limit reported by
sysconf(_SC_OPEN_MAX), but it seems like doing so would be undesirable
-- it would preclude advance creation of a file actions object which
will open or dup onto high fd numbers at a later time after the rlimit
has been increased.
Rich
> Let me document this in gnulib and update the cross-compilation guess
> accordingly.
>
> Rich, FYI: These are the test programs:
>
> #include
> int main ()
> {
> posix_spawn_file_actions_t actions;
> if (posix_spawn_file_actions_init (&actions) != 0)
> return 1;
> if (posix_spawn_file_actions_addclose (&actions, 1000) == 0)
> return 2;
> return 0;
> }
>
> #include
> int main ()
> {
> posix_spawn_file_actions_t actions;
> if (posix_spawn_file_actions_init (&actions) != 0)
> return 1;
> if (posix_spawn_file_actions_adddup2 (&actions, 1000, 2) == 0)
> return 2;
> return 0;
> }
>
> #include
> #include
> int main ()
> {
> posix_spawn_file_actions_t actions;
> if (posix_spawn_file_actions_init (&actions) != 0)
> return 1;
> if (posix_spawn_file_actions_addopen (&actions, 1000, "foo", 0,
> O_RDONLY)
> == 0)
> return 2;
> return 0;
> }
>
>
> 2019-03-23 Bruno Haible
>
> posix_spawn_file_actions_*: Document musl libc bugs.
> * doc/posix-functions/posix_spawn_file_actions_addclose.texi: Mention
> the bug.
> * doc/posix-functions/posix_spawn_file_actions_adddup2.texi: Likewise.
> * doc/posix-functions/posix_spawn_file_actions_addopen.texi: Likewise.
> * m4/posix_spawn.m4 (gl_FUNC_POSIX_SPAWN_FILE_ACTIONS_ADDCLOSE): When
> cross-compiling to a musl system, guess no.
> (gl_FUNC_POSIX_SPAWN_FILE_ACTIONS_ADDDUP2): Likewise.
> (gl_FUNC_POSIX_SPAWN_FILE_ACTIONS_ADDOPEN): Likewise.
>
> diff --git a/doc/posix-functions/posix_spawn_file_actions_addclose.texi
> b/doc/posix-functions/posix_spawn_file_actions_addclose.texi
> index 199daa1..80418db 100644
> --- a/doc/posix-functions/posix_spawn_file_actions_addclose.texi
> +++ b/doc/posix-functions/posix_spawn_file_actions_addclose.texi
> @@ -13,7 +13,7 @@ This function is missing on some platforms:
> Mac OS X 10.4, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1,
> HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 9, Cygwin, mingw, MSVC 14, Interix
> 3.5, BeOS, Android 8.1.
> @item
> This function does not reject a too large file descriptor on some platforms:
> -Solaris 11.4.
> +musl libc, Solaris 11.4.
> @end itemize
>
> Portability problems not fixed by Gnulib:
> diff --git a/doc/posix-functions/posix_spawn_file_actions_adddup2.texi
> b/doc/posix-functions/posix_spawn_file_actions_adddup2.texi
> index e515715..985d6bc 100644
> --- a/doc/posix-functions/posix_spawn_file_actions_adddup2.texi
> +++ b/doc/posix-functions/posix_spawn_file_actions_adddup2.texi
> @@ -13,7 +13,7 @@ This function is missing on some platforms:
> Mac OS X 10.4, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1,
> HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 9, Cygwin, mingw, MSVC 14, Interix
> 3.5, BeOS, Android 8.1.
> @item
> This function does not reject a too large file descriptor on some platforms:
> -Solaris 11.4.
> +musl libc, Solaris 11.4.
> @end itemize
>
> Portability problems not fixed by Gnulib:
> diff --git a/doc/posix-functions/posix_spawn_file_actions_addopen.texi
> b/doc/posix-functions/posix_spawn_file_actions_addopen.texi
> index a7809cf..eea56e3 100644
> --- a/doc/posix-functions/posix_spawn_file_actions_addopen.texi
> +++ b/doc/posix-functions/posix_spawn_file_actions_addopen.texi
> @@ -13,7 +13,7 @@ This function is missing on some platforms:
> Mac OS X 10.4, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1,
> HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 9, Cygwin, mingw, MSVC 14, Interix
> 3.5, BeOS, Android 8.1.
> @item
> This function does not reject a too large file descriptor on some platforms:
> -Solaris 11.4.
> +musl libc, Solaris 11.4.
> @end itemize
>
> Portability problems not fixed by Gnulib:
> diff --git a/m4/posix_spawn.m4 b/m4/posix_spawn.m4
> index 1e2533c..d50dcc9 100644
> --- a/m4/posix_spawn.m4
> +++ b/m4/posix_spa
Re: stdioext on musl
Rich Felker wrote: > > 2) Provide 4 primitive functions. > > This is less offensive at least, but will configure even find them? > Eric Blake offered to make it work that way, but you seem to want to > test against macros that identify the implementation...? If gnulib is > willing to _detect_ working functions rather than trying to detect > musl, I'd be willing, albeit reluctant, to add them. If you accept the proposed function names __freadahead, __freadptr, __freadptrinc, __fseterr, then we will start by using an autoconf check, and use the obvious conditionals like #if HAVE___FREADPTR in the code. This way, if other libcs do the same, gnulib will not have to change much. But it is in our discretion to use #ifdef __MUSL__ instead. For example, hypothetically speaking, if all other libc authors create incompatible or buggy variants of __freadptr. Then we may want to use #ifdef __MUSL__. We often, but not always, use an autoconf test that verifies that a function works. Why not always? Because such a test is ca. 20-50 lines of code, and a #ifdef is just 1 line of code. Additionally, we need the #ifdef for platforms that are cross-compilation targets (because AC_RUN_IFELSE's 4th argument is a cross-compilation guess). I believe musl is a candidate for cross-compilation, due to its small size? > > 1) Currently, gnulib has to go to a great length to detect musl. > >It uses the presence of __stdio_read and __stdio_write as an indicator; > > That's not valid. These are internal functions that could be renamed > or disappear (e.g. be changed to visibility=hidden) at any time. Yup. That's precisely why we need an indicator such as __MUSL__. > I hope it doesn't sound like I'm just being pedantic here. All along, > a big part of musl's design goal has been to avoid implementation > lock-in caused by exposing internals to applications. By keeping the > interface basically just the standard C and POSIX functions, ... You are not alone on the world. Some other people may well do the same. Then we have two libcs, which both don't identify themselves. And in real life, there are bugs that gnulib needs to work around. So gnulib needs a way to distinguish your libc from the other guys' libc. This is not hypothetical at all. The __freading, __fwriting functions exist in various libcs (glibc, Solaris, uClibc, musl). But only in musl the value is different in some particular case. Therefore I ask you to spent 1 line of code to identify musl. Or, you can contribute the two autoconf tests - written according to gnulib standards and with a reasonable cross-compilation default - that will allow gnulib to distinguish the glibc, Solaris, uClibc __freading / __fwriting functions from the musl one. > Then either test that __freading works, or use something like > > #if defined(__GLIBC__) && __GLIBC__MAJOR__ == 2 && __GLIBC_MINOR__ < 7 > > to special-case the workaround only for particular known broken > versions, and otherwise assume it works. Yes we want to assume, in general, that a function works. BUT 1) in the case of __fwriting, musl 0.9.1 is among the platforms which are "known broken" (means, not exactly like gnulib expects), 2) when cross-compiling, we would like to have a conservative guess that classifies all musl versions as "possibly bad, better not use" and all other platforms as "likely OK". For this purpose, we need a macro such as __MUSL__. Bruno
Re: bug#70104: "FAIL: test-canonicalize" coreutils v9.5 on musl libc
On 2024-03-31 12:45, Bruno Haible wrote: I think you must ask this to yourself: - What caused you to change the unit tests on 2023-09-04? - How is the musl version that you used on that date configured? What I use is Alpine Linux, as I said in versions 3.9, 3.14, 3.19. - Did you work with gnulib testdirs at that time, or did you use a package in which some modules are --avoid ed from import? Thanks for fixing the problem. I cannot now remember why I put that musl stuff in. I suspect that I got it from some tests in some other package, but don't recall which ones. I don't use musl myself.
getcwd: Fix cross-compilation guess for musl libc
On Alpine Linux 3.13/powerpcle, I see this configure test fail:
checking whether getcwd succeeds when 4k < cwd_length < 16k... no
On this platform, PATH_MAX = 4 KiB < 64 KiB = PAGESIZE. The getcwd
system call fails with error ENAMETOOLONG.
2021-01-24 Bruno Haible
getcwd: Fix cross-compilation guess for musl libc.
* m4/getcwd-abort-bug.m4 (gl_FUNC_GETCWD_ABORT_BUG): Guess no also on
musl libc.
* doc/posix-functions/getcwd.texi: Update platform info.
diff --git a/doc/posix-functions/getcwd.texi b/doc/posix-functions/getcwd.texi
index 9ca0ae3..9a4cf1e 100644
--- a/doc/posix-functions/getcwd.texi
+++ b/doc/posix-functions/getcwd.texi
@@ -38,7 +38,7 @@ Portability problems fixed by Gnulib module @code{getcwd}:
@item
This function does not handle long file names (greater than @code{PATH_MAX})
correctly on some platforms:
-glibc on Linux 2.4.20, Mac OS X 10.13, FreeBSD 6.4, NetBSD 9.0, OpenBSD 4.9,
AIX 7.1.
+glibc on Linux 2.4.20, musl libc 1.2.2/powerpc64le, Mac OS X 10.13, FreeBSD
6.4, NetBSD 9.0, OpenBSD 6.7, AIX 7.1.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/m4/getcwd-abort-bug.m4 b/m4/getcwd-abort-bug.m4
index 89d0689..bd32de1 100644
--- a/m4/getcwd-abort-bug.m4
+++ b/m4/getcwd-abort-bug.m4
@@ -1,4 +1,4 @@
-# serial 15
+# serial 16
# Determine whether getcwd aborts when the length of the working directory
# name is unusually large. Any length between 4k and 16k trigger the bug
# when using glibc-2.4.90-9 or older.
@@ -128,11 +128,12 @@ main ()
]])],
[gl_cv_func_getcwd_succeeds_beyond_4k=yes],
[dnl An abort will provoke an exit code of something like 134 (128 + 6).
-dnl An exit code of 4 can also occur (in OpenBSD 6.7, NetBSD 5.1 for
-dnl example): getcwd (NULL, 0) fails rather than returning a string
-dnl longer than PATH_MAX. This may be POSIX compliant (in some
-dnl interpretations of POSIX). But gnulib's getcwd module wants to
-dnl provide a non-NULL value in this case.
+dnl An exit code of 4 can also occur (for example in
+ dnl musl libc 1.2.2/powerpc64le, NetBSD 9.0, OpenBSD 6.7:
+dnl getcwd (NULL, 0) fails rather than returning a string longer than
+dnl PATH_MAX. This may be POSIX compliant (in some interpretations of
+dnl POSIX). But gnulib's getcwd module wants to provide a non-NULL
+dnl value in this case.
ret=$?
if test $ret -ge 128 || test $ret = 4; then
gl_cv_func_getcwd_succeeds_beyond_4k=no
@@ -141,10 +142,8 @@ main ()
fi
],
[case "$host_os" in
- # Guess yes on musl systems.
- *-musl*) gl_cv_func_getcwd_succeeds_beyond_4k="guessing yes" ;;
- # Guess no otherwise, even on glibc systems.
- *) gl_cv_func_getcwd_succeeds_beyond_4k="guessing no"
+ # Guess no otherwise, even on glibc systems and musl systems.
+ *) gl_cv_func_getcwd_succeeds_beyond_4k="guessing no"
esac
])
])
Re: [PATCH] Do not decorate symbols as dllexport on Cygwin
Corinna Vinschen wrote: > This patch will be in the next Cygwin release 3.4.6. Thanks! > I'm just a bit fuzzy what patches will be required for gnulib now... With this patch, the setlocale_null lock should be gone in Cygwin >= 3.4.6. I can't really test it, but I hope the patch is correct. 2023-02-06 Bruno Haible setlocale-null: Don't use a lock in Cygwin >= 3.4.6. Road paved by Corinna Vinschen . * m4/setlocale_null.m4 (gl_FUNC_SETLOCALE_NULL): Assume that setlocale (LC_ALL, NULL) is multithread-safe in Cygwin >= 3.4.6. * lib/setlocale_null.c: Update comments. * tests/test-setlocale_null-mt-all.c: Likewise. diff --git a/lib/setlocale_null.c b/lib/setlocale_null.c index 6ac563db14..89c8a06598 100644 --- a/lib/setlocale_null.c +++ b/lib/setlocale_null.c @@ -173,7 +173,7 @@ setlocale_null_unlocked (int category, char *buf, size_t bufsize) #endif } -#if !(SETLOCALE_NULL_ALL_MTSAFE && SETLOCALE_NULL_ONE_MTSAFE) /* musl libc, macOS, FreeBSD, NetBSD, OpenBSD, AIX, Haiku, Cygwin */ +#if !(SETLOCALE_NULL_ALL_MTSAFE && SETLOCALE_NULL_ONE_MTSAFE) /* musl libc, macOS, FreeBSD, NetBSD, OpenBSD, AIX, Haiku, Cygwin < 3.4.6 */ /* Use a lock, so that no two threads can invoke setlocale_null_unlocked at the same time. */ @@ -198,7 +198,7 @@ setlocale_null_with_lock (int category, char *buf, size_t bufsize) return ret; } -# elif HAVE_PTHREAD_API /* musl libc, macOS, FreeBSD, NetBSD, OpenBSD, AIX, Haiku, Cygwin */ +# elif HAVE_PTHREAD_API /* musl libc, macOS, FreeBSD, NetBSD, OpenBSD, AIX, Haiku, Cygwin < 3.4.6 */ extern # if defined _WIN32 || defined __CYGWIN__ diff --git a/m4/setlocale_null.m4 b/m4/setlocale_null.m4 index dd6a5ef538..b41df499a8 100644 --- a/m4/setlocale_null.m4 +++ b/m4/setlocale_null.m4 @@ -1,4 +1,4 @@ -# setlocale_null.m4 serial 6 +# setlocale_null.m4 serial 7 dnl Copyright (C) 2019-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, @@ -13,9 +13,23 @@ AC_DEFUN([gl_FUNC_SETLOCALE_NULL], AC_CACHE_CHECK([whether setlocale (LC_ALL, NULL) is multithread-safe], [gl_cv_func_setlocale_null_all_mtsafe], [case "$host_os" in - # Guess no on musl libc, macOS, FreeBSD, NetBSD, OpenBSD, AIX, Haiku, Cygwin. - *-musl* | darwin* | freebsd* | midnightbsd* | netbsd* | openbsd* | aix* | haiku* | cygwin*) + # Guess no on musl libc, macOS, FreeBSD, NetBSD, OpenBSD, AIX, Haiku. + *-musl* | darwin* | freebsd* | midnightbsd* | netbsd* | openbsd* | aix* | haiku*) gl_cv_func_setlocale_null_all_mtsafe=no ;; + # Guess no on Cygwin < 3.4.6. + cygwin*) + AC_EGREP_CPP([Lucky user], + [ +#if defined __CYGWIN__ + #include + #if CYGWIN_VERSION_DLL_COMBINED >= CYGWIN_VERSION_DLL_MAKE_COMBINED (3004, 6) + Lucky user + #endif +#endif + ], + [gl_cv_func_setlocale_null_all_mtsafe=yes], + [gl_cv_func_setlocale_null_all_mtsafe=no]) +;; # Guess yes on glibc, HP-UX, IRIX, Solaris, native Windows. *-gnu* | gnu* | hpux* | irix* | solaris* | mingw*) gl_cv_func_setlocale_null_all_mtsafe=yes ;; diff --git a/tests/test-setlocale_null-mt-all.c b/tests/test-setlocale_null-mt-all.c index 6036c260cd..7480406639 100644 --- a/tests/test-setlocale_null-mt-all.c +++ b/tests/test-setlocale_null-mt-all.c @@ -166,7 +166,7 @@ Solaris 11.0 OK Solaris 11.4 OK Solaris OpenIndiana OK Haikucrash < 1 sec -Cygwin crash < 1 sec +Cygwin < 3.4.6 crash < 1 sec mingwOK MSVC OK (assuming compiler option /MD !) */
Re: localename: add support for musl libc
Hi Rich, > Really use of NL_LOCALE_NAME should always be preferred if it's > available, since it's a clean public interface for the functionality > desired rather than a hack poking at implementation internals. But if > you really like poking at internals for other implementations ... In a perfect world, what you say would make sense. However, not all libc versions that define _NL_LOCALE_NAME also have a _NL_LOCALE_NAME that *works* [1]. It's not that I "really like poking at internals". It's that I want my code to actually work. > The comment /* musl */ above is wrong and should not have been added. How can you judge that a comment in gnulib code is adequate, when you are not familiar with the way gnulib is developed? The comment /* musl */ says two things: - If a developer makes changes to these piece of code, they should test in on a system with musl libc. - If a developer sees that this code is being compiled/executed on a system without musl libc, they should review the #if chain, to make sure no mistake was introduced in #ifs. Now back to my comment that you haven't addressed, regarding lack of __MUSL__: If someone else creates a platform that shares the same superficial characteristics (runs on Linux, has and NL_LOCALE_NAME) but behaves differently, we will accidentally run into the code intended for musl on that platform. Whereas the fallback code (return "" in this case) would be safer: it would make the unit test fail, but it would not lead to a compilation error or to a code dump. And if that platform does not have an identifiying macro either, we really got a problem how to distinguish the two. Bruno [1] https://sourceware.org/bugzilla/show_bug.cgi?id=10968
jit/cache testing done
Hi, I'm done with testing the 'jit/cache' module. It works fine on the following platforms: Architecture OSLibc ABI x86_64 Linux glibc 64 x86_64 Linux musl x86_64 Solaris 10 x86_64 Solaris 11 x86_64 macOS x86_64 Linux glibc x32 x86_64 GNU/kFreeBSD glibc x86_64 FreeBSD x86_64 NetBSD x86_64 OpenBSD x86_64 Haiku x86_64 Cygwin x86_64 Windows mingw x86_64 Windows msvc i386 Linux glibc i386 Linux musl i386 Solaris 10 i386 Solaris 11 i386 macOS i386 GNU/Hurd i386 GNU/kFreeBSD glibc i386 FreeBSD i386 NetBSD i386 OpenBSD i386 Haiku i386 Cygwin i386 Windows mingw i386 Windows msvc m68k Linux glibc mips Linux glibc 32 mips64 Linux glibc n32 mips64 Linux glibc 64 mips64 OpenBSD sparc Linux glibc sparc Solaris 10 sparc Solaris 11 sparc NetBSD sparc64Linux glibc sparc64Solaris 10 sparc64Solaris 11 sparc64FreeBSD sparc64NetBSD alpha Linux glibc hppa Linux glibc hppa NetBSD hppa OpenBSD armLinux glibc eabi armLinux glibc eabi,hf armFreeBSD armAndroid arm64 Linux glibc arm64 Linux musl arm64 macOS arm64 FreeBSD powerpcLinux glibc powerpcAIX powerpcmacOS powerpcFreeBSD powerpcNetBSD powerpc64 Linux glibc powerpc64 AIX powerpc64 FreeBSD powerpc64leLinux glibc powerpc64le Linux musl powerpc64leFreeBSD ia64 Linux glibc s390 Linux glibc s390x Linux glibc s390x Linux musl riscv32Linux glibc riscv64Linux glibc loongarch64Linux glibc Bruno
Re: [musl] Re: musl bugs found through gnulib
> [CCing the musl list]
> Isaac Dunham wrote in
> <http://lists.gnu.org/archive/html/bug-gnulib/2012-06/msg00101.html>:
>> musl is designed for standards conformance,
>
> There is a recipe, in <http://sourceware.org/glibc/wiki/Testing/Gnulib>,
> that explains how to use gnulib to check a libc against bugs.
Be warned: a bad test can cause failures as well.
It's been one of the musl developers' complaints about gnulib that the
tests are buggy and frequently check for glibc behavior instead of
standard behavior.
> When I apply this to musl-0.9.1, I get this list of problems:
>
> Replacements of *printf, because of
> checking whether printf supports infinite 'long double' arguments... no
> checking whether printf supports the 'ls' directive... no
> checking whether printf survives out-of-memory conditions... no
At least one of these (infinite long double, IIRC) is invalid or a test
for a GNU-ism. This was previously discussed on the musl ML. OOM behavior
is undefined AFAICT (feel free to point out a standard), and the scenario
is a lot less likely with musl than glibc for several reasons.
> Replacement of duplocale, because of
> checking whether duplocale(LC_GLOBAL_LOCALE) works... no
Need to check this one
> Replacement of fdopen, because of
> checking whether fdopen sets errno... no
I presume this is nonconformance to POSIX ("otherwise, a null pointer
shall be returned and errno set...")?
> Replacement of futimens, because of
> checking whether futimens works... no
Could be a bug.
> Replacement of getcwd, because of
> checking whether getcwd handles long file names properly... no, but it
> is partly working
Is this a test for ERANGE handling (error on name >= size)? Other than
that, I see no specification covering this.
> checking whether getcwd aborts when 4k < cwd_length < 16k... no
AFAICT, only required to error when size =< cwd_length. If size !<
(cwd_length + 1), that is conformant behavior. (See man 3posix getcwd)
> Replacement of getopt, because of
> checking whether getopt is POSIX compatible... no
We'd need to see this test...(will look later).
> Replacement of glob, because of
> checking for GNU glob interface version 1... no
> (not sure this is a bug or just an incompatibility compared to glibc)
Looks like an incompatability, since it specifies "GNU interface"...
> Replacement of iconv and iconv_open, because of
> checking whether iconv supports conversion between UTF-8 and
> UTF-{16,32}{BE,LE}... no
Not "nonconformant" from the standpoint of POSIX, AFAICT, but it is
incomplete. musl is UTF8 native, but I don't think it supports UTF16/UTF32
yet.
> Replacement of mktime, because of
> checking for working mktime... no
> Replacement of perror, because of
> checking whether perror matches strerror... no
> Replacement of popen, because of
> checking whether popen works with closed stdin... no
Look like bugs, if the description is correct.
> Replacement of regex, because of
> checking for working re_compile_pattern... no
This is #ifdef __USE_GNU
I'm not aware of any standard covering GNU APIs...
> Replacement of strtod, because of
> checking whether strtod obeys C99... no
>
> For each of the replacements, first look at the test program's results
> (in config.log), then look at the test program's source code (in m4/*.m4).
>
Thanks,
Isaac Dunham
Re: [musl] Re: musl bugs found through gnulib
> [CCing the musl list]
> Isaac Dunham wrote in
> <http://lists.gnu.org/archive/html/bug-gnulib/2012-06/msg00101.html>:
>> musl is designed for standards conformance,
>
> There is a recipe, in <http://sourceware.org/glibc/wiki/Testing/Gnulib>,
> that explains how to use gnulib to check a libc against bugs.
Be warned: a bad test can cause failures as well.
It's been one of the musl developers' complaints about gnulib that the
tests are buggy and frequently check for glibc behavior instead of
standard behavior.
> When I apply this to musl-0.9.1, I get this list of problems:
>
> Replacements of *printf, because of
> checking whether printf supports infinite 'long double' arguments... no
> checking whether printf supports the 'ls' directive... no
> checking whether printf survives out-of-memory conditions... no
At least one of these (infinite long double, IIRC) is invalid or a test
for a GNU-ism. This was previously discussed on the musl ML. OOM behavior
is undefined AFAICT (feel free to point out a standard), and the scenario
is a lot less likely with musl than glibc for several reasons.
> Replacement of duplocale, because of
> checking whether duplocale(LC_GLOBAL_LOCALE) works... no
Need to check this one
> Replacement of fdopen, because of
> checking whether fdopen sets errno... no
I presume this is nonconformance to POSIX ("otherwise, a null pointer
shall be returned and errno set...")?
> Replacement of futimens, because of
> checking whether futimens works... no
Could be a bug.
> Replacement of getcwd, because of
> checking whether getcwd handles long file names properly... no, but it
> is partly working
Is this a test for ERANGE handling (error on name >= size)? Other than
that, I see no specification covering this.
> checking whether getcwd aborts when 4k < cwd_length < 16k... no
AFAICT, only required to error when size =< cwd_length. If size !<
(cwd_length + 1), that is conformant behavior. (See man 3posix getcwd)
> Replacement of getopt, because of
> checking whether getopt is POSIX compatible... no
We'd need to see this test...(will look later).
> Replacement of glob, because of
> checking for GNU glob interface version 1... no
> (not sure this is a bug or just an incompatibility compared to glibc)
Looks like an incompatability, since it specifies "GNU interface"...
> Replacement of iconv and iconv_open, because of
> checking whether iconv supports conversion between UTF-8 and
> UTF-{16,32}{BE,LE}... no
Not "nonconformant" from the standpoint of POSIX, AFAICT, but it is
incomplete. musl is UTF8 native, but I don't think it supports UTF16/UTF32
yet.
> Replacement of mktime, because of
> checking for working mktime... no
> Replacement of perror, because of
> checking whether perror matches strerror... no
> Replacement of popen, because of
> checking whether popen works with closed stdin... no
Look like bugs, if the description is correct.
> Replacement of regex, because of
> checking for working re_compile_pattern... no
This is #ifdef __USE_GNU
I'm not aware of any standard covering GNU APIs...
> Replacement of strtod, because of
> checking whether strtod obeys C99... no
>
> For each of the replacements, first look at the test program's results
> (in config.log), then look at the test program's source code (in m4/*.m4).
>
Thanks,
Isaac Dunham
Re: stdioext on musl
On 06/17/2012 03:53 PM, Rich Felker wrote: > By "better interfaces" do you mean the > 4 already-mentioned stdio extension functions, or something else? Yes, I mean the functions that Bruno mentioned. > I mean will it find them without needing a special macro like > __MUSL__? Having a symbol like __MUSL__ helps simplify gnulib's job, because it needn't bother to use a heuristic like "if it has __stdio_read and __stdio_write, it must be musl", but can simply use __MUSL__ directly. If musl doesn't want to define __MUSL__, that's OK, gnulib can just define __MUSL__ on its own using that heuristic, as in Bruno's patch. If the heuristic goes wrong in some future platform, we'll fix it. This is normal; it's no big deal. That being said, it's nicer for gnulib if musl announced its presence with a symbol like __MUSL__.
gnulib changes breaks Libtasn1 4.10 build with musl
Hi, While building Libtasn1 4.10 (which uses gnulib) with musl in Yocto project, we observed this build error: ... make[4]: *** [progname.lo] Error 1 make[4]: *** Waiting for unfinished jobs In file included from TOPDIR/tmp/work/i586-poky-linux-musl/libtasn1/4.10-r0/recipe-sysroot/usr/include/endian.h:23:0, from TOPDIR/tmp/work/i586-poky-linux-musl/libtasn1/4.10-r0/recipe-sysroot/usr/include/sys/types.h:70, from ./sys/types.h:28, from ./stdio.h:58, from ../../libtasn1-4.10/gl/read-file.h:25, from ../../libtasn1-4.10/gl/read-file.c:20: ./stdint.h:89:5: error: #if with no expression #if ... (Link: http://errors.yoctoproject.org/Errors/Details/123659/ ) This appears to be an error introduced by the gnulib commit: http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=5a400b3f5a1f5483dbfd75d38bdb7080218a063b * m4/stdint.m4 (gl_STDINT_H): Don't define GNULIB_OVERRIDES_WINT_T. Reverting the changes in stdint.m4 seems to fix it. Best Regards, Maxin
Re: Why require SLOW_BUT_NO_HACKS for stubs?
On Sun, 10 Jun 2012 19:00:54 -0700 Paul Eggert wrote: > On 06/09/2012 11:05 PM, Isaac Dunham wrote: > > Is there any reason not to merge > > Performance, surely. But if there's > consensus that performance does not matter that > much with musl, perhaps we should default to the > slow version with musl. The test as it stands is "error out on unsupported platforms unless user specifies to use slow method". My proposal is "On unsupported platforms, use the slow method instead of erroring out." All supported platforms are unaffected. > Is there any simple way to tell at compile-time, > or at configure-time, that musl is being used? > That would help us distinguish musl (where being > slow is acceptable) from other platforms (which may not > want that). First, the proposal is "Run slow anywhere current code would #error", not "default to slow code". Second, officially, no. musl is designed for standards conformance, and the maintainer takes the perspective that #ifdef should be reserved for non-standard-conformant libc versions. Unofficially, I can think of a few oddities: strl* are supported with -D_BSD_SOURCE, while __linux__ will be defined; almost all symbols use the function name; only SUSv4 is supported with _XOPEN_SOURCE (so -D_XOPEN_SOURCE=600 with still gives _XOPEN_VERSION=700). None of these are guaranteed to stay the same, though no _XOPEN_VERSION less than 700 is likely to be supported. Isaac Dunham
Re: lib/fwriting.c
Tim Rice wrote:
> On line 24 of lib/fwriting.c we see
> /* This file is not used on systems that have the __fwritable function,
>
> Should that not be __fwriting instead of __fwritable ?
Indeed. Thanks for the report. Fixed as part of this larger commit:
2020-10-11 Bruno Haible
stdioext: Update comments regarding Cygwin.
* lib/fpending.c: Update comments.
* lib/fpurge.c: Likewise.
* lib/freadable.h: Likewise.
* lib/freadable.c: Likewise.
* lib/freading.h: Likewise.
* lib/freading.c: Likewise.
* lib/fwritable.h: Likewise.
* lib/fwritable.c: Likewise.
* lib/fwriting.h: Likewise.
* lib/fwriting.c: Likewise.
diff --git a/lib/fpending.c b/lib/fpending.c
index 802ebcb..4cc0ea7 100644
--- a/lib/fpending.c
+++ b/lib/fpending.c
@@ -25,7 +25,7 @@
#include "stdio-impl.h"
/* This file is not used on systems that already have the __fpending function,
- namely glibc >= 2.2, Solaris >= 7, Android API >= 23. */
+ namely glibc >= 2.2, Solaris >= 7, Cygwin >= 1.7.34, Android API >= 23. */
/* Return the number of pending (aka buffered, unflushed)
bytes on the stream, FP, that is open for writing. */
@@ -39,7 +39,7 @@ __fpending (FILE *fp)
/* GNU libc, BeOS, Haiku, Linux libc5 */
return fp->_IO_write_ptr - fp->_IO_write_base;
#elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
- /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, Android */
+ /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin < 1.7.34, Minix 3,
Android */
return fp->_p - fp->_bf._base;
#elif defined __EMX__/* emx+gcc */
return fp->_ptr - fp->_buffer;
diff --git a/lib/fpurge.c b/lib/fpurge.c
index f05da5a..fc88646 100644
--- a/lib/fpurge.c
+++ b/lib/fpurge.c
@@ -19,7 +19,7 @@
/* Specification. */
#include
-#if HAVE___FPURGE /* glibc >= 2.2, Haiku, Solaris >= 7,
Android API >= 23 */
+#if HAVE___FPURGE /* glibc >= 2.2, Haiku, Solaris >= 7,
Cygwin >= 1.7.10, Android API >= 23 */
# include
#endif
#include
@@ -29,13 +29,13 @@
int
fpurge (FILE *fp)
{
-#if HAVE___FPURGE /* glibc >= 2.2, Haiku, Solaris >= 7,
Android API >= 23, musl libc */
+#if HAVE___FPURGE /* glibc >= 2.2, Haiku, Solaris >= 7,
Cygwin >= 1.7.10, Android API >= 23, musl libc */
__fpurge (fp);
/* The __fpurge function does not have a return value. */
return 0;
-#elif HAVE_FPURGE /* FreeBSD, NetBSD, OpenBSD, DragonFly,
Mac OS X, Cygwin 1.7 */
+#elif HAVE_FPURGE /* FreeBSD, NetBSD, OpenBSD, DragonFly,
Mac OS X, Cygwin >= 1.7 */
/* Call the system's fpurge function. */
# undef fpurge
diff --git a/lib/freadable.c b/lib/freadable.c
index 160fc30..b7110cb 100644
--- a/lib/freadable.c
+++ b/lib/freadable.c
@@ -26,7 +26,8 @@
#endif
/* This file is not used on systems that have the __freadable function,
- namely glibc >= 2.2, Solaris >= 7, Android API >= 23, musl libc. */
+ namely glibc >= 2.2, Solaris >= 7, Cygwin >= 1.7.34, Android API >= 23,
+ musl libc. */
bool
freadable (FILE *fp)
@@ -38,7 +39,7 @@ freadable (FILE *fp)
/* GNU libc, BeOS, Haiku, Linux libc5 */
return (fp->_flags & _IO_NO_READS) == 0;
#elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
- /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, Android */
+ /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin < 1.7.34, Minix 3,
Android */
return (fp_->_flags & (__SRW | __SRD)) != 0;
#elif defined __EMX__ /* emx+gcc */
return (fp->_flags & (_IORW | _IOREAD)) != 0;
diff --git a/lib/freadable.h b/lib/freadable.h
index 5a17e4a..f05e5fb 100644
--- a/lib/freadable.h
+++ b/lib/freadable.h
@@ -22,7 +22,7 @@
STREAM must not be wide-character oriented.
The result doesn't change until the stream is closed or re-opened. */
-#if HAVE___FREADABLE /* glibc >= 2.2, Solaris >= 7, Android API >= 23, musl
libc */
+#if HAVE___FREADABLE /* glibc >= 2.2, Solaris >= 7, Cygwin >= 1.7.34, Android
API >= 23, musl libc */
# include
# define freadable(stream) (__freadable (stream) != 0)
diff --git a/lib/freading.c b/lib/freading.c
index f4dab78..f046676 100644
--- a/lib/freading.c
+++ b/lib/freading.c
@@ -37,7 +37,7 @@ freading (FILE *fp)
|| ((fp->_flags & (_IO_NO_READS | _IO_CURRENTLY_PUTTING)) == 0
&& fp->_IO_read_base != NULL));
# elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
- /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, Android */
+ /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin < 1.7.34, Minix 3,
Android */
return (fp_->_flags & __SRD)
argp: pass NULL as msgid to dgettext without checks
since my libc is musl, tar is using builtin argp implementation, which will pass NULL as msgid to dgettext without additional checks. but according to https://www.gnu.org/software/gettext/manual/html_node/Interface-to-gettext.html, passing NULL to gettext is undefined. and, musl chose to crash.. could you please check if msgid is NULL before passing it to dgettext? the problem code is located at argp-help.c. related links: https://www.openwall.com/lists/musl/2017/03/24/10. -- Best regards, xhe
Re: [PATCH] sigsegv: Fix build on ppc/musl
Eric Blake wrote: > On Wed, Mar 09, 2022 at 11:37:14PM -0800, Khem Raj wrote: > > mcontext is not a standard layout so glibc and musl differ sadly. > > > > Fixes > > ../../m4-1.4.19/lib/sigsegv.c: In function 'sigsegv_handler': > > > > ../../m4-1.4.19/lib/sigsegv.c:223:75: > > error: 'mcontext_t' has no member named 'uc_regs'; did you mean 'gregs'? > > > > 223 | #define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) > > ucp)->uc_mcontext.uc_regs->gregs[1] > > | > > ^~~ > > Thanks for the report. As this file comes from gnulib, the fix needs > to go there first. Thanks for the report. I'm adding this patch to GNU libsigsegv: https://git.savannah.gnu.org/gitweb/?p=libsigsegv.git;a=commitdiff;h=a6ff69873110c0a8ba6f7fd90532dbc11224828c and then this (derived) patch to Gnulib. I couldn't verify that it works, since there is no Linux distro that is based on musl libc and is ported to Linux/powerpc (32-bit). 2022-03-13 Bruno Haible sigsegv: Add support for Linux/PowerPC (32-bit) with musl libc. Reported by Khem Raj in <https://lists.gnu.org/archive/html/m4-patches/2022-03/msg0.html>. * src/sigsegv.c (SIGSEGV_FAULT_STACKPOINTER): In the Linux/PowerPC 32-bit case, handle musl libc differently. * modules/sigsegv (Files): Add m4/musl.m4. (configure.ac): Invoke gl_MUSL_LIBC. diff --git a/lib/sigsegv.c b/lib/sigsegv.c index da70ffa5fd..da64d7d0b6 100644 --- a/lib/sigsegv.c +++ b/lib/sigsegv.c @@ -227,11 +227,28 @@ int libsigsegv_version = LIBSIGSEGV_VERSION; # if defined __powerpc64__ || defined __powerpc64_elfv2__ /* 64-bit */ # define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) ucp)->uc_mcontext.gp_regs[1] # else /* 32-bit */ -/* both should be equivalent */ -# if 0 -#define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) ucp)->uc_mcontext.regs->gpr[1] +# if MUSL_LIBC +/* musl libc has a different structure of ucontext_t in + musl/arch/powerpc/bits/signal.h. */ +/* The glibc comments say: + "Different versions of the kernel have stored the registers on signal + delivery at different offsets from the ucontext struct. Programs should + thus use the uc_mcontext.uc_regs pointer to find where the registers are + actually stored." */ +#if 0 +# define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) ucp)->uc_mcontext.gregs[1] +#else +# define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) ucp)->uc_regs->gregs[1] +#endif # else -#define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) ucp)->uc_mcontext.uc_regs->gregs[1] +/* Assume the structure of ucontext_t in + glibc/sysdeps/unix/sysv/linux/powerpc/sys/ucontext.h. */ +/* Because of the union, both definitions should be equivalent. */ +#if 0 +# define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) ucp)->uc_mcontext.regs->gpr[1] +#else +# define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) ucp)->uc_mcontext.uc_regs->gregs[1] +#endif # endif # endif diff --git a/modules/sigsegv b/modules/sigsegv index b723bd6814..eedce3a9d9 100644 --- a/modules/sigsegv +++ b/modules/sigsegv @@ -17,6 +17,7 @@ lib/sigsegv.c lib/stackvma.h lib/stackvma.c m4/mmap-anon.m4 +m4/musl.m4 m4/sigaltstack.m4 m4/stack-direction.m4 m4/libsigsegv.m4 @@ -46,6 +47,8 @@ if $GL_GENERATE_SIGSEGV_H; then dnl Persuade Solaris OpenIndiana to declare mincore(). AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS]) + gl_MUSL_LIBC + AC_REQUIRE([AC_CANONICAL_HOST]) case "$host_os" in solaris2.11)
Re: bug#70104: "FAIL: test-canonicalize" coreutils v9.5 on musl libc
Adept's Lab wrote:
> >> test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed
Thanks for the report. I reproduce it with gnulib testdirs
$ rm -rf ../testdir1; ./gnulib-tool --create-testdir --dir=../testdir1
--single-configure canonicalize-lgpl
$ rm -rf ../testdir2; ./gnulib-tool --create-testdir --dir=../testdir2
--single-configure canonicalize
when run on Alpine Linux 3.9, 3.14, and 3.19.
History of these failures:
- For many years, one of the tests was failing on Alpine Linux.
- On 2021-01-17, I added a fix, that consists of a realpath() override [1].
- On 2022-07-31, the bug was reported again [2], against the sed-4.8 release
which predates the 2021-01-17 fix [3].
- On 2023-09-04, Paul changed the behaviour of the unit tests on musl libc,
without giving an explanation [4].
- Now, the unit tests fail again, as reported above.
I'm therefore partially reverting Paul's change from 2023-09-04 (attached).
Paul Eggert wrote:
> Does this behavior (of whether / and // are the same directory) depend
> on musl version, or on how musl is configured?
I think you must ask this to yourself:
- What caused you to change the unit tests on 2023-09-04?
- How is the musl version that you used on that date configured?
What I use is Alpine Linux, as I said in versions 3.9, 3.14, 3.19.
- Did you work with gnulib testdirs at that time, or did you use
a package in which some modules are --avoid ed from import?
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2021-01/msg00215.html
[2] https://lists.gnu.org/archive/html/bug-sed/2022-07/msg3.html
[3] https://ftp.gnu.org/gnu/sed/
[4] https://lists.gnu.org/archive/html/bug-gnulib/2023-09/msg00011.html
From 1defda6356c29c7f731bddb9e9231f594e01d9c9 Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Sun, 31 Mar 2024 21:31:34 +0200
Subject: [PATCH] canonicalize[-lgpl] tests: Fix test failure on musl libc.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Reported by Adept's Lab via Pádraig Brady at
<https://lists.gnu.org/archive/html/bug-coreutils/2024-03/msg00086.html>.
* tests/test-canonicalize-lgpl.c (main): Don't special-case "//"
handling for musl libc.
* tests/test-canonicalize.c (main): Likewise.
* modules/canonicalize-lgpl-tests (Files): Remove m4/musl.m4.
(configure.ac): Don't invoke gl_MUSL_LIBC.
---
ChangeLog | 11 +++
modules/canonicalize-lgpl-tests | 2 --
tests/test-canonicalize-lgpl.c | 6 +++---
tests/test-canonicalize.c | 6 +++---
4 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 2f05098a08..ffae5513ae 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2024-03-31 Bruno Haible
+
+ canonicalize[-lgpl] tests: Fix test failure on musl libc.
+ Reported by Adept's Lab via Pádraig Brady at
+ <https://lists.gnu.org/archive/html/bug-coreutils/2024-03/msg00086.html>.
+ * tests/test-canonicalize-lgpl.c (main): Don't special-case "//"
+ handling for musl libc.
+ * tests/test-canonicalize.c (main): Likewise.
+ * modules/canonicalize-lgpl-tests (Files): Remove m4/musl.m4.
+ (configure.ac): Don't invoke gl_MUSL_LIBC.
+
2024-03-31 Collin Funk
gnulib-tool.py: Fix output of 'po/LINGUAS'.
diff --git a/modules/canonicalize-lgpl-tests b/modules/canonicalize-lgpl-tests
index 409ee7225b..73a0e32abb 100644
--- a/modules/canonicalize-lgpl-tests
+++ b/modules/canonicalize-lgpl-tests
@@ -1,5 +1,4 @@
Files:
-m4/musl.m4
tests/test-canonicalize-lgpl.c
tests/signature.h
tests/null-ptr.h
@@ -11,7 +10,6 @@ same-inode
symlink
configure.ac:
-gl_MUSL_LIBC
Makefile.am:
TESTS += test-canonicalize-lgpl
diff --git a/tests/test-canonicalize-lgpl.c b/tests/test-canonicalize-lgpl.c
index 1b2ad98f51..21211e5eac 100644
--- a/tests/test-canonicalize-lgpl.c
+++ b/tests/test-canonicalize-lgpl.c
@@ -262,9 +262,9 @@ main (void)
ASSERT (stat ("/", &st1) == 0);
ASSERT (stat ("//", &st2) == 0);
bool same = psame_inode (&st1, &st2);
-#if defined __MVS__ || defined MUSL_LIBC
-/* On IBM z/OS and musl libc, "/" and "//" both canonicalize to
- themselves, yet they both have st_dev == st_ino == 1. */
+#if defined __MVS__
+/* On IBM z/OS, "/" and "//" both canonicalize to themselves, yet they both
+ have st_dev == st_ino == 1. */
same = false;
#endif
if (same)
diff --git a/tests/test-canonicalize.c b/tests/test-canonicalize.c
index 6763a525c9..5d19285c00 100644
--- a/tests/test-canonicalize.c
+++ b/tests/test-canonicalize.c
@@ -394,9 +394,9 @@ main (void)
ASSERT (stat ("/", &st1) == 0);
ASSERT (stat ("//", &st2) == 0);
bool same = psame_inode (&st1, &st2);
-#if defined __MVS__ || defined MUSL_LIBC
-
Re: musl compatibility
On 06/07/2012 12:14 PM, Reuben Thomas wrote: > Someone just wrote a rant in a bug report for a program I maintain > about gnulib being the cause of many portability problems. I tracked > it down to the points raised here: > > http://www.etalabs.net/musl/faq.html > > Have you any plans to address these problems? In particular, it does > seem odd to place a burden on libc authors of porting gnulib to it, > rather than just not supporting those functions which require > non-standard APIs on such libc's. I've heard such rants as well. The rants are IMO, misdirected. For instance, IIRC, gnulib's freadahead use is caused by musl's printf not being posix compliant, causing gnulib to pull in its printf replacement, which doesn't work on musl. A library that is new, actively maintained, and that calls itself a "C/POSIX standard library" should really address that by making it's printf posix compliant, so that gnulib's fallback doesn't even get built. It seems that nobody who is interested in musl has looked at gnulib's config.log to understand why does gnulib think musl's printf is not good enough. -- Pedro Alves
Re: [musl] Re: musl bugs found through gnulib
On 06/20/2012 05:04 AM, Rich Felker wrote: > Some more updates.. > > On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: >> When I compile all of gnulib, I also get a compilation error >> (may be a musl or a gnulib problem, haven't investigated): >> fsusage.c: In function 'get_fs_usage': >> fsusage.c:222:17: error: storage size of 'fsd' isn't known >> fsusage.c:224:3: warning: implicit declaration of function 'statfs' >> [-Wimplicit-function-declaration] >> fsusage.c:222:17: warning: unused variable 'fsd' [-Wunused-variable] >> make[4]: *** [fsusage.o] Error 1 > > This looks like a gnulib problem. On musl, statvfs should get used, > and this code should not even be compiled... Judging from the > comments, it looks like a hard-coded workaround for broken glibc > and/or Linux versions, but the header include seems to be missing in > the workaround case... This is addressed in different ways in these two commits: http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commit;h=defe5737 http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2ab2617e cheers, Pádraig.
Re: [PATCH] Do not decorate symbols as dllexport on Cygwin
On Feb 6 18:37, Bruno Haible wrote: > Corinna Vinschen wrote: > > This patch will be in the next Cygwin release 3.4.6. > > Thanks! > > > I'm just a bit fuzzy what patches will be required for gnulib now... > > With this patch, the setlocale_null lock should be gone in Cygwin >= 3.4.6. > I can't really test it, but I hope the patch is correct. I just ran the setlocale_null-mt-* tests with gnulib from git master under Cygwin with my newlib patch, and the tests succeeded. I checked that configure is doing the right thing and config.h contains the right settings: $ ./configure [...] checking whether setlocale (LC_ALL, NULL) is multithread-safe... yes checking whether setlocale (category, NULL) is multithread-safe... yes [...] $ grep SETLOCALE_NULL config.h #define GNULIB_TEST_SETLOCALE_NULL 1 #define SETLOCALE_NULL_ALL_MTSAFE 1 #define SETLOCALE_NULL_ONE_MTSAFE 1 $ grep SETLOCALE_NULL gltests/config.h #define GNULIB_TEST_SETLOCALE_NULL 1 #define SETLOCALE_NULL_ALL_MTSAFE 1 #define SETLOCALE_NULL_ONE_MTSAFE 1 Thanks a lot, Corinna > > > 2023-02-06 Bruno Haible > > setlocale-null: Don't use a lock in Cygwin >= 3.4.6. > Road paved by Corinna Vinschen . > * m4/setlocale_null.m4 (gl_FUNC_SETLOCALE_NULL): Assume that > setlocale (LC_ALL, NULL) is multithread-safe in Cygwin >= 3.4.6. > * lib/setlocale_null.c: Update comments. > * tests/test-setlocale_null-mt-all.c: Likewise. > > diff --git a/lib/setlocale_null.c b/lib/setlocale_null.c > index 6ac563db14..89c8a06598 100644 > --- a/lib/setlocale_null.c > +++ b/lib/setlocale_null.c > @@ -173,7 +173,7 @@ setlocale_null_unlocked (int category, char *buf, size_t > bufsize) > #endif > } > > -#if !(SETLOCALE_NULL_ALL_MTSAFE && SETLOCALE_NULL_ONE_MTSAFE) /* musl libc, > macOS, FreeBSD, NetBSD, OpenBSD, AIX, Haiku, Cygwin */ > +#if !(SETLOCALE_NULL_ALL_MTSAFE && SETLOCALE_NULL_ONE_MTSAFE) /* musl libc, > macOS, FreeBSD, NetBSD, OpenBSD, AIX, Haiku, Cygwin < 3.4.6 */ > > /* Use a lock, so that no two threads can invoke setlocale_null_unlocked > at the same time. */ > @@ -198,7 +198,7 @@ setlocale_null_with_lock (int category, char *buf, size_t > bufsize) >return ret; > } > > -# elif HAVE_PTHREAD_API /* musl libc, macOS, FreeBSD, NetBSD, OpenBSD, AIX, > Haiku, Cygwin */ > +# elif HAVE_PTHREAD_API /* musl libc, macOS, FreeBSD, NetBSD, OpenBSD, AIX, > Haiku, Cygwin < 3.4.6 */ > > extern > # if defined _WIN32 || defined __CYGWIN__ > diff --git a/m4/setlocale_null.m4 b/m4/setlocale_null.m4 > index dd6a5ef538..b41df499a8 100644 > --- a/m4/setlocale_null.m4 > +++ b/m4/setlocale_null.m4 > @@ -1,4 +1,4 @@ > -# setlocale_null.m4 serial 6 > +# setlocale_null.m4 serial 7 > dnl Copyright (C) 2019-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, > @@ -13,9 +13,23 @@ AC_DEFUN([gl_FUNC_SETLOCALE_NULL], >AC_CACHE_CHECK([whether setlocale (LC_ALL, NULL) is multithread-safe], > [gl_cv_func_setlocale_null_all_mtsafe], > [case "$host_os" in > - # Guess no on musl libc, macOS, FreeBSD, NetBSD, OpenBSD, AIX, Haiku, > Cygwin. > - *-musl* | darwin* | freebsd* | midnightbsd* | netbsd* | openbsd* | > aix* | haiku* | cygwin*) > + # Guess no on musl libc, macOS, FreeBSD, NetBSD, OpenBSD, AIX, Haiku. > + *-musl* | darwin* | freebsd* | midnightbsd* | netbsd* | openbsd* | > aix* | haiku*) > gl_cv_func_setlocale_null_all_mtsafe=no ;; > + # Guess no on Cygwin < 3.4.6. > + cygwin*) > + AC_EGREP_CPP([Lucky user], > + [ > +#if defined __CYGWIN__ > + #include > + #if CYGWIN_VERSION_DLL_COMBINED >= CYGWIN_VERSION_DLL_MAKE_COMBINED (3004, > 6) > + Lucky user > + #endif > +#endif > + ], > + [gl_cv_func_setlocale_null_all_mtsafe=yes], > + [gl_cv_func_setlocale_null_all_mtsafe=no]) > +;; > # Guess yes on glibc, HP-UX, IRIX, Solaris, native Windows. > *-gnu* | gnu* | hpux* | irix* | solaris* | mingw*) > gl_cv_func_setlocale_null_all_mtsafe=yes ;; > diff --git a/tests/test-setlocale_null-mt-all.c > b/tests/test-setlocale_null-mt-all.c > index 6036c260cd..7480406639 100644 > --- a/tests/test-setlocale_null-mt-all.c > +++ b/tests/test-setlocale_null-mt-all.c > @@ -166,7 +166,7 @@ Solaris 11.0 OK > Solaris 11.4 OK > Solaris OpenIndiana OK > Haikucrash < 1 sec > -Cygwin crash < 1 sec > +Cygwin < 3.4.6 crash < 1 sec > mingwOK > MSVC OK (assuming compiler option /MD !) > */ > >
Re: Behaviour of strverscmp(3)
Dmitry Bogatov wrote:
> > Example code:
> >
> > #include
> > #include
> >
> > int main()
> > {
> > int value = strverscmp("UNKNOWN", "2.2.0");
> > printf("%d\n", value);
> > return 0;
> > }
> >
> > Under glibc value "35" is printed (positive), under musl value "-1" is
> > printed (negative).
Indeed, I can reproduce this with
- musl libc 1.2.3 and older (Alpine Linux 3.17 and older),
- Cygwin 2.9.0.
> > Not sure what is the correct solution for the
> > issue, so I cross-post into two lists.
Since the issue has meanwhile been fixed in musl libc 1.2.4
https://git.musl-libc.org/cgit/musl/commit/src/string/strverscmp.c?id=b50eb8c36c20f967bd0ed70c0b0db38a450886ba
the glibc behaviour is the correct one.
I'm applying the patch below.
> > While trying to building gsasl statically with musl library as part of
> > Nixpkgs distribution
Nixpkg must be using an old musl libc, then. The newest one is 1.2.4.
Simon Josefsson wrote:
> https://cygwin.com/cgit/newlib-cygwin/tree/newlib/libc/string/strverscmp.c
So, I've forwarded the report to the Cygwin people:
https://sourceware.org/pipermail/cygwin/2024-January/255085.html
> Cygwin (via MSYS2)
Errr. Cygwin does not use MSYS2. MSYS2 cannibalizes the Cygwin sources, not
the other way around.
2024-01-02 Bruno Haible
strverscmp: Work around bug in musl libc 1.2.3 and in Cygwin.
Reported by Dmitry Bogatov via Simon Josefsson in
<https://lists.gnu.org/archive/html/bug-gnulib/2024-01/msg2.html>.
* m4/string_h.m4 (gl_STRING_H_DEFAULTS): Initialize REPLACE_STRVERSCMP.
* m4/strverscmp.m4 (gl_FUNC_STRVERSCMP): Test whether strverscmp works
and set REPLACE_STRVERSCMP if not.
* lib/string.in.h (strverscmp): Consider REPLACE_STRVERSCMP.
* modules/strverscmp (Depends-on, configure.ac): Likewise.
* modules/string (Makefile.am): Substitute REPLACE_STRVERSCMP.
* tests/test-strverscmp.c (main): Add test cases suggested by Dmitry
Bogatov and by Simon Josefsson.
* doc/glibc-functions/strverscmp.texi: Mention the musl and Cygwin bug.
Update version info regarding FreeBSD.
diff --git a/doc/glibc-functions/strverscmp.texi
b/doc/glibc-functions/strverscmp.texi
index 5882d223e1..9e37143fa4 100644
--- a/doc/glibc-functions/strverscmp.texi
+++ b/doc/glibc-functions/strverscmp.texi
@@ -20,8 +20,13 @@
Portability problems fixed by Gnulib:
@itemize
@item
-This function is missing on all non-glibc platforms:
-macOS 11.1, FreeBSD 13.0, NetBSD 9.0, OpenBSD 6.7, Minix 3.1.8, AIX 5.1, HP-UX
11, IRIX 6.5, Solaris 11.4, Cygwin 1.7.x, mingw, MSVC 14, Android 9.0.
+This function is missing on many platforms:
+macOS 11.1, FreeBSD 13.1, NetBSD 9.0, OpenBSD 6.7, Minix 3.1.8, AIX 5.1, HP-UX
11, IRIX 6.5, Solaris 11.4, Cygwin 1.7.x, mingw, MSVC 14, Android 9.0.
+@item
+This function treats ASCII letters as smaller than a digit sequence
+on some platforms:
+@c
https://git.musl-libc.org/cgit/musl/commit/src/string/strverscmp.c?id=b50eb8c36c20f967bd0ed70c0b0db38a450886ba
+musl libc 1.2.3, Cygwin 3.4.6.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/lib/string.in.h b/lib/string.in.h
index 66be871a57..01ea3e3913 100644
--- a/lib/string.in.h
+++ b/lib/string.in.h
@@ -1419,12 +1419,22 @@ _GL_WARN_ON_USE (strsignal, "strsignal is unportable - "
#endif
#if @GNULIB_STRVERSCMP@
-# if !@HAVE_STRVERSCMP@
+# if @REPLACE_STRVERSCMP@
+# if !(defined __cplusplus && defined GNULIB_NAMESPACE)
+# define strverscmp rpl_strverscmp
+# endif
+_GL_FUNCDECL_RPL (strverscmp, int, (const char *, const char *)
+ _GL_ATTRIBUTE_PURE
+ _GL_ARG_NONNULL ((1, 2)));
+_GL_CXXALIAS_RPL (strverscmp, int, (const char *, const char *));
+# else
+# if !@HAVE_STRVERSCMP@
_GL_FUNCDECL_SYS (strverscmp, int, (const char *, const char *)
_GL_ATTRIBUTE_PURE
_GL_ARG_NONNULL ((1, 2)));
-# endif
+# endif
_GL_CXXALIAS_SYS (strverscmp, int, (const char *, const char *));
+# endif
_GL_CXXALIASWARN (strverscmp);
#elif defined GNULIB_POSIXCHECK
# undef strverscmp
diff --git a/m4/string_h.m4 b/m4/string_h.m4
index 3cbcbc7487..8b12101447 100644
--- a/m4/string_h.m4
+++ b/m4/string_h.m4
@@ -5,7 +5,7 @@
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
-# serial 37
+# serial 38
# Written by Paul Eggert.
@@ -146,5 +146,6 @@ AC_DEFUN([gl_STRING_H_DEFAULTS]
REPLACE_STRERROR_R=0; AC_SUBST([REPLACE_STRERROR_R])
REPLACE_STRERRORNAME_NP=0;AC_SUBST([REPLACE_STRERRORNAME_NP])
REPLACE_STRSIGNAL=0; AC_SUBST([REPLACE_STRSIGNAL])
+ REPLACE_STRVERSCMP=0
stdioext: Fix compilation errors with newer Android headers
Compiling for Android 4.3 (with recent Android 9.0 header files), I'm seeing
compilation failures in the stdioext modules. Such as:
In file included from fseterr.c:24:0:
stdio-impl.h:72:22: error: field '_ub' has incomplete type
struct __sbuf _ub; /* ungetc buffer */
^
fseterr.c: In function 'fseterr':
fseterr.c:37:6: error: 'FILE' has no member named '_flags'
fp_->_flags |= __SERR;
^
fseterr.c:37:18: error: '__SERR' undeclared (first use in this function)
fp_->_flags |= __SERR;
^
This fixes them.
2018-05-13 Bruno Haible
stdioext: Fix compilation errors with newer Android headers.
* lib/stdio-impl.h (fp_, fp_ub): Define differently for Android.
(__SLBF, __SNBF, __SRD, __SWR, __SRW, __SEOF, __SERR, __SOFF): Define
fallbacks for Android.
* lib/fpending.c: Update comments.
* lib/fpurge.c: Likewise.
* lib/freadable.h: Likewise.
* lib/freadable.c: Likewise.
* lib/freadahead.c: Likewise.
* lib/freading.h: Likewise.
* lib/freadptr.c: Likewise.
* lib/fseterr.c: Likewise.
* lib/fwritable.h: Likewise.
* lib/fwritable.c: Likewise.
* lib/fwriting.h: Likewise.
* lib/fwriting.c: Likewise.
diff --git a/lib/fpending.c b/lib/fpending.c
index 7bc235d..de370d4 100644
--- a/lib/fpending.c
+++ b/lib/fpending.c
@@ -24,6 +24,9 @@
#include "stdio-impl.h"
+/* This file is not used on systems that already have the __fpending function,
+ namely glibc >= 2.2, Solaris >= 7, Android API >= 23. */
+
/* Return the number of pending (aka buffered, unflushed)
bytes on the stream, FP, that is open for writing. */
size_t
diff --git a/lib/fpurge.c b/lib/fpurge.c
index 554790b..f9c82cd 100644
--- a/lib/fpurge.c
+++ b/lib/fpurge.c
@@ -19,7 +19,7 @@
/* Specification. */
#include
-#if HAVE___FPURGE /* glibc >= 2.2, Haiku, Solaris >= 7 */
+#if HAVE___FPURGE /* glibc >= 2.2, Haiku, Solaris >= 7,
Android API >= 23 */
# include
#endif
#include
@@ -29,7 +29,7 @@
int
fpurge (FILE *fp)
{
-#if HAVE___FPURGE /* glibc >= 2.2, Haiku, Solaris >= 7, musl
libc */
+#if HAVE___FPURGE /* glibc >= 2.2, Haiku, Solaris >= 7,
Android API >= 23, musl libc */
__fpurge (fp);
/* The __fpurge function does not have a return value. */
diff --git a/lib/freadable.c b/lib/freadable.c
index 53cdbee..f4ce079 100644
--- a/lib/freadable.c
+++ b/lib/freadable.c
@@ -25,6 +25,9 @@
# include
#endif
+/* This file is not used on systems that have the __freadable function,
+ namely glibc >= 2.2, Solaris >= 7, Android API >= 23, musl libc. */
+
bool
freadable (FILE *fp)
{
diff --git a/lib/freadable.h b/lib/freadable.h
index 000e95b..4b51570 100644
--- a/lib/freadable.h
+++ b/lib/freadable.h
@@ -22,7 +22,7 @@
STREAM must not be wide-character oriented.
The result doesn't change until the stream is closed or re-opened. */
-#if HAVE___FREADABLE /* glibc >= 2.2, Solaris >= 7, musl libc */
+#if HAVE___FREADABLE /* glibc >= 2.2, Solaris >= 7, Android API >= 23, musl
libc */
# include
# define freadable(stream) (__freadable (stream) != 0)
diff --git a/lib/freadahead.c b/lib/freadahead.c
index ed3dd0e..fd5411c 100644
--- a/lib/freadahead.c
+++ b/lib/freadahead.c
@@ -27,6 +27,9 @@
extern size_t __sreadahead (FILE *);
#endif
+/* This file is not used on systems that have the __freadahead function,
+ namely musl libc. */
+
size_t
freadahead (FILE *fp)
{
diff --git a/lib/freading.h b/lib/freading.h
index 29d92b1..31d71fd 100644
--- a/lib/freading.h
+++ b/lib/freading.h
@@ -33,7 +33,7 @@
STREAM must not be wide-character oriented. */
#if HAVE___FREADING && (!defined __GLIBC__ || defined __UCLIBC__ || __GLIBC__
> 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 7))
-/* Solaris >= 7, not glibc >= 2.2, but glibc >= 2.7, or musl libc */
+/* Solaris >= 7, Android API >= 29, not glibc >= 2.2, but glibc >= 2.7, or
musl libc */
# include
# define freading(stream) (__freading (stream) != 0)
diff --git a/lib/freadptr.c b/lib/freadptr.c
index 3afa621..9176559 100644
--- a/lib/freadptr.c
+++ b/lib/freadptr.c
@@ -23,6 +23,9 @@
#include "stdio-impl.h"
+/* This file is not used on systems that have the __freadptr function,
+ namely musl libc. */
+
const char *
freadptr (FILE *fp, size_t *sizep)
{
diff --git a/lib/fseterr.c b/lib/fseterr.c
index fd9da63..81f51ed 100644
--- a/lib/fseterr.c
+++ b/lib/fseterr.c
@@ -23,6 +23,9 @@
#include "stdio-impl.h"
+/* This file is not used on systems that have the __fseterr function,
+ namely musl libc. */
+
void
fseterr (FILE *fp)
{
diff --git a/lib/fwritable.c b/lib/fwritable.c
index 24a148a..79e7c38
execinfo: Update doc
musl libc does not have the backtrace* functions. It's worth mentioning. (I don't know why https://github.com/ronchaine/libexecinfo has been archived.) Ideally we should document musl libc portability, like we do for all other platforms. This would be about 2-3 days of work; not in my plans for today. 2024-05-17 Bruno Haible execinfo: Update doc. * doc/glibc-headers/execinfo.texi: Mention musl libc. * doc/glibc-functions/backtrace.texi: Likewise. * doc/glibc-functions/backtrace_symbols.texi: Likewise. * doc/glibc-functions/backtrace_symbols_fd.texi: Likewise. diff --git a/doc/glibc-functions/backtrace.texi b/doc/glibc-functions/backtrace.texi index ef2a3ac657..82919a0dc9 100644 --- a/doc/glibc-functions/backtrace.texi +++ b/doc/glibc-functions/backtrace.texi @@ -23,7 +23,7 @@ @itemize @item This function is missing on many platforms: -FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 10, Cygwin 2.9, mingw, MSVC 14, Android API level 32. +musl libc, FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 10, Cygwin 2.9, mingw, MSVC 14, Android API level 32. @end itemize Portability problems not fixed by Gnulib: diff --git a/doc/glibc-functions/backtrace_symbols.texi b/doc/glibc-functions/backtrace_symbols.texi index f63e263a81..fd6e5b3ca0 100644 --- a/doc/glibc-functions/backtrace_symbols.texi +++ b/doc/glibc-functions/backtrace_symbols.texi @@ -23,7 +23,7 @@ @itemize @item This function is missing on many platforms: -FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 10, Cygwin 2.9, mingw, MSVC 14, Android API level 32. +musl libc, FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 10, Cygwin 2.9, mingw, MSVC 14, Android API level 32. @end itemize Portability problems not fixed by Gnulib: diff --git a/doc/glibc-functions/backtrace_symbols_fd.texi b/doc/glibc-functions/backtrace_symbols_fd.texi index 71461ebcac..1ceda9fe60 100644 --- a/doc/glibc-functions/backtrace_symbols_fd.texi +++ b/doc/glibc-functions/backtrace_symbols_fd.texi @@ -23,7 +23,7 @@ @itemize @item This function is missing on many platforms: -FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 10, Cygwin 2.9, mingw, MSVC 14, Android API level 32. +musl libc, FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 10, Cygwin 2.9, mingw, MSVC 14, Android API level 32. @end itemize Portability problems not fixed by Gnulib: diff --git a/doc/glibc-headers/execinfo.texi b/doc/glibc-headers/execinfo.texi index bb1372ed51..9927feb319 100644 --- a/doc/glibc-headers/execinfo.texi +++ b/doc/glibc-headers/execinfo.texi @@ -23,7 +23,7 @@ @itemize @item This header file is missing on some platforms: -FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 10, Cygwin, mingw, MSVC 14, Android 9.0. +musl libc, FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 10, Cygwin, mingw, MSVC 14, Android 9.0. @end itemize Portability problems not fixed by Gnulib:
Re: [musl] Re: musl bugs found through gnulib
On Wed, Jun 20, 2012 at 03:28:02PM -0400, Rich Felker wrote: > > Replacement of getcwd, because of > > checking whether getcwd handles long file names properly... no, but it is > > partly working This test is failing because musl uses the kernel to resolve the current directory name, and the kernel does not support pathnames longer than PATH_MAX. For some reason, the test only considers this an error if AT_FDCWD is defined. Does gnulib aim to provide a getcwd that always works regardless of path depth? If so, replacing getcwd is the right action for gnulib on musl. > > checking whether getcwd aborts when 4k < cwd_length < 16k... no No is the correct result here. This test is looking for a bug that only exists on some archs with large page sizes (>4k), and no means it did not find the bug. > > Replacement of mktime, because of > > checking for working mktime... no This test is buggy; it goes into an infinite loop due to integer overflow UB, because the condition to break out of the loop is only checked when the test does not fail: for (j = 1; ; j <<= 1) if (! bigtime_test (j)) result |= 4; else if (INT_MAX / 2 < j) break; However this does indicate a bug in musl. The relevant code is very old and I suspect it's not checking for integer overflows at all, just generating huge time_t values that get truncated rather than mapped to (time_t)-1. Both need to be fixed. > > test-fcntl.c:382: assertion failed > > FAIL: test-fcntl > > Pending; intend to fix. Fixed. > > test-fma2.h:116: assertion failed > > FAIL: test-fma2 > > Unknown. Asking nsz.. Fixed by nsz. :-) Rich
Re: gnulib cross-compiling issue with musl
On Tue, Jun 18, 2013 at 10:41:45AM -0700, Paul Eggert wrote: > On 06/18/13 10:03, Rich Felker wrote: > > 1. In the #else case, instead of #error, put if(0) > > 2. Write a "portable" version of the replacement code > > How about this idea instead? > > 3. Modify gl_FUNC_FFLUSH_STDIN so that it checks at > compile-time whether it's using musl, and succeeds > in that case. > > This should be more robust than (1), and easier to implement > than (2). Can you suggest code along those lines? And if > it's nontrivial, would you be willing to sign copyright > papers assigning the code to the FSF? We've been through that discussion before, and even if it were feasible, it wouldn't help on any new system except musl. Of my two proposed fixes, the first would fix the issue on any future system that's not broken (not just existing ones), but would obviously not support future broken systems. The second proposed fix should support any future system, but would be a bit more costly, assuming it's even possible. To revisit why I don't like your proposed fix, for every bug we could get fixed by making an easy way for applications to test "is this musl?", we would have something like 10 new bugs created by people doing that. This is not just speculation; it's based on questions we get on the list and on IRC. Your idea of using such a test in the form of "if (is_musl) assume_non_broken();" is the first proposed use of this form I've seen. Every other request for an easy "if (is_musl)" test have been from people who wanted to do something that would cause bad breakage with future versions of musl. Rich
Re: [PATCH] getusershell: Add tests.
Hi Bruno, On 5/17/24 5:59 AM, Bruno Haible wrote: > The test fails on Alpine Linux. > > > FAIL: test-getusershell > === > > ../../gltests/test-getusershell.c:53: assertion 'ptr[0] != '#'' failed > Aborted (core dumped) > FAIL test-getusershell (exit status: 134) Hahaha, I added that check expecting that it would never cause issues. I remember you saying a few days ago saying that "every function is worth testing", so here is more evidence. :) > If you want to look into it: It's easy to install Alpine Linux in a VM. > Cf. maint-tools/platforms/test-environments.txt. Here's my writeup: I'll set one up this weekend so I have a musl environment for running tests. However, I think this failure has an easy explanation now that I look at the musl sources. The glibc implementation is derived from BSD. In the FreeBSD man page for shells(5) the following is said [1]: A hash mark (``#'') indicates the beginning of a comment; subsequent characters up to the end of the line are not interpreted by the routines which search the file. Blank lines are also ignored. In other words getusershell () should ignore comments which glibc also does. It appears that musl doesn't check for comments which explains that failure [2]. It also looks like musl will return empty lines (getline () with length 1), which I believe is incorrect from the FreeBSD man page description. If you still have your alpine machine up you can remove the comments from '/etc/shells' and check if it passes. [1] https://man.freebsd.org/cgi/man.cgi?query=shells&sektion=5&apropos=0&manpath=FreeBSD+14.0-RELEASE+and+Ports [2] https://git.musl-libc.org/cgit/musl/tree/src/legacy/getusershell.c Collin
Re: [PATCH] sigsegv: Fix build on ppc/musl
On Sun, Mar 13, 2022 at 9:14 AM Sam wrote: > > > > > On 13 Mar 2022, at 14:17, Bruno Haible wrote: > > > > Eric Blake wrote: > >> On Wed, Mar 09, 2022 at 11:37:14PM -0800, Khem Raj wrote: > >>> mcontext is not a standard layout so glibc and musl differ sadly. > >>> > >>> Fixes > >>> ../../m4-1.4.19/lib/sigsegv.c: In function 'sigsegv_handler': > >>> > >>> > >>> ../../m4-1.4.19/lib/sigsegv.c:223:75: error: 'mcontext_t' has no member > >>> named 'uc_regs'; did you mean 'gregs'? > >>> 223 | #define > >>> SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) > >>> ucp)->uc_mcontext.uc_regs->gregs[1] > >>> | > >>> ^~~ > >> > >> Thanks for the report. As this file comes from gnulib, the fix needs > >> to go there first. > > > > Thanks for the report. I'm adding this patch to GNU libsigsegv: > > https://git.savannah.gnu.org/gitweb/?p=libsigsegv.git;a=commitdiff;h=a6ff69873110c0a8ba6f7fd90532dbc11224828c > > > > and then this (derived) patch to Gnulib. > > > > I couldn't verify that it works, since there is no Linux distro that is > > based > > on musl libc and is ported to Linux/powerpc (32-bit). > > There's at least Gentoo, Adélie, and at least for now, Void. all OpenEmbedded/yocto based distributions as well do support ppc32/musl. > > Thanks for adding the patch and thanks to Khem for reporting it. > > Best, > sam
futimens on musl libc
The gnulib configure test in m4/futimens.m4, when run on Alpine Linux 3.7,
determines that the errno value is not as expected for a wrong fd.
Let me document this in gnulib and update the cross-compilation guess
accordingly.
Rich, FYI: The test program is this one:
#include
#include
#include
#include
#include
int main ()
{
struct timespec ts[2];
int fd = creat ("conftest.file", 0600);
struct stat st;
if (fd < 0) return 1;
ts[0].tv_sec = 1;
ts[0].tv_nsec = UTIME_OMIT;
ts[1].tv_sec = 1;
ts[1].tv_nsec = UTIME_NOW;
errno = 0;
if (futimens (AT_FDCWD, NULL) == 0) return 2;
if (errno != EBADF) return 3; /* <== It fails here */
if (futimens (fd, ts)) return 4;
sleep (1);
ts[0].tv_nsec = UTIME_NOW;
ts[1].tv_nsec = UTIME_OMIT;
if (futimens (fd, ts)) return 5;
if (fstat (fd, &st)) return 6;
if (st.st_ctime < st.st_atime) return 7;
return 0;
}
2019-03-23 Bruno Haible
futimens: Document musl libc bug.
* doc/posix-functions/futimens.texi: Mention the bug.
* m4/futimens.m4 (gl_FUNC_FUTIMENS): Require AC_CANONICAL_HOST. When
cross-compiling guess no on glibc and musl systems.
diff --git a/doc/posix-functions/futimens.texi
b/doc/posix-functions/futimens.texi
index 19fb84e..1e1c76c 100644
--- a/doc/posix-functions/futimens.texi
+++ b/doc/posix-functions/futimens.texi
@@ -29,7 +29,7 @@ Linux kernel 2.6.32, Solaris 11.1.
@item
Passing @code{AT_FDCWD} as the fd argument does not properly fail with
@code{EBADF} on some systems:
-glibc 2.11, Solaris 11.
+glibc 2.11, musl libc, Solaris 11.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/m4/futimens.m4 b/m4/futimens.m4
index 3cfa4a1..b5f4be9 100644
--- a/m4/futimens.m4
+++ b/m4/futimens.m4
@@ -1,4 +1,4 @@
-# serial 7
+# serial 8
# See if we need to provide futimens replacement.
dnl Copyright (C) 2009-2019 Free Software Foundation, Inc.
@@ -11,6 +11,7 @@ dnl with or without modifications, as long as this notice is
preserved.
AC_DEFUN([gl_FUNC_FUTIMENS],
[
AC_REQUIRE([gl_SYS_STAT_H_DEFAULTS])
+ AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles
AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
AC_CHECK_FUNCS_ONCE([futimens])
if test $ac_cv_func_futimens = no; then
@@ -44,10 +45,21 @@ AC_DEFUN([gl_FUNC_FUTIMENS],
]])],
[gl_cv_func_futimens_works=yes],
[gl_cv_func_futimens_works=no],
- [gl_cv_func_futimens_works="guessing yes"])
+ [case "$host_os" in
+ # Guess no on glibc systems.
+*-gnu* | gnu*) gl_cv_func_futimens_works="guessing no" ;;
+ # Guess no on musl systems.
+*-musl*) gl_cv_func_futimens_works="guessing no" ;;
+ # Guess yes otherwise.
+*) gl_cv_func_futimens_works="guessing yes" ;;
+ esac
+ ])
rm -f conftest.file])
-if test "$gl_cv_func_futimens_works" = no; then
- REPLACE_FUTIMENS=1
-fi
+case "$gl_cv_func_futimens_works" in
+ *yes) ;;
+ *)
+REPLACE_FUTIMENS=1
+;;
+esac
fi
])
Re: test-pthread-rwlock failure on Pop!_OS 22.04 LTS
On 6/29/24 02:48, Bruno Haible wrote: 1. Install a toolchain for creating binaries linked against musl-libc: $ sudo apt install musl-gcc 2. Create a testdir for the module 'pthread-rwlock'. 3. Build it with CC="gcc". You should still see the test failure after 10 minutes. 4. Build it with CC="musl-gcc". Run $ time gltests/test-pthread-rwlock If 4. takes more than 30 seconds, your OS is probably running on top of a hypervisor, and that is causing the problem. If 4. takes just a few seconds, it looks like a glibc bug. 4. takes just a few seconds on my platform.
Re: getusershell tests: Fail if empty lines are returned.
Hi Bruno, On 5/18/24 12:16 AM, Bruno Haible wrote: >> I'll submit a bug report on the musl lists now. > > Thanks. I submitted a report yesterday but forgot to link here [1]. >> I don't think this function is used too much > > Probably no one noticed the bug before, because the typical use of > this function is to test whether a given shell string is valid, > as in [1], and for this use, the bug hardly matters. True. I think most programs care about the current users default shell (struct passwd.pw_shell) anyways, not the systems available shells. I still think that the Musl behavior is unexpected enough that it warrants overriding though. I don't see a way to check the behavior of getusershell () in configure checks though. Typically /etc/shells can only be written by root and a administrator can change it at any time. IIRC most distributions use a hook to edit it upon installing (or uninstalling) a shell package. Who knows if some add empty lines or comments in the process. What do you think about just replacing it on all Musl systems? I can write a patch if that solution seems reasonable to you. Collin [1] https://www.openwall.com/lists/musl/2024/05/18/1
Re: Fwd: gnulib posix_spawn_file_actions_addclose
Valery Ushakov wrote:
> However for the addclose case the [1] says in the ERRORS section:
>
> The posix_spawn_file_actions_addopen() function shall fail if:
>
> [EBADF]
> The value specified by fildes is negative or greater than or
> equal to {OPEN_MAX}.
>
> The posix_spawn_file_actions_addclose() function shall fail if:
>
> [EBADF]
> The value specified by fildes is negative.
Ah, I see: I initially wrote the test based on the old specification [0].
Then POSIX changed the part about posix_spawn_file_actions_addclose [1].
Then, in 2021 I acknowledged this through commit [2].
At the time, musl libc still had the bug regarding the negative file
descriptors; therefore the configure test said "no", gnulib added its
replacement, and the unit test succeeded.
Now, you have discovered that musl libc no longer has the bug regarding
the negative file descriptors; therefore the configure test says "yes",
gnulib no longer overrides the function, and the unit test now fails.
The patch below should fix it.
[0]
https://pubs.opengroup.org/onlinepubs/009695399/functions/posix_spawn_file_actions_addclose.html
[1]
https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn_file_actions_addclose.html
[2]
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=36a838b081de0d2c62970df5b4b8d736d3aebe1d
2022-09-07 Bruno Haible
posix_spawn_file_actions_addclose tests: Avoid test failure on musl.
Reported by Valery Ushakov in
<https://lists.gnu.org/archive/html/bug-gnulib/2022-09/msg00041.html>.
* modules/posix_spawn_file_actions_addclose-tests (configure.ac): Invoke
gl_MUSL_LIBC.
* tests/test-posix_spawn_file_actions_addclose.c (main): Skip one of the
tests on musl libc.
diff --git a/modules/posix_spawn_file_actions_addclose-tests
b/modules/posix_spawn_file_actions_addclose-tests
index b115e3dfca..701e04dc17 100644
--- a/modules/posix_spawn_file_actions_addclose-tests
+++ b/modules/posix_spawn_file_actions_addclose-tests
@@ -9,6 +9,7 @@ posix_spawn_file_actions_init
posix_spawn_file_actions_destroy
configure.ac:
+gl_MUSL_LIBC
Makefile.am:
TESTS += test-posix_spawn_file_actions_addclose
diff --git a/tests/test-posix_spawn_file_actions_addclose.c
b/tests/test-posix_spawn_file_actions_addclose.c
index c5238c3e38..d0ab33d14f 100644
--- a/tests/test-posix_spawn_file_actions_addclose.c
+++ b/tests/test-posix_spawn_file_actions_addclose.c
@@ -55,12 +55,14 @@ main (void)
ASSERT (posix_spawn_file_actions_addclose (&actions, -1) == EBADF);
}
/* This behaviour is not mandated by POSIX, but happens to pass on all
- platforms. */
+ platforms except musl libc. */
+#if !defined MUSL_LIBC
{
int bad_fd = big_fd ();
errno = 0;
ASSERT (posix_spawn_file_actions_addclose (&actions, bad_fd) == EBADF);
}
+#endif
posix_spawn_file_actions_destroy (&actions);
[PATCH] getusershell: Work around musl bugs.
Reported by Bruno Haible in <https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00261.html>. * doc/glibc-functions/getusershell.texi: Mention the musl bug. * lib/unistd.in.h (getusershell, setusershell, endusershell): Allow the functions to be declared with the rpl_ prefix. * m4/getusershell.m4 (gl_FUNC_GETUSERSHELL): Prepare functions to be replaced on musl systems. (gl_PREREQ_GETUSERSHELL): New macro. * m4/unistd_h.m4 (gl_UNISTD_H_DEFAULTS): Initialize REPLACE_GETUSERSHELL. * modules/getusershell (Depends-on): Update module conditions to account for the function being available but replaced by Gnulib. (configure.ac): Likewise. Invoke gl_PREREQ_GETUSERSHELL. --- ChangeLog | 17 doc/glibc-functions/getusershell.texi | 5 lib/unistd.in.h | 39 ++- m4/getusershell.m4| 11 +++- m4/unistd_h.m4| 3 ++- modules/getusershell | 12 ++--- modules/unistd| 1 + 7 files changed, 76 insertions(+), 12 deletions(-) diff --git a/ChangeLog b/ChangeLog index 1e8cc94054..89c5aa6993 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,20 @@ +2024-05-19 Collin Funk + + getusershell: Work around musl bugs. + Reported by Bruno Haible in + <https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00261.html>. + * doc/glibc-functions/getusershell.texi: Mention the musl bug. + * lib/unistd.in.h (getusershell, setusershell, endusershell): Allow the + functions to be declared with the rpl_ prefix. + * m4/getusershell.m4 (gl_FUNC_GETUSERSHELL): Prepare functions to be + replaced on musl systems. + (gl_PREREQ_GETUSERSHELL): New macro. + * m4/unistd_h.m4 (gl_UNISTD_H_DEFAULTS): Initialize + REPLACE_GETUSERSHELL. + * modules/getusershell (Depends-on): Update module conditions to account + for the function being available but replaced by Gnulib. + (configure.ac): Likewise. Invoke gl_PREREQ_GETUSERSHELL. + 2024-05-18 Bruno Haible abort-debug: Prefer libbacktrace to execinfo. diff --git a/doc/glibc-functions/getusershell.texi b/doc/glibc-functions/getusershell.texi index 83b6d4971e..379e6d893f 100644 --- a/doc/glibc-functions/getusershell.texi +++ b/doc/glibc-functions/getusershell.texi @@ -14,6 +14,11 @@ @node getusershell @item This function is missing a declaration on some platforms: Solaris 9. + +@item +This function mistakenly returns comments and empty lines on some platforms: +@c https://www.openwall.com/lists/musl/2024/05/18/1 +musl libc 1.2.4 @end itemize Portability problems not fixed by Gnulib: diff --git a/lib/unistd.in.h b/lib/unistd.in.h index 7dbed38969..e01629af25 100644 --- a/lib/unistd.in.h +++ b/lib/unistd.in.h @@ -1531,12 +1531,21 @@ _GL_CXXALIASWARN (getpid); #if @GNULIB_GETUSERSHELL@ +# if @REPLACE_GETUSERSHELL@ /* Return the next valid login shell on the system, or NULL when the end of the list has been reached. */ -# if !@HAVE_DECL_GETUSERSHELL@ +# if !(defined __cplusplus && defined GNULIB_NAMESPACE) +#undef getusershell +#define getusershell rpl_getusershell +# endif +_GL_FUNCDECL_RPL (getusershell, char *, (void)); +_GL_CXXALIAS_RPL (getusershell, char *, (void)); +# else +# if !@HAVE_DECL_GETUSERSHELL@ _GL_FUNCDECL_SYS (getusershell, char *, (void)); -# endif +# endif _GL_CXXALIAS_SYS (getusershell, char *, (void)); +# endif _GL_CXXALIASWARN (getusershell); #elif defined GNULIB_POSIXCHECK # undef getusershell @@ -1548,10 +1557,19 @@ _GL_WARN_ON_USE (getusershell, "getusershell is unportable - " #if @GNULIB_GETUSERSHELL@ /* Rewind to pointer that is advanced at each getusershell() call. */ -# if !@HAVE_DECL_GETUSERSHELL@ +# if @REPLACE_GETUSERSHELL@ +# if !(defined __cplusplus && defined GNULIB_NAMESPACE) +#undef setusershell +#define setusershell rpl_setusershell +# endif +_GL_FUNCDECL_RPL (setusershell, void, (void)); +_GL_CXXALIAS_RPL (setusershell, void, (void)); +# else +# if !@HAVE_DECL_GETUSERSHELL@ _GL_FUNCDECL_SYS (setusershell, void, (void)); -# endif +# endif _GL_CXXALIAS_SYS (setusershell, void, (void)); +# endif _GL_CXXALIASWARN (setusershell); #elif defined GNULIB_POSIXCHECK # undef setusershell @@ -1564,10 +1582,19 @@ _GL_WARN_ON_USE (setusershell, "setusershell is unportable - " #if @GNULIB_GETUSERSHELL@ /* Free the pointer that is advanced at each getusershell() call and associated resources. */ -# if !@HAVE_DECL_GETUSERSHELL@ +# if @REPLACE_GETUSERSHELL@ +# if !(defined __cplusplus && defined GNULIB_NAMESPACE) +#undef endusershell +#define endusershell rpl_endusershell +# endif +_GL_FUNCDECL_RPL (endusershell, void, (void)); +_GL_CXXALIAS_RPL (endusershell, void, (void)); +# else +# if !@HAVE_DECL_GETUSERSHELL@ _GL_FUNCDECL_SYS (endusershell, void, (void)); -# endi
Re: [platform-testers] new snapshot available: grep-3.4-almost.19-ff30
Jeffrey Walton wrote in
<https://lists.gnu.org/archive/html/grep-devel/2020-09/msg00020.html>:
> Hi Everyone,
>
> grep-3.4-almost.19-ff30 fails self test on Alpine Linux 3.10 with
> BusyBox, triplet x86_64-pc-linux-gnu.
>
> ...
> FAIL: test-hard-locale
> FAIL: test-setlocale_null-mt-all
>
> Attached are config.log and test-suite.log.
The cause of these two failures is the wrong triplet: $host_os is
- on Alpine Linux 3.10: linux-gnu,
- on Alpine Linux 3.9 and 3.12: linux-musl.
The triplet comes from config.guess. The test there uses ldd ('ldd --version'
in particular). But on Alpine Linux 3.10 /usr/bin/ldd has been replaced with
a shell script that does not understand the --version option.
This patch fixes it. Part of it can be removed once config.guess will have been
corrected.
2020-09-19 Bruno Haible
Fix recognition of musl libc on Alpine Linux 3.10.
Reported by Jeffrey Walton in
<https://lists.gnu.org/archive/html/grep-devel/2020-09/msg00020.html>.
* m4/musl.m4 (gl_MUSL_CANONICAL_HOST): New macro.
(gl_MUSL_LIBC): Require it.
* m4/setlocale_null.m4 (gl_FUNC_SETLOCALE_NULL): Likewise.
* modules/setlocale-null (Files): Add m4/musl.m4.
diff --git a/m4/musl.m4 b/m4/musl.m4
index 252054c..343c71a 100644
--- a/m4/musl.m4
+++ b/m4/musl.m4
@@ -1,4 +1,4 @@
-# musl.m4 serial 1
+# musl.m4 serial 2
dnl Copyright (C) 2019-2020 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -9,10 +9,40 @@ dnl with or without modifications, as long as this notice is
preserved.
# <https://lists.gnu.org/archive/html/bug-gnulib/2018-02/msg00079.html>.
# From Bruno Haible.
+# There are three ways to test for musl libc:
+# a. Look at the 'ldd --version' output. This is how config.guess
+#does it. But it fails on Alpine Linux 3.10, because on this system
+#'ldd' is a shell script that does not understand the '--version'
+#option.
+# b. Test whether the header file exists.
+# c. Test whether the header file defines the macro
+#__DEFINED_va_list.
+# We use a+c.
+
AC_DEFUN_ONCE([gl_MUSL_LIBC],
[
- AC_REQUIRE([AC_CANONICAL_HOST])
+ AC_REQUIRE([gl_MUSL_CANONICAL_HOST])
case "$host_os" in
*-musl*) AC_DEFINE([MUSL_LIBC], [1], [Define to 1 on musl libc.]) ;;
esac
])
+
+# Like AC_CANONICAL_HOST, except for a fix regarding Alpine Linux 3.10.
+
+AC_DEFUN([gl_MUSL_CANONICAL_HOST],
+[
+ AC_REQUIRE([AC_CANONICAL_HOST])
+ case "$host_os" in
+linux*-gnu*)
+ AC_EGREP_CPP([actually_musl],
+[#include
+ #ifdef __DEFINED_va_list
+ actually_musl
+ #endif
+],
+ [host=`echo "$host" | sed -e 's/gnu.*/musl/'`
+ host_os=`echo "$host_os" | sed -e 's/gnu.*/musl/'`
+])
+ ;;
+ esac
+])
diff --git a/m4/setlocale_null.m4 b/m4/setlocale_null.m4
index c1ee1f7..20c5c99 100644
--- a/m4/setlocale_null.m4
+++ b/m4/setlocale_null.m4
@@ -1,4 +1,4 @@
-# setlocale_null.m4 serial 2
+# setlocale_null.m4 serial 3
dnl Copyright (C) 2019-2020 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -6,7 +6,7 @@ dnl with or without modifications, as long as this notice is
preserved.
AC_DEFUN([gl_FUNC_SETLOCALE_NULL],
[
- AC_REQUIRE([AC_CANONICAL_HOST])
+ AC_REQUIRE([gl_MUSL_CANONICAL_HOST])
AC_REQUIRE([gl_PTHREADLIB])
AC_CHECK_HEADERS_ONCE([threads.h])
diff --git a/modules/setlocale-null b/modules/setlocale-null
index 2774004..d8c57a2 100644
--- a/modules/setlocale-null
+++ b/modules/setlocale-null
@@ -7,6 +7,7 @@ lib/setlocale_null.c
lib/setlocale-lock.c
lib/windows-initguard.h
m4/setlocale_null.m4
+m4/musl.m4
m4/threadlib.m4
m4/visibility.m4
[PATCH] boot-time: do not depend on timespec_get
This is for Emacs, which does not use timespec_get now
and which likes to minimize dependencies.
Also, treat musl libc like recent glibc,
and fix a timespec_get return value typo.
* lib/boot-time-aux.h (get_linux_uptime):
Assume musl libc supports CLOCK_BOOTTIME.
(get_linux_boot_time_final_fallback):
Likewise for musl libc and CLOCK_REALTIME.
Do not rely on the timespec_get module, to break the dependency.
Consider 0 to be a failure return from timespec_get.
Fall back on gettimeofday if timespec_get does not exist.
* modules/boot-time (Depends-on): Remove timespec_get.
---
ChangeLog | 16
lib/boot-time-aux.h | 42 +++---
modules/boot-time | 1 -
3 files changed, 43 insertions(+), 16 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 4330034fbe..03120ec167 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,19 @@
+2023-08-12 Paul Eggert
+
+ boot-time: do not depend on timespec_get
+ This is for Emacs, which does not use timespec_get now
+ and which likes to minimize dependencies.
+ Also, treat musl libc like recent glibc,
+ and fix a timespec_get return value typo.
+ * lib/boot-time-aux.h (get_linux_uptime):
+ Assume musl libc supports CLOCK_BOOTTIME.
+ (get_linux_boot_time_final_fallback):
+ Likewise for musl libc and CLOCK_REALTIME.
+ Do not rely on the timespec_get module, to break the dependency.
+ Consider 0 to be a failure return from timespec_get.
+ Fall back on gettimeofday if timespec_get does not exist.
+ * modules/boot-time (Depends-on): Remove timespec_get.
+
2023-08-12 Bruno Haible
readutmp, boot-time: Fix parsing of /proc/uptime.
diff --git a/lib/boot-time-aux.h b/lib/boot-time-aux.h
index 4c5474c6c8..d980682a59 100644
--- a/lib/boot-time-aux.h
+++ b/lib/boot-time-aux.h
@@ -27,9 +27,9 @@ static int
get_linux_uptime (struct timespec *p_uptime)
{
/* The clock_gettime facility returns the uptime with a resolution of 1 µsec.
- It is available with glibc >= 2.14. In glibc < 2.17 it required linking
- with librt. */
-# if (__GLIBC__ + (__GLIBC_MINOR__ >= 17) > 2) || defined __ANDROID__
+ It is available with glibc >= 2.14, Android, or musl libc.
+ In glibc < 2.17 it required linking with librt. */
+# if !defined __GLIBC__ || 2 < __GLIBC__ + (17 <= __GLIBC_MINOR__)
if (clock_gettime (CLOCK_BOOTTIME, p_uptime) >= 0)
return 0;
# endif
@@ -115,21 +115,33 @@ get_linux_boot_time_final_fallback (struct timespec
*p_boot_time)
if (get_linux_uptime (&uptime) >= 0)
{
struct timespec result;
- /* equivalent to:
- if (clock_gettime (CLOCK_REALTIME, &result) >= 0)
+# if !defined __GLIBC__ || 2 < __GLIBC__ + (16 <= __GLIBC_MINOR__)
+ /* Better than:
+ if (0 <= clock_gettime (CLOCK_REALTIME, &result))
+ because timespec_get does not need -lrt in glibc 2.16.
*/
- if (timespec_get (&result, TIME_UTC) >= 0)
+ if (! timespec_get (&result, TIME_UTC))
+return -1;
+# else
+ /* Fall back on lower-res approach that does not need -lrt.
+ This is good enough; on these hosts UPTIME is even lower-res. */
+ struct timeval tv;
+ int r = gettimeofday (&tv, NULL);
+ if (r < 0)
+return r;
+ result.tv_sec = tv.tv_sec;
+ result.tv_nsec = tv.tv_usec * 1000;
+# endif
+
+ if (result.tv_nsec < uptime.tv_nsec)
{
- if (result.tv_nsec < uptime.tv_nsec)
-{
- result.tv_nsec += 10;
- result.tv_sec -= 1;
-}
- result.tv_sec -= uptime.tv_sec;
- result.tv_nsec -= uptime.tv_nsec;
- *p_boot_time = result;
- return 0;
+ result.tv_nsec += 10;
+ result.tv_sec -= 1;
}
+ result.tv_sec -= uptime.tv_sec;
+ result.tv_nsec -= uptime.tv_nsec;
+ *p_boot_time = result;
+ return 0;
}
return -1;
}
diff --git a/modules/boot-time b/modules/boot-time
index 8890406d6c..749b9014cd 100644
--- a/modules/boot-time
+++ b/modules/boot-time
@@ -16,7 +16,6 @@ idx
stat-time
stdbool
time-h
-timespec_get
unlocked-io-internal
configure.ac:
--
2.39.2
Re: lib/freadseek.c:69:3: error: #error "Please port gnulib freadseek.c to your platform!
Hello, We'll need a bit more technical information to troubleshoot the issue: On 2018-12-29 1:22 a.m., Necktwi Ozfguah wrote: While I am building coreutils with musl on aarch64 (RaspberryPi 3B), Which operating system and which version are you using? The output of "uname -a" would be helpful. Note that while the RPi3B board does support 64bit mode (aarch64), most common OSes (like Rasbian) still run in 32bit mode (arm7l). this error is thrown: lib/freadseek.c: In function 'freadptrinc': lib/freadseek.c:69:3: error: #error "Please port gnulib freadseek.c to your platform! Look at the definition of getc, getc_unlocked on your system, then report this to bug-gnulib." #error "Please port gnulib freadseek.c to your platform! Look at the definition of getc, getc_unlocked on your system, then report this to bug-gnulib." ^ Which version of coreutils are you using, and which version of musl are you using? It would also help to know how you compile them (e.g the "./configure" command, if not standard). For example, I've just tried compiling a recent coreutils version (v8.30-33-g2f438fa9f from git), using the latest musl (1.1.20-git-165-gde7dc13), on x86_64, arm7l (Raspian9) and aarch64 (Ubuntu 14.04), using the following command: ./configure CC=musl-gcc LDFLAGS="-static" and they all compiled without errors. regards, - assaf
doc: Update regarding *l functions on NetBSD 9.3
texi
+++ b/doc/posix-functions/coshl.texi
@@ -18,4 +18,8 @@
@item
This function is only defined as a macro with arguments on some platforms:
MSVC 14.
+@item
+This function produces results which are accurate to only 16 digits on some
+platforms:
+NetBSD 9.3.
@end itemize
diff --git a/doc/posix-functions/cosl.texi b/doc/posix-functions/cosl.texi
index fe1382a98c..4263fc13b5 100644
--- a/doc/posix-functions/cosl.texi
+++ b/doc/posix-functions/cosl.texi
@@ -18,4 +18,8 @@
Portability problems not fixed by Gnulib:
@itemize
+@item
+This function produces results which are accurate to only 16 digits on some
+platforms:
+NetBSD 9.3.
@end itemize
diff --git a/doc/posix-functions/erfcl.texi b/doc/posix-functions/erfcl.texi
index df7541ca03..f8f3f603bb 100644
--- a/doc/posix-functions/erfcl.texi
+++ b/doc/posix-functions/erfcl.texi
@@ -15,4 +15,8 @@
@item
This function is missing on some platforms:
FreeBSD 6.0, NetBSD 7.1, OpenBSD 3.8, Minix 3.1.8, HP-UX 11, IRIX 6.5, Solaris
9, Cygwin 1.7.x, mingw, MSVC 9, Android 4.4.
+@item
+This function produces results which are accurate to only 16 digits on some
+platforms:
+NetBSD 9.3.
@end itemize
diff --git a/doc/posix-functions/erfl.texi b/doc/posix-functions/erfl.texi
index a41910c183..6362a7a2ee 100644
--- a/doc/posix-functions/erfl.texi
+++ b/doc/posix-functions/erfl.texi
@@ -15,4 +15,8 @@
@item
This function is missing on some platforms:
FreeBSD 6.0, NetBSD 7.1, OpenBSD 3.8, Minix 3.1.8, HP-UX 11, IRIX 6.5, Solaris
9, Cygwin 1.7.x, mingw, MSVC 9, Android 4.4.
+@item
+This function produces results which are accurate to only 16 digits on some
+platforms:
+NetBSD 9.3.
@end itemize
diff --git a/doc/posix-functions/exp2l.texi b/doc/posix-functions/exp2l.texi
index 37729a6301..66257d0870 100644
--- a/doc/posix-functions/exp2l.texi
+++ b/doc/posix-functions/exp2l.texi
@@ -17,7 +17,7 @@
@item
This function produces results which are accurate to only 16 digits on some
platforms:
-NetBSD 9.0.
+NetBSD 9.3.
@end itemize
Portability problems fixed by Gnulib module @code{exp2l-ieee}:
diff --git a/doc/posix-functions/expl.texi b/doc/posix-functions/expl.texi
index f70589f29e..5dfb045960 100644
--- a/doc/posix-functions/expl.texi
+++ b/doc/posix-functions/expl.texi
@@ -23,7 +23,7 @@
@item
This function produces results which are accurate to only 16 digits on some
platforms:
-musl libc 1.2.2/arm64, musl libc 1.2.2/s390x, NetBSD 9.0.
+musl libc 1.2.2/arm64, musl libc 1.2.2/s390x, NetBSD 9.3.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/doc/posix-functions/hypotl.texi b/doc/posix-functions/hypotl.texi
index 4b91a48828..9a74d2668e 100644
--- a/doc/posix-functions/hypotl.texi
+++ b/doc/posix-functions/hypotl.texi
@@ -13,7 +13,7 @@
FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX
6.5, Solaris 9, Cygwin 1.7.x, MSVC 14, Android 4.4.
@item
This function produces very imprecise results on some platforms:
-NetBSD 9.0, OpenBSD 5.1/SPARC.
+NetBSD 9.3, OpenBSD 5.1/SPARC.
@end itemize
Portability problems fixed by Gnulib module @code{hypotl-ieee}:
diff --git a/doc/posix-functions/log10l.texi b/doc/posix-functions/log10l.texi
index ffddbcb442..d3b71e3014 100644
--- a/doc/posix-functions/log10l.texi
+++ b/doc/posix-functions/log10l.texi
@@ -26,7 +26,7 @@
@item
This function produces results which are accurate to only 16 digits on some
platforms:
-musl libc 1.2.2/arm64, musl libc 1.2.2/s390x, NetBSD 9.0.
+musl libc 1.2.2/arm64, musl libc 1.2.2/s390x, NetBSD 9.3.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/doc/posix-functions/logl.texi b/doc/posix-functions/logl.texi
index e0d04b5ec0..679bcae137 100644
--- a/doc/posix-functions/logl.texi
+++ b/doc/posix-functions/logl.texi
@@ -20,7 +20,7 @@
@item
This function produces results which are accurate to only 16 digits on some
platforms:
-musl libc 1.2.2/arm64, musl libc 1.2.2/s390x, NetBSD 9.0.
+musl libc 1.2.2/arm64, musl libc 1.2.2/s390x, NetBSD 9.3.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/doc/posix-functions/powl.texi b/doc/posix-functions/powl.texi
index c7c2482d86..05a18cfd7e 100644
--- a/doc/posix-functions/powl.texi
+++ b/doc/posix-functions/powl.texi
@@ -18,4 +18,8 @@
@item
This function is only defined as a macro with arguments on some platforms:
MSVC 14.
+@item
+This function produces results which are accurate to only 16 digits on some
+platforms:
+NetBSD 9.3.
@end itemize
diff --git a/doc/posix-functions/sinhl.texi b/doc/posix-functions/sinhl.texi
index 614f549ee3..b4e8d2d4af 100644
--- a/doc/posix-functions/sinhl.texi
+++ b/doc/posix-functions/sinhl.texi
@@ -18,4 +18,8 @@
@item
This function is only defined as a macro with arguments on some platforms:
MSVC 14.
+@item
+This function produces results which are accurate to only 16 digits on some
+platforms:
+NetBSD 9.3.
@end itemize
diff --git a/doc/posix-functions/sinl.texi b/doc/posix-functions/sinl.texi
index d19cca7115..bd8b9bd450 10
Re: stdioext on musl
Hi Rich, The patches that you've committed at http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=deb90c79e5c498fbb48de1423df034447f330e38 http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=e15171b8d8e80e8b5bcf4e95b1709697858f545a go a long way at implementing the support that gnulib needs. Just one question: When trying to use the new 4 functions, I get gcc warnings freadahead.c: In function 'freadahead': freadahead.c:84:3: warning: implicit declaration of function '__freadahead' [-Wimplicit-function-declaration] freadptr.c: In function 'freadptr': freadptr.c:105:3: warning: implicit declaration of function '__freadptr' [-Wimplicit-function-declaration] freadptr.c:105:3: warning: return makes pointer from integer without a cast [enabled by default] freadseek.c: In function 'freadptrinc': freadseek.c:62:3: warning: implicit declaration of function '__freadptrinc' [-Wimplicit-function-declaration] fseterr.c: In function 'fseterr': fseterr.c:49:3: warning: implicit declaration of function '__fseterr' [-Wimplicit-function-declaration] Will you add declarations of these functions to a public .h file? Or should gnulib provide these declarations? Bruno
Re: gnulib does not always detect need for iconv() hack on musl
Sergei Trofimovich wrote: > Aha, 'config.guess' clearly detects wrong libc here: > > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu Yes, for a musl system, that's wrong. The problem may come from your environment. Which of the environment variables CC_FOR_BUILD, HOST_CC, CC, CONFIG_SITE did you have defined, and to which values? > I did not realize 'config.guess' has the code to detect libc but it > clearly does. I'll dig from there and complain elsewhere. The mailing list is https://lists.gnu.org/mailman/listinfo/config-patches . The current code in config.guess is a heuristic (that has been working on Alpine Linux up to 3.13), because the musl libc people refuse to have their libc identify itself. [1] Bruno [1] https://wiki.musl-libc.org/faq.html#Q:-Why-is-there-no-%3Ccode%3E__MUSL__%3C/code%3E-macro?
Re: test-pthread-rwlock failure on Pop!_OS 22.04 LTS
Hi Paul, These measurements: > * in virtual machines with 8 CPUs: > > - Ubuntu 22.0460 sec (4 CPUs: 15 sec) > > * outside VirtualBox: > > - Ubuntu 22.04 (12 CPUs) 6 sec together with the investigation of the pthread_cond_timedwait "bug", makes it sound possible that a hypervisor is exercising some influence. I would therefore be interested in the result of the following experiment: 1. Install a toolchain for creating binaries linked against musl-libc: $ sudo apt install musl-gcc 2. Create a testdir for the module 'pthread-rwlock'. 3. Build it with CC="gcc". You should still see the test failure after 10 minutes. 4. Build it with CC="musl-gcc". Run $ time gltests/test-pthread-rwlock If 4. takes more than 30 seconds, your OS is probably running on top of a hypervisor, and that is causing the problem. If 4. takes just a few seconds, it looks like a glibc bug. Bruno
localename: add support for musl libc
On Alpine Linux 3.7.0, which uses musl libc, I see this test failure: FAIL: test-localename = ../../gltests/test-localename.c:183: assertion 'strcmp (name, "fr_FR.UTF-8") == 0' failed FAIL test-localename (exit status: 134) This patch fixes it. 2018-02-24 Bruno Haible localename: Add support for musl libc. * m4/localename.m4 (gl_LOCALENAME): Check for . * lib/localename.c (gl_locale_name_thread_unsafe): Use NL_LOCALE_NAME on Linux platforms which define NL_LOCALE_NAME. diff --git a/lib/localename.c b/lib/localename.c index 2133cbc..74c8ee0 100644 --- a/lib/localename.c +++ b/lib/localename.c @@ -40,7 +40,7 @@ # if defined __APPLE__ && defined __MACH__ # include # endif -# if (__GLIBC__ >= 2 && !defined __UCLIBC__) || defined __CYGWIN__ +# if (__GLIBC__ >= 2 && !defined __UCLIBC__) || (defined __linux__ && HAVE_LANGINFO_H) || defined __CYGWIN__ # include # endif # if !defined IN_LIBINTL @@ -2703,6 +2703,9 @@ gl_locale_name_thread_unsafe (int category, const char *categoryname) nl_langinfo (_NL_LOCALE_NAME (category)). */ name = thread_locale->__names[category]; return name; +# elif defined __linux__ && HAVE_LANGINFO_H && defined NL_LOCALE_NAME +/* musl libc */ +return nl_langinfo_l (NL_LOCALE_NAME (category), thread_locale); # elif (defined __FreeBSD__ || defined __DragonFly__) || (defined __APPLE__ && defined __MACH__) /* FreeBSD, Mac OS X */ int mask; diff --git a/m4/localename.m4 b/m4/localename.m4 index 0ac4529..a0e1367 100644 --- a/m4/localename.m4 +++ b/m4/localename.m4 @@ -1,4 +1,4 @@ -# localename.m4 serial 2 +# localename.m4 serial 3 dnl Copyright (C) 2007, 2009-2018 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -8,6 +8,7 @@ AC_DEFUN([gl_LOCALENAME], [ AC_REQUIRE([gt_LC_MESSAGES]) AC_REQUIRE([gt_INTL_MACOSX]) + AC_CHECK_HEADERS_ONCE([langinfo.h]) AC_CHECK_FUNCS([setlocale uselocale]) dnl Solaris 12 provides getlocalename_l, while Illumos doesn't have dnl it nor the equivalent.
Re: Fwd: gnulib posix_spawn_file_actions_addclose
Hi Uwe, > It looks like you are the author of the posix_spawn > implementation in gnulib Ulrich Drepper wrote most of the part for the Unix platforms; I wrote the implementation for native Windows. > so I wanted to ask a question privately before spamming bug-gnulib. Better direct all questions to the mailing list. 1. So that you don't have to wait in times when I am not available. 2. So that the discussions are available for later reference. > On a systems with musl-1.2.3 for its libc the gnulib configure (as > part of m4 1.4.19) detects: > > $ grep spawn .log.configure > checking for spawn.h... yes > checking for posix_spawn_file_actions_addchdir_np... yes > checking for posix_spawn_file_actions_addchdir... no > checking for library containing posix_spawn... none required > checking for posix_spawn... yes > checking whether posix_spawn is declared... yes > checking whether posix_spawn works... yes > checking whether posix_spawn rejects scripts without shebang... yes > checking whether posix_spawnp rejects scripts without shebang... yes > checking whether posix_spawnattr_setschedpolicy is supported... yes > checking whether posix_spawnattr_setschedparam is supported... yes > checking for posix_spawnattr_t... yes > checking for posix_spawn_file_actions_t... yes > checking whether posix_spawn_file_actions_addclose works... yes > checking whether posix_spawn_file_actions_adddup2 works... no > checking whether posix_spawn_file_actions_addopen works... no > > > The addclose configure test succeeds b/c of this commit: > > > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=36a838b081de0d2c62970df5b4b8d736d3aebe1d > > that makes configure test a negative fd instead of a large fd. Yes. > However tests/test-posix_spawn_file_actions_addclose.c still tests for > a large fd too and fails that test. Yes. I believe the test verifies one of the assertions by POSIX [1]. > I wonder if either test-posix_spawn_file_actions_addclose.c should not > check for the "big" fd (and neither should spawn_faction_addclose.c > too?) or the configure check should be reverted to check for the > "big" fd to make the two match. I believe it's a POSIX compliance bug in musl libc, but Rich Felker disagrees. [2][3][4] Bruno [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn_file_actions_addclose.html [2] https://www.openwall.com/lists/musl/2019/03/24/2 [3] https://www.openwall.com/lists/musl/2019/03/24/5 [4] https://www.openwall.com/lists/musl/2019/03/24/7
Re: gnulib cross-compiling issue with musl
On Tue, Jun 18, 2013 at 11:32:50AM -0700, Paul Eggert wrote: > On 06/18/13 11:07, Rich Felker wrote: > > > Of my two > > proposed fixes, the first would fix the issue on any future system > > that's not broken (not just existing ones), but would obviously not > > support future broken systems. > > But we're not talking about "future" systems here; we're merely talking > about unported-to systems, not all of which are future systems. > > Nor are we talking about "broken" systems; we're merely talking about > systems that do not conform to POSIX -- they may conform to C11, say, > without conforming to POSIX. > > So this first fix sounds problematic. I think the advent of new implementations that don't aim for at least a reasonable level of POSIX compatibility is fairly unlikely. But if you think it matters, you could add #elif defined _POSIX_VERSION containing the if(0), and leave #else at the end with #error. This should be entirely safe. > > The second proposed fix should support > > any future system, but would be a bit more costly, assuming it's even > > possible. > > That would be better, yes. But it'd be more work to implement than > method (3) would be. I agree that it would be more work, but if you really don't accept solution #1, I'd be happy to work with the gnulib team on figuring out what solution #2 would entail, whether it's possible, and implementing it. > > To revisit why I don't like your proposed fix, for every bug we could > > get fixed by making an easy way for applications to test "is this > > musl?", we would have something like 10 new bugs created by people > > doing that. This is not just speculation; it's based on questions we > > get on the list and on IRC. Your idea of using such a test in the form > > of "if (is_musl) assume_non_broken();" is the first proposed use of > > this form I've seen. Every other request for an easy "if (is_musl)" > > test have been from people who wanted to do something that would cause > > bad breakage with future versions of musl. > > I'm afraid I don't follow this reasoning. Are you saying that, > method (3) is OK here but its use here might encourage people > to use it in other places where it's not OK? If so, let's add > a comment warning people to use method (3) carefully. I'm saying that musl intentionally does not provide any macros to identify itself. Changing this to help gnulib do one correct thing would not be worth dealing with all the incorrect usages it would lead to. And I'm confident that presence of such a macro would lead to lots of bugs in lots of applications, and to people blaming us for changing things when such incorrect applications break, on the basis of all the requests we have received from users for a __MUSL__ macro. In every case, we have been able to recommend clean portable solutions that did not involve hard-coding assumptions about musl. The same issue was discussed in the thread on musl and gnulib compatibility last year, and we reached mutually acceptable conclusions: instead of adding __MUSL__ and documenting ways for gnulib to poke at stdio internals (which are documented by musl as being subject to change between versions and not acceptable for applications to poke at), we added functions like __freadahead etc. and gnulib is simply probing for their existence. Rich
Re: musl compatibility
Il 12/06/2012 14:14, Eric Blake ha scritto: >> > While I agree with this, perhaps we can follow the suggestion and >> > replace "if (freadahead (f))" with "if (freading(f) && !feof(f))" in >> > closein.c. > freading() is just as much an extension as freadahead(), but it might be > an easier extension to implement. musl has it, too. Paolo
Re: musl compatibility
On 06/23/2012 08:10 AM, Paolo Bonzini wrote: > However, in the case of close_stdin, is this important for something > that happens rarely I tend to agree that it's not that important, but isn't this question moot now that freadahead has been ported to musl? (And welcome back from vacation)
Re: [PATCH] mountlist/ptsname_r: leverage AC_HEADER_MAJOR
On 02 Dec 2016 01:40, Bruno Haible wrote: > Pádraig Brady wrote in > http://lists.gnu.org/archive/html/bug-gnulib/2016-04/msg00022.html > and pushed in > http://lists.gnu.org/archive/html/bug-gnulib/2016-11/msg00116.html: > > > Context in > > http://lists.gnu.org/archive/html/bug-gnulib/2016-03/msg00025.html > > glibc-2.23 and musl now need this change it seems. > > The patch should be fine to apply though and fixes an immediate issue. > > glibc and musl cannot need a change that only affects the behaviour on > Solaris, AIX, and OSF/1. => There was no "immediate issue". > > Actually the only benefit of the change is that on Solaris, the code now > uses instead of . is somewhat > cleaner (doesn't define unrelated old cruft). i was just grepping for all users and bulk converting them over. you're certainly correct in the case of the ptsname_r module, the current code that calls major/minor isn't used on glibc/musl/etc... systems. -mike signature.asc Description: Digital signature
Problem building free.c with musl libc
Please see this issue report for the 'mmv' project, which I maintain: https://github.com/rrthomas/mmv/issues/23 Let me know if it's not as clear-cut as the report suggests to me; it seems though that the problem is simply with compiling the current version of free.c with musl as libc. -- https://rrt.sc3d.org
expm1l: Work around a NetBSD 10.0/i386 bug
On NetBSD 10.0/i386 I see this test failure:
FAIL: test-expm1l
=
../../gltests/test-expm1.h:41: assertion 'y >= x' failed
FAIL test-expm1l (exit status: 134)
The cause is that for arguments such as x = 2^-1075, expm1l(x) returns 0,
which it never should. (exp(x) - 1 is always ≥ x.)
This patch provides a workaround.
2024-04-06 Bruno Haible
expm1l: Work around a NetBSD 10.0/i386 bug.
* m4/expm1l.m4 (gl_FUNC_EXPM1L): Test the value of
expm1l(2^LDBL_MIN_EXP).
* doc/posix-functions/expm1l.texi: Mention the NetBSD 10.0/i386 bug.
* tests/test-expm1.h (test_function): Allow more deviation on
NetBSD/i386.
diff --git a/doc/posix-functions/expm1l.texi b/doc/posix-functions/expm1l.texi
index f8c68c9d45..f8a015b3da 100644
--- a/doc/posix-functions/expm1l.texi
+++ b/doc/posix-functions/expm1l.texi
@@ -15,9 +15,12 @@
This function is not declared on some platforms:
IRIX 6.5.
@item
+This function returns 0 instead of small positive values on some platforms:
+NetBSD 10.0/i386.
+@item
This function produces results which are accurate to only 16 digits on some
platforms:
-musl libc 1.2.2/arm64, musl libc 1.2.2/s390x, Mac OS X 10.5, NetBSD 10.0.
+musl libc 1.2.2/arm64, musl libc 1.2.2/s390x, Mac OS X 10.5, NetBSD
10.0/x86_64.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/m4/expm1l.m4 b/m4/expm1l.m4
index cdd51ae201..3e75891ac3 100644
--- a/m4/expm1l.m4
+++ b/m4/expm1l.m4
@@ -1,5 +1,5 @@
# expm1l.m4
-# serial 13
+# serial 14
dnl Copyright (C) 2010-2024 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -125,7 +125,7 @@ AC_DEFUN([gl_FUNC_EXPM1L]
long double (* volatile my_expm1l) (long double) = argc ? expm1l : dummy;
int result = 0;
/* This test fails on musl 1.2.2/arm64, musl 1.2.2/s390x, Mac OS X 10.5,
- NetBSD 10.0. */
+ NetBSD 10.0/x86_64. */
{
const long double TWO_LDBL_MANT_DIG = /* 2^LDBL_MANT_DIG */
(long double) (1U << ((LDBL_MANT_DIG - 1) / 5))
@@ -141,6 +141,18 @@ AC_DEFUN([gl_FUNC_EXPM1L]
if (!(err >= -100.0L && err <= 100.0L))
result |= 1;
}
+ /* This test fails on NetBSD 10.0/i386. */
+ {
+int i;
+long double x;
+volatile long double y;
+for (i = -1, x = 0.5L; i > LDBL_MIN_EXP; i--, x *= 0.5L)
+ ;
+/* Here i = LDBL_MIN_EXP, x = 2^LDBL_MIN_EXP. */
+y = my_expm1l (x);
+if (!(y >= x))
+ result |= 2;
+ }
return result;
}
]])],
diff --git a/tests/test-expm1.h b/tests/test-expm1.h
index 01128c491d..fc92617a05 100644
--- a/tests/test-expm1.h
+++ b/tests/test-expm1.h
@@ -52,7 +52,9 @@ test_function (void)
/* Error bound, in ulps. */
const DOUBLE err_bound =
(sizeof (DOUBLE) > sizeof (double) ?
-#if defined __i386__ && defined __FreeBSD__
+#if defined __i386__ && defined __NetBSD__
+ L_(1025.0)
+#elif defined __i386__ && defined __FreeBSD__
/* On FreeBSD/x86 6.4, the 'long double' type really has only 53 bits of
precision in the compiler but 64 bits of precision at runtime. See
<https://lists.gnu.org/r/bug-gnulib/2008-07/msg00063.html>.
@@ -83,6 +85,8 @@ test_function (void)
(sizeof (DOUBLE) > sizeof (double) ?
#if defined __i386__ && defined __FreeBSD__
L_(1536.0)
+#elif defined __i386__ && defined __NetBSD__
+ L_(1026.0)
#else
L_(11.0)
#endif
Re: bug#70104: "FAIL: test-canonicalize" coreutils v9.5 on musl libc
On 31/03/2024 10:02, Adept's Lab wrote: test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed ^ the only error log message I get. Fail was not presented with previous stable versions. This is on musl 1.1.24 as detailed at: https://github.com/coreutils/coreutils/issues/83 CC'ing bug-gnulib cheers, Pádraig
Re: stdioext on musl
On Sun, Jun 17, 2012 at 10:56:48PM +0200, Bruno Haible wrote: > Rich Felker wrote: > > 1. freadahead is inherently non-portable and has no working portable > > fallback version. At some point in the discussions, it was suggested > > that this function should not be pulled in except on old broken > > systems where stdio doesn't work and needs replacement functions. > > However, at least some packages, notably GNU M4, seem to use it > > directly. > > freadahead is one of the "extended" stdio functions that gnulib provides > portably. "Portable" sometimes means that some porting effort is needed. I find this a really warped definition of "portable". In a worst-case, it's not possible to implement many of these operations at all. If for example you had a system design where stdio was in kernelspace... To me, portable means write once, run anywhere. I could somewhat see extending one's definition of portable to mean "needs tuning for the particular system, but for any given system, there's at least one way to make it work". gnulib code is neither of these. > It was tested using the recipe from > http://lists.gnu.org/archive/html/bug-gnulib/2012-02/msg00022.html > All tests pass, except for a bug in setvbuf or __fbufsize, that I have > reported separately. > > There are two areas where musl libc can be modified to reduce the size > of this patch. > > 1) Currently, gnulib has to go to a great length to detect musl. >It uses the presence of __stdio_read and __stdio_write as an indicator; That's not valid. These are internal functions that could be renamed or disappear (e.g. be changed to visibility=hidden) at any time. I hope it doesn't sound like I'm just being pedantic here. All along, a big part of musl's design goal has been to avoid implementation lock-in caused by exposing internals to applications. By keeping the interface basically just the standard C and POSIX functions, arbitrary stable struct definitions and constants, and a moderate subset of BSD and GNU extension functions, musl keeps its options open to replace the internals of almost any component with an improved design, without breaking application binaries. When applications start probing around for internals like __stdio_read, this goal gets a lot harder. Not only do old interfaces that have nothing to do with a new implementation have to be preserved (and possibly emulated); the knowledge of what interfaces are being (ab)used by applications, and what properties applications are depending on, is not even readily available. > Why does musl make it so hard? Why does gnulib make it so hard? No other code we've encountered is full of so many ugly system-specific hacks. The majority of packages tested with musl _just_ _work_, or have a few minor issues like missing includes needed to get a type defined. >Can't you just define a preprocessor symbol that indicates musl? >Like so many other systems do? No, because the intent is NOT to support broken code like what's currently in gnulib that hard-codes implementation-internals of particular implementations, or worse, hard-codes assumptions that a particular implementation is missing certain interfaces. The latter causes serious breakage when the implementation later adds said functionality. Even if __MUSL__ did exist and provided you with sufficient information to know the version, using internals specific to a particular version would break dynamic-linked binaries used with a different version of the library. >gnulib needs this because some implementations provide the same functions >but they behave differently. E.g. __freading is broken in glibc < 2.7 >but not in musl. And __freading and __fwriting don't implement exactly >the same semantics as glibc. That's why real-life programs need to >#ifdef according to OS and libraries. Then either test that __freading works, or use something like #if defined(__GLIBC__) && __GLIBC__MAJOR__ == 2 && __GLIBC_MINOR__ < 7 to special-case the workaround only for particular known broken versions, and otherwise assume it works. Really I prefer just making a configure test to make sure it works... > 2) Provide 4 primitive functions. This is less offensive at least, but will configure even find them? Eric Blake offered to make it work that way, but you seem to want to test against macros that identify the implementation...? If gnulib is willing to _detect_ working functions rather than trying to detect musl, I'd be willing, albeit reluctant, to add them. My favorite option would really be a #3 though: ensure that gnulib, and gnulib-based apps, can work with a PURELY C/POSIX implementation with no extensions and no poking at implementation internals. Then, optionally do the ugly hacks if there's a compelling benefit, but make sure the code doesn't break when you can't identify the system as one you've got a set of hacks for. Rich
Re: musl, printf out-of-memory test
Rich Felker wrote:
> > but once I get
> >
> > configure:8979: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2
> > -Wall conftest.c >&5
> > configure:8982: $? = 0
> > configure:8986: $? = 139
> > configure:9031: result: no
> >
> > So, apparently, under memory stress, musl's printf has a probability of
> > between 10% and 50% of crashing with SIGSEGV (139 = 128 + 11).
>
> musl's printf does not do anything with memory except using a small
> constant amount of stack space (a few hundred bytes for non-float,
> somewhere around 5-7k for floating point). This is completely
> independent of the width/padding/precision; the implementation
> actually goes to a good bit of trouble to ensure that it can print any
> amount of padding efficiently without large or unbounded stack space
> usage.
>
> Is there any way the rlimits put in place could be preventing the
> stack from expanding beyond even one page the current number of pages,
> etc.?
I can reduce the program and the compilation options:
=== conftest.c =
#include
#include
int main()
{
int ret;
int err;
ret = printf ("%.500f", 1.0);
err = errno;
fprintf (stderr, "printf's return value = %d, errno = %d\n", ret, err);
return !(ret == 502 || (ret < 0 && err == ENOMEM));
}
$ musl-gcc -g -Wall conftest.c -o conftest
$ ./conftest > /dev/null ; echo $?
printf's return value = 502, errno = 0
0
$ ./conftest > /dev/null ; echo $?
printf's return value = 502, errno = 0
0
$ ./conftest > /dev/null ; echo $?
printf's return value = 502, errno = 0
0
$ ./conftest > /dev/null ; echo $?
Speicherzugriffsfehler (Speicherabzug geschrieben)
139
$ ./conftest > /dev/null ; echo $?
Speicherzugriffsfehler (Speicherabzug geschrieben)
139
I couldn't get useful info from gdb.
This is on Linux, 32-bit mode on a 64-bit system. Can you reproduce this?
Bruno
Re: test-pthread-rwlock failure on Pop!_OS 22.04 LTS
I wrote: > 3) This topic has been discussed in the glibc bug > https://sourceware.org/bugzilla/show_bug.cgi?id=13701 > where I have raised my voice for a writer-preferring implementation. The rwlock implementation being not writer-preferring appears to be only one contributing factor. I did "time ./test-pthread-rwlock" * in virtual machines with 8 CPUs: - Ubuntu 22.0460 sec (4 CPUs: 15 sec) - musl libc on Ubuntu 22.040.3 sec - Alpine Linux 0.3 sec - FreeBSD 14 1.4 sec - OpenBSD 7.5 2.5 sec - Solaris 11.422 sec (4 CPUs: 20 sec) - Cygwin 33..35 sec (4 CPUs: 25..27 sec) - mingw 12 sec - MSVC16 sec * outside VirtualBox: - Ubuntu 22.04 (12 CPUs) 6 sec - macOS 12 3.6 sec - AIX 7.1 4 sec Intermediate results: * While gl_cv_pthread_rwlock_rdlock_prefer_writer is - yes on macOS, FreeBSD, NetBSD, OpenBSD <= 6.0, Solaris, Cygwin, - no on glibc, musl libc, OpenBSD >= 6.5, AIX, Android, only glibc has the problem; musl libc, OpenBSD 7.5, AIX don't. * The first two measurements were done on the same Ubuntu 22.04 VM. This hints that kernel customization (scheduler, policies etc.) are not the cause — otherwise musl libc on Ubuntu 22.04 would have the same problem. * I don't understand why the same Ubuntu 22.04 outside VirtualBox works fine (6 seconds), whereas inside VirtualBox it's 60 seconds. But it's not entirely a VirtualBox or virtualization problem, since in Paul's case the system is running on the naked harware (no virtualization). So: - It seems to be a glibc problem. - But a large amount of CPU time is spent in the kernel. Which performance tools exist that can help understand the situation across the glibc / kernel boundary? Bruno
Re: stdioext on musl
On Sun, Jun 17, 2012 at 04:10:52PM -0700, Paul Eggert wrote: > On 06/17/2012 03:53 PM, Rich Felker wrote: > > By "better interfaces" do you mean the > > 4 already-mentioned stdio extension functions, or something else? > > Yes, I mean the functions that Bruno mentioned. > > > I mean will it find them without needing a special macro like > > __MUSL__? > > Having a symbol like __MUSL__ helps simplify gnulib's job, because > it needn't bother to use a heuristic like "if it has __stdio_read and > __stdio_write, it must be musl", but can simply use __MUSL__ directly. This heuristic is wrong. So is checking for musl. The correct check is to test for the _behavior_ you need and use the results of those tests. This is the most basic principle of autoconf. > If musl doesn't want to define __MUSL__, that's OK, gnulib can just > define __MUSL__ on its own using that heuristic, as in Bruno's patch. Nope, __MUSL__ is in the namespace reserved for the implementation. In particular, adding #ifdef __MUSL__ #error to any of the standard headers is valid, and it's what one of our users just suggested we do if this patch to gnulib is done as-is... It would be valid to define something in the application-reserved namespace, but there is no reliable test by which to determine whether to define it. __stdio_read is NOT public. > If the heuristic goes wrong in some future platform, we'll fix it. > This is normal; it's no big deal. That being said, it's nicer for > gnulib if musl announced its presence with a symbol like __MUSL__. It's nicer if gnulib plays by the same rules as everybody else rather than considering itself above the rules. Up until Bruno jumped in (when I was communicating mainly with Eric), I was pleasantly surprised at how sane and reasonable the discussion was. It completely defied the reputation gnulib has, and folks seemed genuinely interested in working with us and addressing the systemic non-portability problems of gnulib -- stuff like fixing all the fallback cases and removing the need for -DSLOW_BUT_NO_HACKS, etc. Then Bruno came back to us with this monstrosity of a patch that insists, for no good reason, on trying to detect musl specifically, thereby _increasing_ the amount of broken special-cased non-portable code in gnulib rather than modernizing it. I would really like to see gnulib modernize. I would like to see it work out-of-the-box, even if somewhat slowly, on ANY not-yet-invented system that satisfies the standard interface contracts. However gnulib is not my project, and it's not my business to tell you that you must do these things if you're horribly opposed to it. What is my business is that Bruno wants to start poking at internals of musl in a way that WILL BREAK in nearly every single application that's using gnulib, and that will have users coming to us with bug reports when gnulib is the code at fault. I can't and won't work with that. If it's your final decision to do things that way, the only option I'm left with is to keep publicly expressing frustration with how broken gnulib is. It's not the option I like, because I'm really sick of dealing with apps breaking because of gnulib already. I'd like to have a nice clean solution like we discussed with Eric last week, so I can get on to better things and not worry that compiling gnulib software is going to start breaking again -- or worse yet, that binaries using gnulib are going to stop working. Rich
Re: musl compatibility
Il 08/06/2012 12:19, Pedro Alves ha scritto: >> > Have you any plans to address these problems? In particular, it does >> > seem odd to place a burden on libc authors of porting gnulib to it, >> > rather than just not supporting those functions which require >> > non-standard APIs on such libc's. > I've heard such rants as well. The rants are IMO, misdirected. For instance, > IIRC, gnulib's freadahead use is caused by musl's printf not being posix > compliant, causing gnulib to pull in its printf replacement, which doesn't > work > on musl. A library that is new, actively maintained, and that calls itself > a "C/POSIX standard library" should really address that by making it's printf > posix compliant, so that gnulib's fallback doesn't even get built. It seems > that > nobody who is interested in musl has looked at gnulib's config.log to > understand > why does gnulib think musl's printf is not good enough. While I agree with this, perhaps we can follow the suggestion and replace "if (freadahead (f))" with "if (freading(f) && !feof(f))" in closein.c. Paolo
Re: [musl] Re: musl bugs found through gnulib
Some updates... On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: > There is a recipe, in <http://sourceware.org/glibc/wiki/Testing/Gnulib>, > that explains how to use gnulib to check a libc against bugs. When I apply > this to musl-0.9.1, I get this list of problems: > > Replacements of *printf, because of > [...] > checking whether printf survives out-of-memory conditions... no No idea. Copying out the test and running it directly, it passes just fine for me. Maybe gnulib has already replaced printf with its own malloc-using version by the time it gets to this test?? > Replacement of fdopen, because of > checking whether fdopen sets errno... no There was one bug here (failure to set errno when mode string was invalid) but I don't think that's the case gnulib was testing for. It seems gnulib wants an error for the "may fail" when the fd is invalid. > Replacement of futimens, because of > checking whether futimens works... no gnulib always forces this test to fail if __linux__ is defined. Rich
Re: stdioext on musl
On Tue, Jun 19, 2012 at 01:46:40PM +0200, Bruno Haible wrote: > Hi Rich, > > The patches that you've committed at > > http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=deb90c79e5c498fbb48de1423df034447f330e38 > > http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=e15171b8d8e80e8b5bcf4e95b1709697858f545a > go a long way at implementing the support that gnulib needs. Just > one question: When trying to use the new 4 functions, I get gcc warnings > > freadahead.c: In function 'freadahead': > freadahead.c:84:3: warning: implicit declaration of function '__freadahead' > [-Wimplicit-function-declaration] > freadptr.c: In function 'freadptr': > freadptr.c:105:3: warning: implicit declaration of function '__freadptr' > [-Wimplicit-function-declaration] > freadptr.c:105:3: warning: return makes pointer from integer without a cast > [enabled by default] > freadseek.c: In function 'freadptrinc': > freadseek.c:62:3: warning: implicit declaration of function '__freadptrinc' > [-Wimplicit-function-declaration] > fseterr.c: In function 'fseterr': > fseterr.c:49:3: warning: implicit declaration of function '__fseterr' > [-Wimplicit-function-declaration] > > Will you add declarations of these functions to a public .h file? > Or should gnulib provide these declarations? Yes, I simply forgot to add them. stdio_ext.h okay? Rich
Re: gnulib cross-compiling issue with musl
On Tue, Jun 18, 2013 at 01:09:10PM -0700, Paul Eggert wrote: > On 06/18/13 11:42, Rich Felker wrote: > > if > > you think it matters, you could add #elif defined _POSIX_VERSION > > containing the if(0) > > Yes, that should work, though it needs to check a couple ore > things as well. I pushed the following: does it work for you? > > fflush, fseeko: port to musl cross-compiles > * lib/fseeko.c (fseeko): Assume that fflushing stdin works if > on some implementation that (1) is not known to be buggy, > (2) claims conformance to POSIX.1-2008 or later, and (3) is being > cross-compiled to so we can't easily check for lack of > conformance. This is for cross-compiling to musl. > Reported by Rich Felker in > <http://lists.gnu.org/archive/html/bug-gnulib/2013-06/msg00043.html>. Thank you. This patch looks like it should solve the problem. I'll make sure it gets tested with someone on our team doing cross compiles and let you know if we run into any problems. Rich
Re: [PATCH] sigsegv: Fix build on ppc/musl
> On 13 Mar 2022, at 14:17, Bruno Haible wrote: > > Eric Blake wrote: >> On Wed, Mar 09, 2022 at 11:37:14PM -0800, Khem Raj wrote: >>> mcontext is not a standard layout so glibc and musl differ sadly. >>> >>> Fixes >>> ../../m4-1.4.19/lib/sigsegv.c: In function 'sigsegv_handler': >>> >>> ../../m4-1.4.19/lib/sigsegv.c:223:75: >>> error: 'mcontext_t' has no member named 'uc_regs'; did you mean 'gregs'? >>> >>> 223 | #define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) >>> ucp)->uc_mcontext.uc_regs->gregs[1] >>> | >>> ^~~ >> >> Thanks for the report. As this file comes from gnulib, the fix needs >> to go there first. > > Thanks for the report. I'm adding this patch to GNU libsigsegv: > https://git.savannah.gnu.org/gitweb/?p=libsigsegv.git;a=commitdiff;h=a6ff69873110c0a8ba6f7fd90532dbc11224828c > > and then this (derived) patch to Gnulib. > > I couldn't verify that it works, since there is no Linux distro that is based > on musl libc and is ported to Linux/powerpc (32-bit). There's at least Gentoo, Adélie, and at least for now, Void. Thanks for adding the patch and thanks to Khem for reporting it. Best, sam signature.asc Description: Message signed with OpenPGP
