error when compiling Octave in Cygwin

[Ivan Sutoris]

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

[...]
make -C liboctave all
make[2]: Entering directory `/cygdrive/d/Development/octave-build/liboctave'
g++ -c -I/usr/include/freetype2 -I. -I../../octave-upstream/liboctave -I.. -I../liboctave -I../src -I../libcruft/misc -I../../octave-upstream -I../../octave-upstream/liboctave -I../../octave-upstream/src -I../../octave-upstream/libcruft/misc  -DHAVE_CONFIG_H -mieee-fp -Wall -W -Wshadow -Wold-style-cast -g -O2 -I/usr/include/freetype2 ../../octave-upstream/liboctave/oct-inttypes.cc -o oct-inttypes.o
../../octave-upstream/liboctave/oct-inttypes.cc:511: error: ambiguous template specialization `mop<octave_int_cmp_op::lt>' for `bool octave_int_cmp_op::mop(double, int64_t)'
../../octave-upstream/liboctave/oct-inttypes.cc:511: error: ambiguous template specialization `mop<octave_int_cmp_op::lt>' for `bool octave_int_cmp_op::mop(double, uint64_t)'
../../octave-upstream/liboctave/oct-inttypes.cc:511: error: ambiguous template specialization `mop<octave_int_cmp_op::lt>' for `bool octave_int_cmp_op::mop(int64_t, double)'
../../octave-upstream/liboctave/oct-inttypes.cc:511: error: ambiguous template specialization `mop<octave_int_cmp_op::lt>' for `bool octave_int_cmp_op::mop(uint64_t, double)'
../../octave-upstream/liboctave/oct-inttypes.cc:512: error: ambiguous template specialization `mop<octave_int_cmp_op::le>' for `bool octave_int_cmp_op::mop(double, int64_t)'
../../octave-upstream/liboctave/oct-inttypes.cc:512: error: ambiguous template specialization `mop<octave_int_cmp_op::le>' for `bool octave_int_cmp_op::mop(double, uint64_t)'
../../octave-upstream/liboctave/oct-inttypes.cc:512: error: ambiguous template specialization `mop<octave_int_cmp_op::le>' for `bool octave_int_cmp_op::mop(int64_t, double)'
../../octave-upstream/liboctave/oct-inttypes.cc:512: error: ambiguous template specialization `mop<octave_int_cmp_op::le>' for `bool octave_int_cmp_op::mop(uint64_t, double)'
../../octave-upstream/liboctave/oct-inttypes.cc:513: error: ambiguous template specialization `mop<octave_int_cmp_op::gt>' for `bool octave_int_cmp_op::mop(double, int64_t)'
../../octave-upstream/liboctave/oct-inttypes.cc:513: error: ambiguous template specialization `mop<octave_int_cmp_op::gt>' for `bool octave_int_cmp_op::mop(double, uint64_t)'
../../octave-upstream/liboctave/oct-inttypes.cc:513: error: ambiguous template specialization `mop<octave_int_cmp_op::gt>' for `bool octave_int_cmp_op::mop(int64_t, double)'
../../octave-upstream/liboctave/oct-inttypes.cc:513: error: ambiguous template specialization `mop<octave_int_cmp_op::gt>' for `bool octave_int_cmp_op::mop(uint64_t, double)'
../../octave-upstream/liboctave/oct-inttypes.cc:514: error: ambiguous template specialization `mop<octave_int_cmp_op::ge>' for `bool octave_int_cmp_op::mop(double, int64_t)'
../../octave-upstream/liboctave/oct-inttypes.cc:514: error: ambiguous template specialization `mop<octave_int_cmp_op::ge>' for `bool octave_int_cmp_op::mop(double, uint64_t)'
../../octave-upstream/liboctave/oct-inttypes.cc:514: error: ambiguous template specialization `mop<octave_int_cmp_op::ge>' for `bool octave_int_cmp_op::mop(int64_t, double)'
../../octave-upstream/liboctave/oct-inttypes.cc:514: error: ambiguous template specialization `mop<octave_int_cmp_op::ge>' for `bool octave_int_cmp_op::mop(uint64_t, double)'
../../octave-upstream/liboctave/oct-inttypes.cc:515: error: ambiguous template specialization `mop<octave_int_cmp_op::eq>' for `bool octave_int_cmp_op::mop(double, int64_t)'
../../octave-upstream/liboctave/oct-inttypes.cc:515: error: ambiguous template specialization `mop<octave_int_cmp_op::eq>' for `bool octave_int_cmp_op::mop(double, uint64_t)'
../../octave-upstream/liboctave/oct-inttypes.cc:515: error: ambiguous template specialization `mop<octave_int_cmp_op::eq>' for `bool octave_int_cmp_op::mop(int64_t, double)'
../../octave-upstream/liboctave/oct-inttypes.cc:515: error: ambiguous template specialization `mop<octave_int_cmp_op::eq>' for `bool octave_int_cmp_op::mop(uint64_t, double)'
../../octave-upstream/liboctave/oct-inttypes.cc:516: error: ambiguous template specialization `mop<octave_int_cmp_op::ne>' for `bool octave_int_cmp_op::mop(double, int64_t)'
../../octave-upstream/liboctave/oct-inttypes.cc:516: error: ambiguous template specialization `mop<octave_int_cmp_op::ne>' for `bool octave_int_cmp_op::mop(double, uint64_t)'
../../octave-upstream/liboctave/oct-inttypes.cc:516: error: ambiguous template specialization `mop<octave_int_cmp_op::ne>' for `bool octave_int_cmp_op::mop(int64_t, double)'
../../octave-upstream/liboctave/oct-inttypes.cc:516: error: ambiguous template specialization `mop<octave_int_cmp_op::ne>' for `bool octave_int_cmp_op::mop(uint64_t, double)'
../../octave-upstream/liboctave/oct-inttypes.h: In function `bool operator<(const double&, const octave_int<T>&) [with T = uint64_t]':
../../octave-upstream/liboctave/oct-inttypes.cc:402:   instantiated from here
../../octave-upstream/liboctave/oct-inttypes.h:1054: error: call of overloaded `mop(const double&, uint64_t)' is ambiguous
../../octave-upstream/liboctave/oct-inttypes.h:193: note: candidates are: static bool octave_int_cmp_op::mop(T, double) [with xop = octave_int_cmp_op::lt, T = double]
../../octave-upstream/liboctave/oct-inttypes.h:198: note:  static bool octave_int_cmp_op::mop(double, T) [with xop = octave_int_cmp_op::lt, T = long long unsigned int]
../../octave-upstream/liboctave/oct-inttypes.cc:60: note:  static bool octave_int_cmp_op::mop(uint64_t, double) [with xop = octave_int_cmp_op::lt]
../../octave-upstream/liboctave/oct-inttypes.cc:80: note:  static bool octave_int_cmp_op::mop(int64_t, double) [with xop = octave_int_cmp_op::lt]
../../octave-upstream/liboctave/oct-inttypes.cc:127: note:  static bool octave_int_cmp_op::mop(double, uint64_t) [with xop = octave_int_cmp_op::lt]
../../octave-upstream/liboctave/oct-inttypes.cc:135: note:  static bool octave_int_cmp_op::mop(double, int64_t) [with xop = octave_int_cmp_op::lt]
../../octave-upstream/liboctave/oct-inttypes.h: In function `bool operator<(const double&, const octave_int<T>&) [with T = int64_t]':
../../octave-upstream/liboctave/oct-inttypes.cc:437:   instantiated from here
../../octave-upstream/liboctave/oct-inttypes.h:1054: error: call of overloaded `mop(const double&, int64_t)' is ambiguous
../../octave-upstream/liboctave/oct-inttypes.h:193: note: candidates are: static bool octave_int_cmp_op::mop(T, double) [with xop = octave_int_cmp_op::lt, T = double]
../../octave-upstream/liboctave/oct-inttypes.h:198: note:  static bool octave_int_cmp_op::mop(double, T) [with xop = octave_int_cmp_op::lt, T = long long int]
../../octave-upstream/liboctave/oct-inttypes.cc:60: note:  static bool octave_int_cmp_op::mop(uint64_t, double) [with xop = octave_int_cmp_op::lt]
../../octave-upstream/liboctave/oct-inttypes.cc:80: note:  static bool octave_int_cmp_op::mop(int64_t, double) [with xop = octave_int_cmp_op::lt]
../../octave-upstream/liboctave/oct-inttypes.cc:127: note:  static bool octave_int_cmp_op::mop(double, uint64_t) [with xop = octave_int_cmp_op::lt]
../../octave-upstream/liboctave/oct-inttypes.cc:135: note:  static bool octave_int_cmp_op::mop(double, int64_t) [with xop = octave_int_cmp_op::lt]
../../octave-upstream/liboctave/oct-inttypes.cc: In function `octave_int<T> pow(const octave_int<T>&, const octave_int<T>&) [with T = uint8_t]':
../../octave-upstream/liboctave/oct-inttypes.cc:613:   instantiated from here
../../octave-upstream/liboctave/oct-inttypes.cc:541: warning: comparison is always false due to limited range of data type
../../octave-upstream/liboctave/oct-inttypes.cc: In function `octave_int<T> pow(const octave_int<T>&, const octave_int<T>&) [with T = uint16_t]':
../../octave-upstream/liboctave/oct-inttypes.cc:614:   instantiated from here
../../octave-upstream/liboctave/oct-inttypes.cc:541: warning: comparison is always false due to limited range of data type
../../octave-upstream/liboctave/oct-inttypes.cc: In function `octave_int<T> pow(const octave_int<T>&, const octave_int<T>&) [with T = uint32_t]':
../../octave-upstream/liboctave/oct-inttypes.cc:615:   instantiated from here
../../octave-upstream/liboctave/oct-inttypes.cc:541: warning: comparison between signed and unsigned integer expressions
../../octave-upstream/liboctave/oct-inttypes.cc: In function `octave_int<T> pow(const octave_int<T>&, const octave_int<T>&) [with T = uint64_t]':
../../octave-upstream/liboctave/oct-inttypes.cc:616:   instantiated from here
../../octave-upstream/liboctave/oct-inttypes.cc:541: warning: comparison between signed and unsigned integer expressions
make[2]: *** [oct-inttypes.o] Error 1
make[2]: Leaving directory `/cygdrive/d/Development/octave-build/liboctave'
make[1]: *** [liboctave] Error 2
make[1]: Leaving directory `/cygdrive/d/Development/octave-build'
make: *** [all] Error 2

[Dmitri A. Sergatskov]

On Thu, Dec 11, 2008 at 4:27 PM, Ivan Sutoris <ivan.sutoris@...> wrote:
> Hi
>
> I've been trying to compile recent development sources under Windows,
> with Cygwin (gcc version 3.4.4). With freshly cloned repository,
                       ^^^^^^^^^^^^^^^^^
This is suspiciously old.  Can you try 4.3.2 or something?
I see that is is shipped with cygwin as gcc4.
You can get configure to pick it up by doing
./configure CC=gcc4

You may need to provide configure with proper fortran compiler
in a similar manner:

./configure CC=gcc4 F77=....

> Thanks for your time
> Ivan Sutoris
>

Sincerely,

Dmitri.
--

[Jaroslav Hajek-2]

On Thu, Dec 11, 2008 at 11:27 PM, Ivan Sutoris <ivan.sutoris@...> 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

[Ivan Sutoris]

On Fri, Dec 12, 2008 at 11:19 AM, Jaroslav Hajek <highegg@...> wrote:

> On Thu, Dec 11, 2008 at 11:27 PM, Ivan Sutoris <ivan.sutoris@...> wrote:
> 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

Thanks for the replies. I'm not insisting on using 3.4.4, it's just
the default version in Cygwin :) Following Dmitri's advice, I found
out that Cygwin includes also gcc 4.3.2 (executables have suffix
"-4"), so I tried to run configure script with parameters "CC=gcc-4
CXX=g++-4 F77=gfortran-4", which went well. The same errors, however,
appeared again during compilation. Are there any other configure flags
one should setup?

Ivan Sutoris

[Jaroslav Hajek-2]

On Fri, Dec 12, 2008 at 2:12 PM, Ivan Sutoris <ivan.sutoris@...> wrote:

> On Fri, Dec 12, 2008 at 11:19 AM, Jaroslav Hajek <highegg@...> wrote:
>> On Thu, Dec 11, 2008 at 11:27 PM, Ivan Sutoris <ivan.sutoris@...> wrote:
>> 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
>
> Thanks for the replies. I'm not insisting on using 3.4.4, it's just
> the default version in Cygwin :) Following Dmitri's advice, I found
> out that Cygwin includes also gcc 4.3.2 (executables have suffix
> "-4"), so I tried to run configure script with parameters "CC=gcc-4
> CXX=g++-4 F77=gfortran-4", which went well. The same errors, however,
> appeared again during compilation. Are there any other configure flags
> one should setup?
>

No. Please verify in Makeconf that your configuration was properly
applied (or may have seen that during the compilation from the
commands).

Can you try compiling (not linking) the attached test program and tell
me the result? To be sure, I asked about the issue on comp-lang-c++.
But it seems to me that either there's a mistake on your side, or
you've discovered a bug in the cygwin port of gcc. In the latter case,
your proper way is to file a bug report to cygwin maintainers.

regards,



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

[test.cc]

---

class A {};

template <class X, class T> void method (double u, T v);

template <class X> void method (double u, long v);

int main ()
{
  double u; long v;
  method<A> (u, v);
}

---

[Ivan Sutoris]

On Fri, Dec 12, 2008 at 2:28 PM, Jaroslav Hajek <highegg@...> wrote:

> On Fri, Dec 12, 2008 at 2:12 PM, Ivan Sutoris <ivan.sutoris@...> wrote:
>> Thanks for the replies. I'm not insisting on using 3.4.4, it's just
>> the default version in Cygwin :) Following Dmitri's advice, I found
>> out that Cygwin includes also gcc 4.3.2 (executables have suffix
>> "-4"), so I tried to run configure script with parameters "CC=gcc-4
>> CXX=g++-4 F77=gfortran-4", which went well. The same errors, however,
>> appeared again during compilation. Are there any other configure flags
>> one should setup?
>>
>
> No. Please verify in Makeconf that your configuration was properly
> applied (or may have seen that during the compilation from the
> commands).
>
> Can you try compiling (not linking) the attached test program and tell
> me the result? To be sure, I asked about the issue on comp-lang-c++.
> But it seems to me that either there's a mistake on your side, or
> you've discovered a bug in the cygwin port of gcc. In the latter case,
> your proper way is to file a bug report to cygwin maintainers.
>
> regards,
>
>
>
> --
> RNDr. Jaroslav Hajek
> computing expert
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
>

I'm attaching Makeconf, but it seems that right executables were
called. I tried to compile your program with both versions of
compiler, and there is indeed a difference:

$ g++ -c test.cc
test.cc: In function `int main()':
test.cc:10: error: call of overloaded `method(double&, long int&)' is ambiguous
test.cc:3: note: candidates are: void method(double, T) [with X = A, T
= long int]
test.cc:5: note:  void method(double, long int) [with X = A]

$ g++-4 -c test.cc
[... no errors here]

Regards
Ivan Sutoris

[Dmitri A. Sergatskov]

On Fri, Dec 12, 2008 at 7:55 AM, Ivan Sutoris <ivan.sutoris@...> wrote:

>
> $ g++-4 -c test.cc
> [... no errors here]
>

So, perhaps you need to specify CXX=g++-4 for the configure as well...

> Regards
> Ivan Sutoris
>

Dmitri.
--

[Marco atzeri-3]

--- Ivan Sutoris ha scritto:

>
> Thanks for the replies. I'm not insisting on using
> 3.4.4, it's just
> the default version in Cygwin :) Following Dmitri's
> advice, I found
> out that Cygwin includes also gcc 4.3.2 (executables
> have suffix
> "-4"), so I tried to run configure script with
> parameters "CC=gcc-4
> CXX=g++-4 F77=gfortran-4", which went well. The same
> errors, however,
> appeared again during compilation. Are there any
> other configure flags
> one should setup?
>
> Ivan Sutoris
>

the cygwin settings for gcc-4 and octave 3.0.3
seems to work fine also on 3.1.51

        configure --libexecdir=/usr/lib \
                --enable-shared \
                CFLAGS="-Dtimezone=_timezone" \
                CC=gcc-4  F77=gfortran-4 \
                CXX=g++-4 CPP=cpp-4  


Regards
Marco

cygwin octave mantainer


     

[Ivan Sutoris]

On Fri, Dec 12, 2008 at 4:36 PM, Marco Atzeri <marco_atzeri@...> wrote:

>
> --- Ivan Sutoris ha scritto:
>
>
> the cygwin settings for gcc-4 and octave 3.0.3
> seems to work fine also on 3.1.51
>
>        configure --libexecdir=/usr/lib \
>                --enable-shared \
>                CFLAGS="-Dtimezone=_timezone" \
>                CC=gcc-4  F77=gfortran-4 \
>                CXX=g++-4 CPP=cpp-4
>
>
> Regards
> Marco
>
> cygwin octave mantainer
>
>
>
>

Thanks for reply, but even with these flags, errors persist. I think
that 3.1.51 snapshot was made before Jaroslav's changes to integer
arithmetics, so the problem (if there is one) would not show there.
During weekend, I'll try to compile again on different computer to see
if it is individual problem with my Cygwin installation, or more
general bug.

Regards
Ivan Sutoris

[Jaroslav Hajek-2]

On Fri, Dec 12, 2008 at 2:55 PM, Ivan Sutoris <ivan.sutoris@...> wrote:

> On Fri, Dec 12, 2008 at 2:28 PM, Jaroslav Hajek <highegg@...> wrote:
>> On Fri, Dec 12, 2008 at 2:12 PM, Ivan Sutoris <ivan.sutoris@...> wrote:
>>> Thanks for the replies. I'm not insisting on using 3.4.4, it's just
>>> the default version in Cygwin :) Following Dmitri's advice, I found
>>> out that Cygwin includes also gcc 4.3.2 (executables have suffix
>>> "-4"), so I tried to run configure script with parameters "CC=gcc-4
>>> CXX=g++-4 F77=gfortran-4", which went well. The same errors, however,
>>> appeared again during compilation. Are there any other configure flags
>>> one should setup?
>>>
>>
>> No. Please verify in Makeconf that your configuration was properly
>> applied (or may have seen that during the compilation from the
>> commands).
>>
>> Can you try compiling (not linking) the attached test program and tell
>> me the result? To be sure, I asked about the issue on comp-lang-c++.
>> But it seems to me that either there's a mistake on your side, or
>> you've discovered a bug in the cygwin port of gcc. In the latter case,
>> your proper way is to file a bug report to cygwin maintainers.
>>
>> regards,
>>
>>
>>
>> --
>> RNDr. Jaroslav Hajek
>> computing expert
>> Aeronautical Research and Test Institute (VZLU)
>> Prague, Czech Republic
>> url: www.highegg.matfyz.cz
>>
>
> I'm attaching Makeconf, but it seems that right executables were
> called. I tried to compile your program with both versions of
> compiler, and there is indeed a difference:
>
> $ g++ -c test.cc
> test.cc: In function `int main()':
> test.cc:10: error: call of overloaded `method(double&, long int&)' is ambiguous
> test.cc:3: note: candidates are: void method(double, T) [with X = A, T
> = long int]
> test.cc:5: note:  void method(double, long int) [with X = A]
>
> $ g++-4 -c test.cc
> [... no errors here]
>
> Regards
> Ivan Sutoris
>

Thanks for this test. This is really weird, because I think that the
test program is exactly the delicate overload problem that occurs in
oct-inttypes.h. However, you Makeconf seems to be OK (contains
CXX=g++-4).

Meanwhile, I think I resolved the conformance question - for technical
details, see the discussion on comp.lang.c++:
<http://groups.google.com/group/comp.lang.c++/browse_frm/thread/398e6ba0047f902a/bcb993f190dbbf65#bcb993f190dbbf65>.
Unless anyone proves my reasoning wrong, the result is that the code
is indeed standard-conforming.
Can you again give the error output from make, this time with gcc 4?
I'm very surprised that it didn't even change - that's suspicious. Can
other people try building on Cygwin? If the problem persists, I think
it's a bug in the cygwin gcc port.

In that case, I'd say file a bug for cygwin, and I will provide you a
special cygwin patch, because in principle, I don't think it's good to
change std-conforming code due to compiler bugs (unless they occur on
majority of platforms).

regards

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

[Marco atzeri-3]

--- Jaroslav Hajek  ha scritto:

>
> Thanks for this test. This is really weird, because
> I think that the
> test program is exactly the delicate overload
> problem that occurs in
> oct-inttypes.h. However, you Makeconf seems to be OK
> (contains
> CXX=g++-4).
>
> Meanwhile, I think I resolved the conformance
> question - for technical
> details, see the discussion on comp.lang.c++:
>

<http://groups.google.com/group/comp.lang.c++/browse_frm/thread/398e6ba0047f902a/bcb993f190dbbf65#bcb993f190dbbf65>.

> Unless anyone proves my reasoning wrong, the result
> is that the code
> is indeed standard-conforming.
> Can you again give the error output from make, this
> time with gcc 4?
> I'm very surprised that it didn't even change -
> that's suspicious. Can
> other people try building on Cygwin? If the problem
> persists, I think
> it's a bug in the cygwin gcc port.
>

built on cygwin with
configure --libexecdir=/usr/lib --enable-shared
CFLAGS="-Dtimezone=_timezone" CC=gcc-4  F77=gfortran-4
CXX=g++-4 CPP=cpp-4


make[2]: Entering directory
`/pub/hg/octave-build/liboctave'
g++-4 -c -I/usr/include/freetype2 -I.
-I../../octave/liboctave -I.. -I../liboctave -I../src
-I../libcr
uft/misc -I../../octave -I../../octave/liboctave
-I../../octave/src -I../../octave/libcruft/misc  -DHA
VE_CONFIG_H -mieee-fp -Wall -W -Wshadow
-Wold-style-cast -g -O2 -I/usr/include/freetype2
../../octave/
liboctave/oct-inttypes.cc -o oct-inttypes.o
Putting child 0x01ca70a0 (oct-inttypes.o) PID 412 on
the chain.
Live child 0x01ca70a0 (oct-inttypes.o) PID 412
../../octave/liboctave/oct-inttypes.cc:511: error:
ambiguous template specialization 'mop<octave_int_c
mp_op::lt>' for 'bool octave_int_cmp_op::mop(double,
int64_t)'
../../octave/liboctave/oct-inttypes.cc:511: error:
ambiguous template specialization 'mop<octave_int_c
mp_op::lt>' for 'bool octave_int_cmp_op::mop(double,
uint64_t)'
../../octave/liboctave/oct-inttypes.cc:511: error:
ambiguous template specialization 'mop<octave_int_c
mp_op::lt>' for 'bool octave_int_cmp_op::mop(int64_t,
double)'
../../octave/liboctave/oct-inttypes.cc:511: error:
ambiguous template specialization 'mop<octave_int_c
mp_op::lt>' for 'bool octave_int_cmp_op::mop(uint64_t,
double)'

> In that case, I'd say file a bug for cygwin, and I
> will provide you a
> special cygwin patch, because in principle, I don't
> think it's good to
> change std-conforming code due to compiler bugs
> (unless they occur on
> majority of platforms).
>

gcc-4 is still on test in cygwin, so a specific
problem is possible.

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

Regards
Marco


     

[Ivan Sutoris]

While compiling on another PC (errors are still there), I noticed that
autogen.sh gives several warnings,(attached below). I don't know if
they are related to this problem, but I thought I post them just to be
sure. Anyway, thanks to all for assistance, but I guess it will be
simpler if I try to compile Octave using virtual machine with Linux
for the time being.

Regards
Ivan Sutoris

calling autoconf and autoheader...
/cygdrive/d/Development/octave-devsrc
configure.in:59: warning: AC_COMPILE_IFELSE was called before
AC_USE_SYSTEM_EXTENSIONS
/usr/src/packages/autoconf/26/autoconf2.5-2.63-1/src/autoconf-2.63/lib/autoconf/specific.m4:386:
AC_USE_SYSTEM_EXTENSIONS is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.63-1/src/autoconf-2.63/lib/autoconf/specific.m4:454:
AC_AIX is expanded from...
configure.in:59: the top level
configure.in:59: warning: AC_RUN_IFELSE was called before
AC_USE_SYSTEM_EXTENSIONS
configure.in:60: warning: AC_COMPILE_IFELSE was called before
AC_USE_SYSTEM_EXTENSIONS
/usr/src/packages/autoconf/26/autoconf2.5-2.63-1/src/autoconf-2.63/lib/autoconf/specific.m4:459:
AC_MINIX is expanded from...
configure.in:60: the top level
configure.in:60: warning: AC_RUN_IFELSE was called before
AC_USE_SYSTEM_EXTENSIONS
configure.in:59: warning: AC_COMPILE_IFELSE was called before
AC_USE_SYSTEM_EXTENSIONS
/usr/src/packages/autoconf/26/autoconf2.5-2.63-1/src/autoconf-2.63/lib/autoconf/specific.m4:386:
AC_USE_SYSTEM_EXTENSIONS is expanded from...
/usr/src/packages/autoconf/26/autoconf2.5-2.63-1/src/autoconf-2.63/lib/autoconf/specific.m4:454:
AC_AIX is expanded from...
configure.in:59: the top level
configure.in:59: warning: AC_RUN_IFELSE was called before
AC_USE_SYSTEM_EXTENSIONS
configure.in:60: warning: AC_COMPILE_IFELSE was called before
AC_USE_SYSTEM_EXTENSIONS
/usr/src/packages/autoconf/26/autoconf2.5-2.63-1/src/autoconf-2.63/lib/autoconf/specific.m4:459:
AC_MINIX is expanded from...
configure.in:60: the top level
configure.in:60: warning: AC_RUN_IFELSE was called before
AC_USE_SYSTEM_EXTENSIONS
/cygdrive/d/Development/octave-devsrc/scripts
skipping autoheader in ./scripts
done

[Jaroslav Hajek-2]

On Sun, Dec 14, 2008 at 8:02 AM, Marco Atzeri <marco_atzeri@...> wrote:

> --- Jaroslav Hajek  ha scritto:
>
>>
>> Thanks for this test. This is really weird, because
>> I think that the
>> test program is exactly the delicate overload
>> problem that occurs in
>> oct-inttypes.h. However, you Makeconf seems to be OK
>> (contains
>> CXX=g++-4).
>>
>> Meanwhile, I think I resolved the conformance
>> question - for technical
>> details, see the discussion on comp.lang.c++:
>>
> <http://groups.google.com/group/comp.lang.c++/browse_frm/thread/398e6ba0047f902a/bcb993f190dbbf65#bcb993f190dbbf65>.
>> Unless anyone proves my reasoning wrong, the result
>> is that the code
>> is indeed standard-conforming.
>> Can you again give the error output from make, this
>> time with gcc 4?
>> I'm very surprised that it didn't even change -
>> that's suspicious. Can
>> other people try building on Cygwin? If the problem
>> persists, I think
>> it's a bug in the cygwin gcc port.
>>
>
> built on cygwin with
> configure --libexecdir=/usr/lib --enable-shared
> CFLAGS="-Dtimezone=_timezone" CC=gcc-4  F77=gfortran-4
> CXX=g++-4 CPP=cpp-4
>
>
> make[2]: Entering directory
> `/pub/hg/octave-build/liboctave'
> g++-4 -c -I/usr/include/freetype2 -I.
> -I../../octave/liboctave -I.. -I../liboctave -I../src
> -I../libcr
> uft/misc -I../../octave -I../../octave/liboctave
> -I../../octave/src -I../../octave/libcruft/misc  -DHA
> VE_CONFIG_H -mieee-fp -Wall -W -Wshadow
> -Wold-style-cast -g -O2 -I/usr/include/freetype2
> ../../octave/
> liboctave/oct-inttypes.cc -o oct-inttypes.o
> Putting child 0x01ca70a0 (oct-inttypes.o) PID 412 on
> the chain.
> Live child 0x01ca70a0 (oct-inttypes.o) PID 412
> ../../octave/liboctave/oct-inttypes.cc:511: error:
> ambiguous template specialization 'mop<octave_int_c
> mp_op::lt>' for 'bool octave_int_cmp_op::mop(double,
> int64_t)'
> ../../octave/liboctave/oct-inttypes.cc:511: error:
> ambiguous template specialization 'mop<octave_int_c
> mp_op::lt>' for 'bool octave_int_cmp_op::mop(double,
> uint64_t)'
> ../../octave/liboctave/oct-inttypes.cc:511: error:
> ambiguous template specialization 'mop<octave_int_c
> mp_op::lt>' for 'bool octave_int_cmp_op::mop(int64_t,
> double)'
> ../../octave/liboctave/oct-inttypes.cc:511: error:
> ambiguous template specialization 'mop<octave_int_c
> mp_op::lt>' for 'bool octave_int_cmp_op::mop(uint64_t,
> double)'
>
>> In that case, I'd say file a bug for cygwin, and I
>> will provide you a
>> special cygwin patch, because in principle, I don't
>> think it's good to
>> change std-conforming code due to compiler bugs
>> (unless they occur on
>> majority of platforms).
>>
>
> gcc-4 is still on test in cygwin, so a specific
> problem is possible.
>

I suppose so. In any case, obviously gcc should work equally on all
platforms and the code compiles on GNU/Linux, so either the Cygwin or
the GNU/Linux versions are buggy.

I don't use cygwin myself, but if anyone wants to file a bug, I can
assist with description of the problem (and the not-quite-trivial
reasoning why gcc is wrong).

cheers

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