Compilation issue

[gbonnoron]

Hi everyone,

I ran into some problems with the "make test" (I follow the build instructions on the github). Many tests (53 or 101 out of 122) fail to compile because of missing refs to chrono related functions. Adding a "#include " to tests/tools.h fix this.

Then I run inot other issues. Tests 98, 114 and 118 segfault. Let me know what information you need to tackle that !

Guillaume

[serge-sans-paille]

Hi @gbonnoron . What a small world :-)

I'm able to reproduce this, I'll yell at the culprit, fix this and get back to you :-)

[serge-sans-paille]

21 fixes the trivial issue, I still experiment a few segfaults.

[serge-sans-paille]

@gbonnoron if you run ulimit -s unlimited before running the test, do you still have the issues? (I don't)

[gbonnoron]

Hello @serge-sans-paille ! Thanks for your quick reply :-) It works also for me with unlimited stack size.

[carlosaguilarmelchor]

Hi @serge-sans-paille was I the culprit ? ;)

[carlosaguilarmelchor]

More seriously, should we move tests from poly_t to poly_p to avoid stack size issues ?

[tlepoint]

I thought we had done it, but apparently no. The question is how do we deal with tests/poly_p.cpp for large parameters? Maybe we could allow that test to fail (is it possible @serge-sans-paille?).

[serge-sans-paille]

one way to handle this would be to statically switch from one implem to the other depending on the (staticaly known) size. I'll have a look at it.

[carlosaguilarmelchor]

Maybe we could tell cmake to do ulimit -s before the test ?

[serge-sans-paille]

On Tue, Dec 06, 2016 at 01:50:26AM -0800, Carlos Aguilar Melchor wrote:

Maybe we could tell cmake to do ulimit -s before the test ?

That would be a terrible hack :-/ And that's too platform dependent...

[carlosaguilarmelchor]

Solved by PR#47