The most astonishing is that this only happens with the 64 bits build. The 32 bits build runs well.
Maybe it is a good idea to remove everything and start a fresh build to be sure we are not looking at a hitch in the system or some leftovers. BTW I am running a build with make test now. I expect it to run for at least 7 hours. Cross-compiling on a virtual machine. Is this an expected behavior? Have fun 2017-04-17 16:57 GMT+02:00 Ben Pfaff <[email protected]>: > On Mon, Apr 17, 2017 at 03:57:31PM +0200, John Darrington wrote: > > On Mon, Apr 17, 2017 at 02:04:51PM +0200, Harry Thijssen wrote: > > It isn't. > > > > From my config.h: > > > > > > /* Define to `int' if <sys/types.h> doesn't define. */ > > #define uid_t int > > > > So uid_t is defined as int ... > > > > > > > On Mon, Apr 17, 2017 at 01:03:25PM +0200, Harry Thijssen wrote: > > > > > > mv -f $depbase.Tpo $depbase.Plo > > > libtool: compile: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H > > > -DEXEEXT=\".exe\" > > > -I. -I.. -I/usr/x86_64-w64-mingw32/sys-root/mingw/include > > .... > > > -I/usr/x86_64-w64-mingw32/sys-root/mingw/include > > > -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/libpng16 > -O2 -g > > > -pipe > > > -Wall -fexceptions --param=ssp-buffer-size=4 -mms-bitfields > -MT > > > fatal-signal.lo -MD -MP -MF .deps/fatal-signal.Tpo -c > fatal-signal.c > > > -DDLL_EXPORT -DPIC -o .libs/fatal-signal.o > > > In file included from fatal-signal.c:26:0: > > > ./signal.h:703:3: error: unknown type name 'uid_t' > > > uid_t si_uid; > > > ^~~~~ > > > > ... so I don't understand why it thinks that uid_t is an unknown type. > > Can you check that fatal-signal.c #includes "config.h" > > fatal-signal.c does include config.h, so this is extra strange. >
_______________________________________________ pspp-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/pspp-dev
