>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
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
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
.
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
/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
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
[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 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
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
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
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
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
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
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 sysinfo first and
fallback to sysconf with _SC_PHYS_PAGES and _SC_PAGESIZE.
This looks good.
I confirmed the values
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 Br
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 it?
If you think POSIX should not specify things the way it does, please
Please patch the gnulib with
Hi,
Many people refuse to click on URLs that are hosted on an unknown domain,
moreover with the word 'click' and a long identifier in it. This is the
kind of URL that is most often used to invade our privacy and steal our
secrets.
Could you therefore please write a self-contained mail (no URLs)?
Hi Paul, Arnold, Jim,
If the 'dfa' module supposed to be multithread-safe?
I'm asking because dfa.c invokes
setlocale (LC_ALL, NULL),
and I've found out that this call is not MT-safe on musl libc, macOS,
FreeBSD, NetBSD, OpenBSD, AIX, Haiku, Cygwin, MSVC.
I'm working on a fix and would like
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
Reuben Thomas wrote:
> Having looked into this, it seems that the same issues apply to PATH_MAX,
> yet gnulib has a pathmax module to define PATH_MAX. What's different in
> that case?
Most systems have a PATH_MAX, only the Hurd doesn't.
Whereas only few systems have a NAME_MAX (musl lib
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
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
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 use
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
Hi,
Reuben suggested I contact upstream since we've been discussing on the
musl mailing list (m...@lists.openwall.com, archive at
http://www.openwall.com/lists/musl/) some of the difficulties that
have arisen out of gnulib and programs using it when building on musl
(http://www.etalabs.net/musl
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
ctions_t actions;
> if (posix_spawn_file_actions_init () != 0)
> return 1;
> if (posix_spawn_file_actions_addopen (, 1000, "foo", 0,
> O_RDONLY)
> == 0)
> return 2;
> return 0;
> }
>
>
> 2019-03-23 Bruno Haible
>
>
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
Hi,
It seems like physmem_total is broken with musl libc since
_SC_PHYS_PAGES is not implemented.
Would it be an idea to use sysinfo from sys/sysinfo.h first and then
fallback to the current _SC_PHYS_PAGES * _SC_PAGESIZE?
Something like:
diff --git a/lib/physmem.c b/lib/physmem.c
index
glibc's current implementation of fchmodat() is non-compliant when
AT_SYMLINK_NOFOLLOW is used. qemu just recently rediscovered what musl
libc has already known for three years: on kernels new enough to support
O_PATH, you can get a race-free implementation that supports
AT_SYMLINK_NOFOLLOW even
I wrote:
> 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.
Correction:
<https://pubs.opengroup.org/onlinepubs/9699919799/functio
Hello,
I'm using musl as a libc, and have run into a number of times that
gnulib stopped build.
By defining SLOW_BUT_NO_HACKS, the software ended up working.
This is the documented behavior, but it doesn't seem like the right one:
if a stub is usable enough to allow using it, why shouldn't
that they don't need.
Instead, wouldn't it be better to change gnulib/lib/stdio-impl.h
so that it groks the musl FILE object? Naturally, this would
inspect musl's internals, but that'd be no different from
all those other libraries that stdio-impl.h supports.
On Sun, Jun 17, 2012 at 11:57:05PM +0200, Bruno Haible wrote:
Rich Felker wrote:
considering printf broken, and replacing printf
because of this, is a big issue. Replacing printf is non-trivial
There is also another test that causes musl's printf to be overridden:
checking whether
1 - 100 of 271 matches
Mail list logo
