n 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* |
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 toolch
trol, 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:-)
On
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
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
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
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
>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-
(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 Pl
+++ 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 musl systems.
*-musl*) ac_cv_func_calloc_0_nonnull="guessing yes" ;;
+
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/localena
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 h
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
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
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/downloa
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 -Wal
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
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 :)
> >
>
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 lik
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
x27;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 el
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-tim
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
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 m
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
[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
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
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 empt
ion,
namely glibc >= 2.2, Solaris >= 7, UnixWare >= 7.1.4.MP4, Cygwin >= 1.7.34,
- Android API >= 23. */
+ Android API >= 23, musl libc, Haiku >= hrev58760. */
/* Return the number of pending (aka buffered, unflushed)
bytes on the stream, FP, that is open for
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
/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
+ -- --
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/unis
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 disapp
ice. 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
/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 POS
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/ins
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_
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 >
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
&g
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
s_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/posi
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' fail
* lib/fcntl.in.h (O_SEARCH): Redefine to O_RDONLY on musl,
which mistakenly defines it to be O_PATH on GNU/Linux.
Problem reported by Lasse Collin in:
https://bugs.gnu.org/75405
---
ChangeLog | 8
lib/fcntl.in.h | 6 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff
e-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 Alpi
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.
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
#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;
&g
Paul Eggert wrote:
> * lib/fcntl.in.h (O_SEARCH): Redefine to O_RDONLY on musl,
> which mistakenly defines it to be O_PATH on GNU/Linux.
> Problem reported by Lasse Collin in:
> https://bugs.gnu.org/75405
Let me document it:
2025-01-08 Bruno Haible
doc: Document the pre
; 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 conditiona
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
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
nt 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, FreeBS
lementations ...
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 com
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
> [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 explai
> [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 explai
SL__?
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, g
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
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 def
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
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
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: I
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 f
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
>
>
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):
>> fsus
uf, 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,
&g
Dmitry Bogatov wrote:
> > Example code:
> >
> > #include
> > #include
> >
> > int main()
> > {
> > int value = strverscmp("UNKNOWN", "2.2.0");
> > printf("%d\n", value);
> > return 0;
> &
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, Solari
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
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 direc
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 nont
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 de
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 mus
(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_H
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 af
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
].
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 t
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
IL: 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 (&#
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
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
Eli Schwartz wrote:
> > [case "$host_os" in
> > # Guess yes on musl systems.
> > *-musl* | midipix*) gl_cv_func_fpurge_works="guessing yes" ;;
> >
-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
P
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 implementin
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 you
",
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
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
On 11/26/24 3:42 AM, Bruno Haible wrote:
> Eli Schwartz reported that the 'fpurge' configure test,
> on musl libc, produces different results
> a) with CC="gcc"
> b) with CC="gcc -Werror=implicit-function-declaration" (which is used as
> an ap
irect 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
ntail, 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 bug
an extension as freadahead(), but it might be
> an easier extension to implement.
musl has it, too.
Paolo
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)
rchive/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.
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 l
5,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 lib
code might be a better solution.
Any such fix should work around the musl bug. (Gnulib doesn't worry
about uclibc.)
I expect such a patch would be welcome if someone had the time to write
and test it. In the meantime I installed the attached to Gnulib, to
document the incompatibility,
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/core
ted 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.
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
>
r.
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
1 - 100 of 576 matches
Mail list logo
