Re: int64NDArray.cc cannot be complied on gcc-3.45 mingw for octave-3.1.52

[Jaroslav Hajek]

On Tue, Feb 10, 2009 at 4:54 AM, Tatsuro MATSUOKA <address@hidden> wrote:
> Hello
>
> I have tried to build octave-3.1.52 by gcc-3.45 on mingw.
>
> The code of 'int64NDArray.cc' cannot be complied on gcc-3.45 mingw for 
> octave-3.1.52
>
>
> oct-inttypes.h: In function `bool operator!=(const octave_int<T>&, const 
> double&) [with T = int64_t]':
> intNDArray.cc:56:   instantiated from `bool 
> intNDArray<T>::any_element_not_one_or_zero() const [with T
> = octave_int64]'
> int64NDArray.cc:32:   instantiated from here
> oct-inttypes.h:1059: error: call of overloaded `mop(int64_t, const double&)' 
> is ambiguous
> oct-inttypes.h:193: note: candidates are: static bool 
> octave_int_cmp_op::mop(T, double) [with xop =
> octave_int_cmp_op::n
> e, T = long long int]
> oct-inttypes.h:198: note:                 static bool 
> octave_int_cmp_op::mop(double, T) [with xop =
> octave_int_cmp_op::n
> e, T = double]
> oct-inttypes.h:211: note:                 static bool 
> octave_int_cmp_op::mop(double, uint64_t) [with
> xop = octave_int_cm
> p_op::ne]
> oct-inttypes.h:212: note:                 static bool 
> octave_int_cmp_op::mop(double, int64_t) [with
> xop = octave_int_cmp
> _op::ne]
> oct-inttypes.h:213: note:                 static bool 
> octave_int_cmp_op::mop(int64_t, double) [with
> xop = octave_int_cmp
> _op::ne]
> oct-inttypes.h:214: note:                 static bool 
> octave_int_cmp_op::mop(uint64_t, double) [with
> xop = octave_int_cm
> p_op::ne]
> make[2]: *** [int64NDArray.o] Error 1
> make[2]: Leaving directory `/home/octaves/octave-3.1.52/liboctave'
> make[1]: *** [liboctave] Error 2
> make[1]: Leaving directory `/home/octaves/octave-3.1.52'
> make: *** [all] Error 2
>
> Any suggestions?
>
> Regards
>
> Tatsuro
>

This is a known problem. The code is, however, standard-conforming
c++, it's just g++ 3.4 is not able to resolve the calls.

See the earlier threads:
http://www.nabble.com/error-when-compiling-Octave-in-Cygwin-tp20966037p20966037.html
http://www.nabble.com/Cast-ambiguity-compilation-error-tp21532844p21537554.html

I'm not really keen on obscuring standard-conforming code in the
mainstream sources to satisfy an obsolete compiler.
Would you be happy with a backward compatibility patch specifically for cygwin?

cheers

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz