[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gsl] test release for GSL 2.4

From: Patrick Alken
Subject: Re: [Help-gsl] test release for GSL 2.4
Date: Wed, 14 Jun 2017 16:19:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1

Thanks Mohammad,

  This is due to a file race condition I inadvertently introduced when
trying to make those tests C89 compliant. I have uploaded a fix to the
git, and will make a new test candidate release in a day or so, after
getting more feedback.

  I've sometimes wondered whether I should group all the GSL tests
together into one Makefile, so that the summary output gives all the
test statistics, rather than individual outputs for each module. I'm not
sure which design is better, and haven't seen much information about
this in the automake documentation.


On 06/14/2017 03:03 PM, Mohammad Akhlaghi wrote:
> Hi Patrick,
> The `./configure', `make', and `make check' commands ran successfully
> on my system (Arch Linux, GCC 7.1.1, GNU C Library 2.25).
> To speed up the build, I usually run the Make commands with `-j8' to
> build in parallel on 8 threads on this system. `make -j8' worked
> nicely and everything was built. But when I ran `make check -j8',
> there was a segmentation fault for the `vector' tests (in P.S.). So I
> removed the `-j8' and all tests passed. This is probably due to
> dependencies in a multi-threaded check (where the tests are built at
> the same time, not after each other).
> So, I had a look at `vector/'. It shows that indeed no
> dependencies are defined for these tests. We had the same issue in
> Gnuastro's `make check' and was able to solve it using an intermediate
> script to run the built programs (and thus not including
> `$(check_PROGRAMS)' in `TESTS'.
> In the link below you can see Gnuastro's `tests/' (we have
> merged all the tests of all the programs/libraries into one Makefile).
> In particular, you can see the part under the "Library checks" title
> (line 194) and its comments.
> The `multithread.c' test program depends on the output of another test
> (`mkprof/'). So we have not put `$(check_PROGRAMS)' in
> `TESTS' and instead defined a small script (`lib/')
> which depends on the output of the dependent test
> (`mkprof/', line 207).
> Ofcourse, in the current architecture, GSL's tests are not unified in
> one `', but are distributed over separate files with a
> handful of (sometimes only one) test(s) in each. So running the tests
> in parallel will not significantly improve the speed. But to avoid
> confusion in cases like this, it can good to define dependencies like
> this so those tests that depend on others don't fail.
> Thank you very much,
> Mohammad
> P.S.
> make[2]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> make[3]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> ../test-driver: line 95: 32689 Segmentation fault      (core dumped)
> "$@" > $log_file 2>&1
> FAIL: test_static
> PASS: test
> make[4]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> make[4]: Nothing to be done for 'all'.
> make[4]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> ============================================================================
> Testsuite summary for gsl 2.3.90
> ============================================================================
> # TOTAL: 2
> # PASS:  1
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> ============================================================================
> See vector/test-suite.log
> ============================================================================
> make[3]: *** [Makefile:741: test-suite.log] Error 1
> make[3]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> make[2]: *** [Makefile:849: check-TESTS] Error 2
> make[2]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> make[1]: *** [Makefile:927: check-am] Error 2
> make[1]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> make: *** [Makefile:961: check-recursive] Error 1

reply via email to

[Prev in Thread] Current Thread [Next in Thread]