On 13/02/2020 16.53, Benjamin Lorenz wrote: > On 13/02/2020 13.18, David Bremner wrote: >> Benjamin Lorenz <lor...@math.tu-berlin.de> writes: >>>> It looks like it's flint related? >>> >>> Yes, I think this is a bug in flint and for now I suggest disabling the >>> flint-interface of polymake with the configure option --without-flint on >>> mips64el. This has basically no functionality loss as polymake will use >>> its own generic polynomial arithmetic instead (it will be somewhat slower). >>> Currently rebuilding polymake to check the testsuite again but this will >>> take some time and I will report back tomorrow. >>> >> >> The easy thing would be to disable it everywhere. It is also possible to >> do it on an architecture specific basis. Do you think the (small) added >> complexity of the latter is worth it? > > It seems we might need some extra stuff for mips64el anyway as I see > some weird segfaults even without flint (at different testcases).
I finally got this running on mips64el: 1) update to polymake 4.0r1, this includes: - a (slightly adjusted) fix for gmp 6.2 - a fix for the TERM issue in the reproducible builds (FTBFS) - disables a libnormaliz test when libnormaliz is not configured - and some other bugfixes 2) switch off both flint and libnormaliz on mips64el with: --without-flint --without-libnormaliz The normaliz package also runs into a similar flint crash as it also uses flint for polynomial arithmetic. Switching off flint for all architectures would be ok but I really want to keep libnormaliz active on all other architectures. I have reported the flint crash upstream: https://github.com/wbhart/flint2/issues/614 3) switch the linker on mips64el: add -fuse-ld=bfd to LDFLAGS by default polymake will use -fuse-ld=gold if it is available but then exception handling doesn't seem to work on mips64el and I really don't want to investigate this any further. Benjamin
