On FreeBSD 11.0 and 12.0, I see test failures
FAIL: test-mbmemcasecmp2.sh
===
../../gltests/test-mbmemcasecmp.h:359: assertion 'my_casecmp (input2, SIZEOF
(input2), input3, SIZEOF (input3)) == 0' failed
Abort trap (core dumped)
FAIL test-mbmemcasecmp2.sh (exit status: 134
On FreeBSD 12.0, I'm seeing this test failure:
../../gltests/test-unicodeio.c:67: assertion 'strcmp (result,
TEST_CODE_AS_UTF8) == 0' failed
Abort trap (core dumped)
FAIL test-unicodeio1.sh (exit status: 134)
This patch fixes it, by generalizing the patch that I added for NetBSD
on 2020-07
On FreeBSD/x86_64 the get-rusage-data test fails:
../../gltests/test-get-rusage-data.c:60: assertion 'value3 > value1' failed
FAIL test-get-rusage-data (exit status: 134)
This patch fixes it.
2020-12-07 Bruno Haible
get-rusage-data tests: Avoid test failure on FreeBSD/x86_64.
Hi Paul,
> >1) publish the current gnulib doc on www.gnu.org (as we do occasionally
> > anyway) [I can do that],
I just published the doc now.
> >2) write a news entry in https://savannah.gnu.org/projects/gnulib
> >3) approve it, also through https://savannah.gnu.org/projects/g
On 12/6/20 4:05 AM, Bruno Haible wrote:
Hi Paul,
I installed the attached patch to do that
Very nice! I made a tweak to the first example, to use printf() instead of
print(). Hope you agree.
Your reaction to the *_WRAPV names just goes to show how bad I am with
marketing
This set of
On FreeBSD 12.2/arm64, the brk() and sbrk() functions no longer exist [1].
This causes a link error in module get-rusage-data.
This patch fixes it.
[1] https://www.freebsd.org/cgi/man.cgi?query=sbrk&sektion=2
2020-12-07 Bruno Haible
get-rusage-data: Fix link error on FreeBSD 12.2/ar
On FreeBSD 12.0 — but not on FreeBSD 11.0 and 12.2 —, I'm seeing a test
failure of the Gnulib 'passfd' test:
recvfd: Permission denied
FAIL test-passfd (exit status: 16)
It fails with the same error, even when run as root.
Does anyone knows the reason?
Is it related to this advisory? [1][2]
Hello Daniel,
> I made the changes, and it almost works (at least errors which where
> generated before are gone).
> But now I get these:
> ...
Probably you're using a different version of mingw than I do. I'm adding
this change. Hope it helps.
2020-12-06 Bruno Haible
Tweak the Win
Hello Bruno,
Works wonderfully!
For the record I'm using x86_64-w64-mingw32-g++ (GCC) 10.2.0
Thanks again,
Daniel
On 07/12/2020 13:54, Bruno Haible wrote:
Hello Daniel,
I made the changes, and it almost works (at least errors which where
generated before are gone).
But now I get these:
...
On 2020-08-18 I encountered a weird interaction between gl_ANSI_CXX
(used when the C++ compiler is optional) and AC_PROG_CXX (used when
the C++ compiler is mandatory). I scratched my head against it.
Zack Weinberg scratched his head against it. The difference is that
Zack found the solution :-)
2
Hello Bruno,
Thanks for your reactivity!
I made the changes, and it almost works (at least errors which where
generated before are gone).
But now I get these:
../lib/stdlib.h: In member function
‘gnulib::_gl_putenv_wrapper::operator gnulib::_gl_putenv_wrapper::type()
const’:
../lib/std
11 matches
Mail list logo