>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-
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
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
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
.
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
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
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
[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.
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
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
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&q
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
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
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
On Mon, Jun 18, 2012 at 02:59:56AM +0200, Bruno Haible wrote:
For 2), the issue is that for a stream opened in write-only mode,
immediately after the fopen() call, gnulib expects fwriting(fp) to be
true:
Thanks. I committed a change whereby __freading now returns 1 whenever
the stream is
On 06/18/2012 06:11 PM, Rich Felker wrote:
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
Bruno Haible wrote:
Rich Felker wrote:
The problem was an obscure pointer-arithmetic overflow ...
where the stack pointer is near the 4GB boundary.
This explains also why it occurred only with a certain probability
outside gdb, but with 100% probability from within gdb: Apparently gdb
runs
Maxin B. John wrote:
> ./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:
>
>
,
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,
-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
, 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
26174991
/data/bruno/tmp/testdir3/conftest
f7f84000-f7ff8000 r-xp 08:05 26168372
/data/arch/x86-linux/inst-musl/lib/libc.so
f7ff8000-f7ffa000 rwxp 00073000 08:05 26168372
/data/arch/x86-linux/inst-musl/lib
Hi again,
Last year after a great deal of discussion, we got most of the issues
between gnulib and musl libc fixed. However there's one problem that
keeps coming up again and again from our users: when cross-compiling,
gnulib treats fseeko (well, actually fflush(stdin), which in turn
requires
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
On Alpine Linux 3.7.0, which uses musl libc, this test fails:
FAIL: test-mbrtowc5.sh
==
../../gltests/test-mbrtowc.c:106: assertion 'wc == c' failed
Aborted
FAIL test-mbrtowc5.sh (exit status: 134)
The issue is that in the C locale, musl uses the encoding that maps
0x00
Its coreutils-8.30 with musl-1.1.20 Linux aarch64, Gentoo.
I've untared coreutils-8.30.tar.xz
cd coreutils-8.30
./bootstrap
./configure CFLAGS="-march=armv8-a+crc -mtune=cortex-a53 -mcpu=cortex-a53
-ftree-vectorize -O2 -pipe -fomit-frame-pointer -Wno-error" CXXFLAGS=$CFLAGS
--prefix=&
On 9/11/19 2:58 PM, Cody Logan wrote:
> Hello,
>
> I'm attempting to cross-compile M4 1.4.18 with musl libc instead of
> glibc. The build completes, but when I run `make check`, I get two test
> failures. I'm running Arch Linux x86-64 on Linux 5.2.13 and
> cross-compil
[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. When I
On Tue, Jun 19, 2012 at 01:28:24AM +0200, Bruno Haible wrote:
Rich Felker wrote in
http://www.openwall.com/lists/musl/2012/06/18/8:
I've already discussed on this list why using an atexit function for
closing stdin or stdout is the heart of the problem and the source of
all the complexity
Rich Felker wrote:
stdio_ext.h okay?
OK, of course.
With these patches from your side, I am applying these changes to gnulib.
No need for #ifdef __MUSL__ for now.
2012-06-19 Bruno Haible br...@clisp.org
stdioext: Add support for musl libc.
* m4/fbufmode.m4
On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote:
[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
On 06/09/2012 06:39 PM, Rich Felker wrote:
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
))
return 2;
if (!(optind == 2))
return 3;
}
return 0;
}
===
$ musl-gcc foo.c -Wall; ./a.out; echo $?
0
$ musl-gcc foo.c -Wall -DOPTIND_MIN=0; ./a.out; echo $?
1
$ musl-gcc foo.c -Wall -DOPTIND_MIN=1; ./a.out
The musl people reported that gnulib's fbuftest was testing undefined
behaviour according to the ISO C standard:
http://www.openwall.com/lists/musl/2012/06/17/9
http://www.openwall.com/lists/musl/2012/06/17/10
This fixes it.
2012-06-22 Bruno Haible br...@clisp.org
fbufmode test: Don't
Currently localcharset uses m4/glibc21.m4 (ac_cv_gnu_library_2_1) to
figure out if charset.alias needs to be installed or not.
However, a separate ac_cv_iconv_has_standard_charset_names or similar
would be better so it can be controlled better. Especially important
with musl c library, where
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 sysinfo first and
fallback to sysconf with _SC_PHYS_PAGES and _SC_PAGESIZE
or use and set up some defines.
> >
> > Does this change fix a compilation problem? You did not say so.
>
> 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.
heh, i completely forgot about that thread ;)
-mike
signature.asc
Description: Digital signature
not say so.
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.
I suggested a makedev gnulib module in the thread above
as it's not just the headers that are varying,
as also some systems use mkdev() and some makedev
nux CentOS 5 nono, but it is partly working
Linux CentOS 6 nono, but it is partly working
Linux CentOS 7 noyes
Linux Alpine 3.7 (musl libc) nono, but it is partly working
Linux alpha (Deb
1 - 100 of 203 matches
Mail list logo
