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/25/2012 08:31 AM, Paul Eggert wrote:
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.
we still
* Bruno Haible (br...@clisp.org) [20120624 13:05]:
Unfortunately, a majority of the users (between 50% and 90%, I got the
impression) runs make; make install without make check.
From my impressions I'd agree that 80 to 90% onlty do make; make install.
And many of them would also ignore a
Paolo Bonzini wrote:
The test as it stands is error out on unsupported platforms unless
user specifies to use slow method.
My proposal is On unsupported platforms, use the slow method instead
of erroring out.
If we did this, nobody would report to bug-gnulib (or to the libc
On Sun, 24 Jun 2012 04:05:39 -0700, Bruno Haible wrote:
Paolo Bonzini wrote:
The test as it stands is error out on unsupported platforms unless
user specifies to use slow method.
My proposal is On unsupported platforms, use the slow method instead
of
On Sun, Jun 17, 2012 at 11:40 PM, Bruno Haible br...@clisp.org wrote:
Isaac Dunham wrote:
The test as it stands is error out on unsupported platforms unless
user specifies to use slow method.
My proposal is On unsupported platforms, use the slow method instead
of erroring out.
If we did
Isaac Dunham wrote:
The test as it stands is error out on unsupported platforms unless
user specifies to use slow method.
My proposal is On unsupported platforms, use the slow method instead
of erroring out.
If we did this, nobody would report to bug-gnulib (or to the libc maintainer)
the
Il 12/06/2012 03:22, Isaac Dunham ha scritto:
Performance, surely. But if there's
consensus that performance does not matter that
much with musl, perhaps we should default to the
slow version with musl.
The test as it stands is error out on unsupported platforms unless
user specifies to
Please don't forget fseterr, the other rude #erroring spot which fails
even though there is deactivated portable fallback code.
Subject: [PATCH] 6 syscalls is still better than a failed build
---
lib/fseterr.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
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
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 it be
On 06/09/2012 11:05 PM, Isaac Dunham wrote:
Is there any reason not to merge
Performance, surely. But if there's
consensus that performance does not matter that
much with musl, perhaps we should default to the
slow version with musl.
Is there any simple way to tell at compile-time,
or at
12 matches
Mail list logo
