Thanks for reporting that. It's indeed a bug in the Gnulib tests. I installed
the attached patch to work around the problem by removing the questionable
tests. I don't see an easy way to test everything that we were trying to test.
>From 175e0bc72808d564074c4adcc72aeadb74adfcc6 Mon Sep 17 00:00:0
Your log says that the problem occurred when you ran this:
gcc -std=gnu11 -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I.. -g -O2 -MT fopen.lo -MD
-MP -MF .deps/fopen.Tpo -c fopen.c -fPIC -DPIC -o .libs/fopen.o
Can you send us the preprocessor output? That is, the output of these commands:
gcc -std=gn
Hi Ruth and John,
> Also, can you try compiling a very simple "hello world" program,
> like:
>
> #include
>
> void main (void)
> {
> printf ("hello world\n");
> }
When you use Gnulib, you need to add
#include
before an
Thank you so much for your help.
From: John Darrington
Sent: Thursday, August 27, 2020 3:59 PM
To: Ruth Waite
Cc: bug-gnu-p...@gnu.org ; bug-gnulib@gnu.org
Subject: Re: PSPP-BUG: PSPP make check errors [cross posting to
bug-gnulib@gnu.org]
At this point I'm go
At this point I'm going to have to ask the Gnulib developers if they can help.
It seems to be that something in your toolchain and Gnulib don't play nicely
together.
J'
On Thu, Aug 27, 2020 at 07:46:14PM +, Ruth Waite wrote:
Here are the results of make -k:
[ad3658@cus-survox
The problem is visible with glibc 2.32 under valgrind:
==20== Invalid read of size 1
==20==at 0x483DAB4: strcmp (vg_replace_strmem.c:847)
==20==by 0x109414: main (test-perror2.c:84)
==20== Address 0x4a1a3d0 is 0 bytes inside a block of size 17 free'd
==20==at 0x483A9F5: free (vg_repla
