Pádraig Brady wrote:
> Ah this issue is restricted to glibc's MALLOC_CHECK_ implementation.
Ah, that explains why I got different results than you did.
> I've reported the glibc bug at:
> https://sourceware.org/bugzilla/show_bug.cgi?id=27870
Thanks!
> The attached avoids this part of the test
On 15/05/2021 16:49, Bruno Haible wrote:
Hi Pádraig,
On glibc-2.31-5.fc32.x86_64 I'm seeing this test failure with coreutils,
since the tests are now checking for a specific errno.
I just checked a later Fedora 34 system which has the same issue.
For me, a testdir created through
Hi Pádraig,
> On glibc-2.31-5.fc32.x86_64 I'm seeing this test failure with coreutils,
> since the tests are now checking for a specific errno.
> I just checked a later Fedora 34 system which has the same issue.
For me, a testdir created through
./gnulib-tool --create-testdir
On 5/15/21 9:04 AM, Pádraig Brady wrote:
I'm wondering should we be more relaxed here as,
there is only one standardised ENOMEM error from realloc,
so code doesn't have to behave differently based on what the errno is.
We've already relaxed the errno test for reallocarray, where NetBSD
On 5/15/21 1:01 AM, Simon Josefsson via Gnulib discussion list wrote:
However, running ./bootstrap remains painfully slow.
Amen!!!
Then a second run of ./bootstrap in the directory would avoid the
gnulib-tool step, and only run autoreconf and friends. A new cfg.mk
variable to tell ./bootstrap
On glibc-2.31-5.fc32.x86_64 I'm seeing this test failure with coreutils,
since the tests are now checking for a specific errno.
I just checked a later Fedora 34 system which has the same issue.
Specifically test-realloc-gnu is enabled in coreutils
and it's failing as realloc is returning NULL as
Hi. There are a couple of different ways to use gnulib in projects:
https://www.gnu.org/software/gnulib/manual/html_node/VCS-Issues.html
At some point in some project I've used all variants, but today most of
my projects are converted into not commiting any gnulib files at all and
use gnulib's
On 5/14/21 5:07 PM, Bruno Haible wrote:
I won't spend any more time on fixing this Solaris-only code — when we
have code that works on all platforms in GNU libsigsegv.
At first I fixed this by having c-stack simply defer to libsigsegv if
installed, but I found that this didn't work on gcc211
