[Octave-bug-tracker] [bug #57591] Segmentation faults when running the test suite (mostly with clang)

[John W. Eaton]

Follow-up Comment #113, bug #57591 (project octave):

For the Fortran libraries we use (or the libraries like BLAS and Lapack that
have interfaces defined by their Fortran heritage) the important thing is not
pointer size (those libraries don't use pointers like we think of in C++ or
even modern Fortran) but the size of the integers that appear in their public
interfaces for things like array dimensions and pivot vectors (which sort of
serve the purpose of pointers, but are offsets into specific arrays).

On 64-bit systems, Octave now uses 64-bit integers for array dimensions and
indexing by default.  But most Linux distributions supply BLAS and Lapack
libraries (and other libraries that depend on them) compiled to use 32-bit
integers.  That's a Fortran legacy thing, where INTEGER and REAL (i.e., single
precision floating point numbers) typically occupy the same amount of
storage.

As already noted, we also currently handle the case of Octave built with
64-bit dimensions and indexing and calling Fortran libraries that are compiled
to use 32-bit integers for dimensions and indexing.

The current assumption is that all Fortran libraries that Octave uses will use
the same convention, either 32-bit or 64-bit integers for dimensions and
indexing.

I see no point in attempting to handle a mixture (some libraries using 32-bit
and others using 64-bit integers) because these libraries also depend on each
other.  It seems to me that mixing them arbitrarily is likely to lead to more
confusion than just requiring that they all use the same convention.

Note also that (at least as I understood the state of things the last time I
looked at this problem in detal) we don't really have a check to ensure that
all the libraries that Octave depends on actually use the same convention.  We
attempt to test the integer size of the BLAS library in the configure script. 
That test requires executing a program, so guesses (or configure options) are
used when cross compiling.  Whatever is determined for the BLAS library is
assumed for all the rest.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57591>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/