CoCoA » CoCoALib

I hope to resolve this while I'm here, and can see what happens on Gereon's cloud.

Of course, it is tedious having to do this because someone else was lazy... :-/

If I recall well, with the clang compiler there is a compile-time error with the platform-specific flags from the "rogue" GMP header.
However, with g++, the compiler generates executables, some of which may generate Illegal instruction errors at run-time... many CoCoALib tests failed, but many also passed.

The simple solution is not to use the compilation flags from the GMP header; but that won't work on my old MacBook (since the compiler defaults to 32-bits, but GMP is compiled with 64-bits).

Maybe I could add yet another configuration option to enable/disable getting the platform flags from gmp.h?

Past experience suggests that there are not normally such problems, so perhaps the default should be to extract the flags from gmp.h?

It could be tricky to write a script to decide automatically: I could do it for Gereon's machine, but then probably another similar problem will arise for a different platform and my gereon-specific test may not detect it... :-/

Another email (from Matthias Koeppe) reported much the same problem as Gereon had.

In replying to him, I wondered "aloud" whether it would not be better to make the default behaviour be not to extract compilation flags from gmp.h, and to have a configuration flag which says explicitly to take flags from gmp.h. This will mean that I have to specify the "get g++ flags from gmp" option when compiling on my old MacBook, but I've known for a long time that my old MacBook was a peculiar platform (so it seems reasonable that I should use special flags on it).

Such a change would not be "backward compatible", but the incompatibility would be noticed only by those using peculiar old computers like mine.

Any comments? Other ideas?

John Abbott wrote:

Such a change would not be "backward compatible", but the incompatibility would be noticed only by those using peculiar old computers like mine.

I admit I haven't understood this problem, nor the solution.
Would this also affect me, as those with a local compilation of gmp?

Anna: you can check whether you would have problems by configuring with the option *--ignore-gmp-cflags@* and then trying to compile. If compilation succeeds then you won't have any problem if I change the default behaviour to be "ignore GMP CFLAGS".

Let me know the outcome of your test.

John Abbott wrote:

Anna: you can check whether you would have problems by configuring with the option *--ignore-gmp-cflags@* and then trying to compile. If compilation succeeds then you won't have any problem if I change the default behaviour to be "ignore GMP CFLAGS".

./configure  --with-boost=/Users/bigatti/0.99/boost_1_61_0 --with-libgmp=/Users/bigatti/0.99/gmp-6.1.0/.libs/libgmp.a  --ignore-gmp-cflags

make
......
====================================
Good news: all CoCoALib tests passed
====================================

OK, then I should try to change the default behaviour... this evening's "entertainment"? :-/

One thing which puzzles me is that CoCoALib compiles fine and all tests pass on my old MacBook even without -m64 flag... I found this out by forgetting to specify the --acquire-gmp-cflags configuration option. Moreover, the time taken to run all the tests is essentially the same... in other words, it appears that the "fancy" platform-specific flags do not produce any measurable gain in speed (as far as the CoCoALib tests are concerned).

At this point I do not see any purpose in keeping even the option to extract compilation flags from gmp.h, so I now propose simply eliminating the relevant parts of the configure script (and any relevant auxiliary scripts).

Comments? Objections?

I have made a preliminary version of configure and various auxiliary scripts which do not expect extra CXXFLAGS for GMP.
Seems to work fine.