Re: error when compiling Octave in Cygwin

[Jaroslav Hajek]

On Thu, Dec 11, 2008 at 11:27 PM, Ivan Sutoris <address@hidden> wrote:
> Hi
>
> I've been trying to compile recent development sources under Windows,
> with Cygwin (gcc version 3.4.4). With freshly cloned repository,
> "configure" goes well (apart from complaining about incompatible BLAS
> library), but "make" stops with errors when compiling liboctave, in
> file oct-inttypes.cc. I'm attaching error messages in separate text
> file. My knowledge of C++ is pretty limited so I don't understand what
> these errors mean. I have compiled 3.0.3 in Cygwin before, so this
> seems to be limited to development sources. Has anyone else
> encountered this problem?
>
> Thanks for your time
> Ivan Sutoris
>

Hi Ivan,

the saturated integer arithmetics has been almost completely rewritten
for better performance since 3.0.x
See <http://www.nabble.com/integer-arithmetics-tt19602789.html#a19602789>
All the heavy templating inside octave_int_cmp_op is to allow safe
comparison of any two integers types
as well as reals with integers without doing useless tests.
I believe that the implementation is standard-conforming; and the call
gcc 3.4.4 gripes about, "mop<octave_int_cmp_op::lt>(double, uint64_t)
is unambigous, namely
"static bool octave_int_cmp_op::mop(double, uint64_t) [with xop =
octave_int_cmp_op::lt]" should be a clear winner, as it matches the
arguments exactly and no deduction is necessary.

Yeah I may still be wrong, but given that more recent compilers seem
to accept my code, I won't bet on it. Actually I suspected a possible
problem when coding that, but both compilers I tried had no problem,
and the alternative (introducing one more nested class) seemed less
elegant. gcc 4 is now out for 3.5 years, it doesn't seem right to me
to avoid standard-conforming code just to please an already obsolete
or almost-obsolete compiler.

So, my advice is the same as Dmitri's: use gcc 4 for compiling the
development sources. Or maybe try upgrading to 3.4.6, chances are that
the problem was fixed even in 3.4 series.

regards


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