Re: 2 test failures

Jeffrey Cliff <[email protected]> writes:

> tl;dr
>
> FAIL gama-local-xml-xml.sh (exit status: 134)
> FAIL gama-g3-xmllint-xsd.sh (exit status: 1)

I just did a full build, check, distcheck on NetBSD 10 amd64, gcc 10,
and all passed.  My sources were
0fd1e3ad348aaabcc8fb98cc49a0d1287fe52e23 but the diff from gama-2.31
does not look important.

> make -j8 -k check told me to mail these test results, so here they are.

I doubt that this is it, but when debugging it is best to reduce all
complexity possible, and if that helps bisect on it.  Thus, leave out
the -j8.  Also, -k keeps going on error, so I don't see why that makes
sense.  It would only serve to make it harder to figure out what's going
on.  If there is a failure, you want to have it obvious.  That's another
reason to omit -j; serial build output is usually much easier to read.

> OS: GNM/GNU+Linux
> gama 2.31
> gcc: gcc (GCC) 15.0.0 20240509 (experimental)

That's pretty new, and labeled experimental by itself.  What happens if
you use a more well-established compiler?

> CFLAGS: -D_GNU_SOURCE -std=gnu23 -Oz -march=native

Where did you get those?  gama  and is not
documented to require a particular C standard.  There should not be any
need to define _GNU_SOURCE.

> CXXFLAGS: -std=gnu++23 -Os -march=native

gama is documented to require C++14.  gnu++23 is not c++14.   gama looks
for and sets --std=c++14.

You also might as well leave out -Oz, -Os, -march=native, at least until
you can pass tests.

> [gama-local dropped a core dump during the test but since i'm
> compiling without debugging symbols it wasn't very useful]

Indeed, compiling without debugging when you need to isn't so useful!  I
suspect that's not what you meant.  In all seriousness, please turn on
"-g -O0" and then run gdb on the crash, or run the test under gdb.

All in all, I would suggest that you simplify everything you can and
report again.