>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-
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
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
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
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
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
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 lin
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 t
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
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:-)
Once the rem
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* |
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
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
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
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
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 :)
> &
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
Thank You.
... Necktwi
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
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 lo
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
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 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
.
musl has it, too.
Paolo
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
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
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
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)
I wrote:
> So far this facility is implemented in
> - glibc >= 2.29,
> - FreeBSD >= 10,
> - illumos,
> - Solaris >= 11.4 (with a bug in thrd_join),
> - AIX >= 7.1 (with terrible bugs in thrd_create and thrd_join).
Another correction: It's also implemented i
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
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
/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
(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 };
Field Type Platforms
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 Alpine uses musl li
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
[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 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
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
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
On 06/10/2012 05:43 AM, Rich Felker wrote:
If the latter is acceptable though, the stdio_ext.h function
__freading might suffice as an implementation.
On musl doesn't __freading actually return a count?
Perhaps we could just use that.
Rich Felker wrote:
checking whether printf supports the 'ls' directive... no
Yep, I caught this one a while back. It's fixed in git.
Good to hear that.
Bruno
__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
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
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
asing. (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 */
Eric Blake wrote:
> Both of these failed tests come from gnulib (added in cc); I'm not sure
> if they have been fixed in the meantime
They have been fixed in gnulib on 2018-02-24.
Bruno
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
> 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?
Bruno
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
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
address space layout randomization.
Anyway, it's fixed now.
I confirm that
http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=914949d321448bd2189bdcbce794dbae2c8ed16e
fixes the bug.
Bruno
On 06/24/2012 03:42 PM, John Spencer wrote:
anything is better than a failed build.
Isn't this discussion moot now, with respect to musl?
That is, I thought the problem with musl and gnulib
is fixed, so we don't have a failed build now.
If this discussion is about what to do with some other
new
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
+++ 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" ;;
+
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
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 comment /* musl */
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
;
if (posix_spawn_file_actions_addopen (, 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.
*
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
>= 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.
[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
[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
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
On Sun, 10 Jun 2012 19:00:54 -0700
Paul Eggert egg...@cs.ucla.edu 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
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
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
p.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, ma
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
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
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
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
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
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
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
On Thu, 17 Apr 2014 01:26:13 +0100
Pádraig Brady p...@draigbrady.com wrote:
On 04/15/2014 03:49 PM, Pádraig Brady wrote:
On 04/15/2014 03:43 PM, Natanael Copa wrote:
* lib/physmem.c (physmem_total): Some systems like musl libc does not
(yet) support _SC_PHYS_PAGES. Use the linux syscall
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.
specified a fallback (for example, replacing all non-ASCII characters
with NUL, '?', or '*').
The standards don't help in making the distinction.
Therefore whether you consider said glibc and libiconv behaviour as
"non-conforming" or not is irrelevant.
I have now adjusted the code to handle musl libc better.
Bruno
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
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_
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 enviro
> 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
Collin Funk wrote:
> I still think that the Musl behavior is unexpected enough that it
> warrants overriding though.
OK.
> 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 administr
",
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 modu
t (fd, )) 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.
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/manua
Bruno Haible wrote:
...
My thought in having musl skip the test is to maximize performance of
fdopen, assuming you might be using it in a situation like on a newly
accept()ed network connection where every syscall counts (think
multi-threaded httpd). For read-only fdopen, no syscalls
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
Hi,
Necktwi Ozfguah wrote:
> While I am building coreutils with musl on aarch64 (RaspberryPi 3B), 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 th
On Sun, Mar 24, 2019 at 07:23:16PM +0100, Bruno Haible wrote:
> Hi Rich,
>
> > -- 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.
>
> This is a highly theoretical use-case, isn't
* Bruno Haible:
> Yes and no. The code is not making assumptions about a particular iconv()
> implementation. But it needs to distinguish two categories of replacements
> done by iconv():
> - those that are harmless (for example when replacing a Unicode TAG
> character U+E00xx with an empty
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
I committed:
> 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_fil
ar *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, Open
lpath() 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 r
Rich Felker wrote:
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
Would you mind telling me how it's different and how
On 06/18/2012 06:27 AM, John Spencer wrote:
I just couldn't withstand to express my disgust
Please refrain from such rhetoric in the future.
The bug-gnulib mailing list is for discussing ways to
improve gnulib, and personal attacks get in the
way of its purpose.
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
2012-06-19 Bruno Haible br...@clisp.org
fdopen: Allow implementations that don't reject invalid fd arguments.
* m4/fdopen.m4 (gl_FUNC_FDOPEN): Let the test pass if fdopen(-1,...)
succeeds.
Reported by Rich Felker dal...@aerifal.cx.
Thanks, Bruno.
That
Jim == Jim Meyering j...@meyering.net writes:
Jim That is correct. It is a feature of gdb-7.0 and newer.
Jim You can inspect (watch/break-at/etc.) the same address and expect it
Jim to refer to the same memory location in multiple invocations.
Jim This makes gdb's command-line history even more
1 - 100 of 479 matches
Mail list logo
