Re: have headers & libs, but cannot configure/make

[Mike Miller]

On Thu, Jan 12, 2017 at 16:33:13 -0800, Chris Roat wrote:
> I need to compile in the complex long support for UMFPACK, and I'm running
> into build errors that might be related to that.  See this one:
> 
> liboctave/array/CSparse.cc: In member function 'ComplexDET 
> SparseComplexMatrix::determinant(octave_idx_type&, double&, bool) const':
> liboctave/array/CSparse.cc:1119:51: error: invalid conversion from 'const 
> octave_idx_type* {aka const long int*}' to 'const long long int*' 
> [-fpermissive]
>                                       0, 1, control);
> <elided>
> umfpack_report_matrix.h:43:18: note: initializing argument 3 of 'long long 
> int umfpack_zl_report_matrix(long long int, long long int, const long long 
> int*, const long long int*, const double*, const double*, long long int, 
> const double*)'
>  SuiteSparse_long umfpack_zl_report_matrix
> 
> Can you tell if that's a config error?

Sure, looks like Octave is expecting UMFPACK to be using indices of type
long, but you have UMFPACK configured to use long long instead.

IIRC you are cross-compiling Octave on a 64-bit system for a 64-bit
target, so the following should apply the same as if you were compiling
natively.

I have no insight on what the right way to build SuiteSparse is, but I
can tell you what Octave does currently. The new default is to define
octave_idx_type to be int64_t when building natively on a system with
64-bit pointers. On my system, int64_t is long.

Octave then assumes that if its octave_idx_type is a 64-bit number, it
can pass that in place of a SuiteSparse_long. In your setup,
SuiteSparse_long appears to be a long long.

I want to say Octave is doing the right thing here, why is
SuiteSparse_long not long or int64_t in your build environment?

-- 
mike