On Thu, May 03, 2018 at 12:01:42 +0200, Sébastien Villemot wrote: > The most urgent problem is portability issues. 4.3.91 and 4.3.92 both failed to > compile on mips and s390x (very weird errors), and a few other arches could not > be tested due to lack of buildd availability. This must be fixed before we can > start the transition. I don't fully understand this yet, but I wanted to drop some notes on what I have found so far. The configure script in 4.4 tries to deduce the Fortran compiler's default integer size, as well as the Fortran integer size that works with the installed BLAS library (which may or may not be the compiler default). As I understand it, with gfortran, the default integer is always 32-bit. And in Debian, all Fortran libraries are compiled with the default options, hence with 32-bit integers. In the Octave configure summary on 32-bit arches, we should see 64-bit array dims and indexing: no 64-bit BLAS array dims and indexing: no and on 64-bit arches, we should see 64-bit array dims and indexing: yes 64-bit BLAS array dims and indexing: no However, on mips and powerpc arches, we see this 64-bit array dims and indexing: no 64-bit BLAS array dims and indexing: yes and both builds fail with the same error undefined reference to `MArray<long long>& operator-=<long long>(MArray<long long>&, long long const&)' and on s390x, we see this 64-bit array dims and indexing: yes 64-bit BLAS array dims and indexing: yes and the build fails with the obscure error (running the built Octave) error: __go_axes__: unknown error in fortran subroutine I think all of these errors might be resolved if we can fix the output of configure to select the correct Fortran default integer size. Unless someone really wants to look into root causes, we should be able to patch configure such that the Fortran integer size is always 32 bits, but I haven't looked into that yet. -- mike
Attachment:
signature.asc
Description: PGP signature