Failure building CVS on IRIX 6.5 with GCC

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Failure building CVS on IRIX 6.5 with GCC

Albert Chin-69
While building CVS on IRIX 6.5.19 with GCC 3.2.2. Any ideas?

g++ -c -I/opt/TWWfsw/readline42a/include -L/opt/TWWfsw/ncurses5/include -I/opt/TWWfsw/libfftw21/include -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -I../glob -I../glob -DHAVE_CONFIG_H  -O2 syscalls.cc -o syscalls.o
syscalls.cc: In function `Octave_map mk_stat_map(const file_stat&)':
syscalls.cc:69: conversion from `ino_t' to `const octave_value' is ambiguous
ov.h:195: candidates are: octave_value::octave_value(octave_value*, int = 1)
   <near match>
ov.h:190:                 octave_value::octave_value(octave_function*) <near
   match>
ov.h:182:                 octave_value::octave_value(const char*) <near match>
ov.h:181:                 octave_value::octave_value(char)
ov.h:179:                 octave_value::octave_value(bool)
ov.h:168:                 octave_value::octave_value(double)
ov.h:166:                 octave_value::octave_value(long unsigned int)
ov.h:165:                 octave_value::octave_value(long int)
ov.h:164:                 octave_value::octave_value(unsigned int)
ov.h:163:                 octave_value::octave_value(int)
ov.h:162:                 octave_value::octave_value(short unsigned int)
ov.h:161:                 octave_value::octave_value(short int)
syscalls.cc:77: conversion from `off_t' to `const octave_value' is ambiguous
ov.h:195: candidates are: octave_value::octave_value(octave_value*, int = 1)
   <near match>
ov.h:190:                 octave_value::octave_value(octave_function*) <near
   match>
ov.h:182:                 octave_value::octave_value(const char*) <near match>
ov.h:181:                 octave_value::octave_value(char)
ov.h:179:                 octave_value::octave_value(bool)
ov.h:168:                 octave_value::octave_value(double)
ov.h:166:                 octave_value::octave_value(long unsigned int)
ov.h:165:                 octave_value::octave_value(long int)
ov.h:164:                 octave_value::octave_value(unsigned int)
ov.h:163:                 octave_value::octave_value(int)
ov.h:162:                 octave_value::octave_value(short unsigned int)
ov.h:161:                 octave_value::octave_value(short int)
gmake[2]: *** [syscalls.o] Error 1
gmake[2]: Leaving directory `/opt/build/octave-2.1.44/src'

--
albert chin ([hidden email])


Reply | Threaded
Open this post in threaded view
|

Failure building CVS on IRIX 6.5 with GCC

John W. Eaton-6
On 19-Feb-2003, Albert Chin <[hidden email]> wrote:

| While building CVS on IRIX 6.5.19 with GCC 3.2.2. Any ideas?

| g++ -c -I/opt/TWWfsw/readline42a/include -L/opt/TWWfsw/ncurses5/include -I/opt/TWWfsw/libfftw21/include -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -I../glob -I../glob -DHAVE_CONFIG_H  -O2 syscalls.cc -o syscalls.o
| syscalls.cc: In function `Octave_map mk_stat_map(const file_stat&)':
| syscalls.cc:69: conversion from `ino_t' to `const octave_value' is ambiguous

What is the actual type of ino_t on your system?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Failure building CVS on IRIX 6.5 with GCC

Albert Chin-69
On Wed, Feb 19, 2003 at 03:42:56PM -0600, John W. Eaton wrote:
> On 19-Feb-2003, Albert Chin <[hidden email]> wrote:
>
> | While building CVS on IRIX 6.5.19 with GCC 3.2.2. Any ideas?
>
> | g++ -c -I/opt/TWWfsw/readline42a/include -L/opt/TWWfsw/ncurses5/include -I/opt/TWWfsw/libfftw21/include -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -I../glob -I../glob -DHAVE_CONFIG_H  -O2 syscalls.cc -o syscalls.o
> | syscalls.cc: In function `Octave_map mk_stat_map(const file_stat&)':
> | syscalls.cc:69: conversion from `ino_t' to `const octave_value' is ambiguous
>
> What is the actual type of ino_t on your system?

typedef unsigned __uint32_t;
typedef __uint32_t o_ino_t;

--
albert chin ([hidden email])


Reply | Threaded
Open this post in threaded view
|

Re: Failure building CVS on IRIX 6.5 with GCC

John W. Eaton-6
On 19-Feb-2003, Albert Chin <[hidden email]> wrote:

| On Wed, Feb 19, 2003 at 03:42:56PM -0600, John W. Eaton wrote:
| > On 19-Feb-2003, Albert Chin <[hidden email]> wrote:
| >
| > | While building CVS on IRIX 6.5.19 with GCC 3.2.2. Any ideas?
| >
| > | g++ -c -I/opt/TWWfsw/readline42a/include -L/opt/TWWfsw/ncurses5/include -I/opt/TWWfsw/libfftw21/include -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -I../glob -I../glob -DHAVE_CONFIG_H  -O2 syscalls.cc -o syscalls.o
| > | syscalls.cc: In function `Octave_map mk_stat_map(const file_stat&)':
| > | syscalls.cc:69: conversion from `ino_t' to `const octave_value' is ambiguous
| >
| > What is the actual type of ino_t on your system?
|
| typedef unsigned __uint32_t;
| typedef __uint32_t o_ino_t;

I'm not sure why the octave_value (unsigned int) constructor fails to
be the best match.  If the above typedefs are correct, then it seems
you should be able to work around the problem with a cast (but I don't
think that's the best solution, so I'd rather not install a change
like that).

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Failure building CVS on IRIX 6.5 with GCC

Paul Kienzle
In reply to this post by Albert Chin-69
Albert Chin wrote:

>On Wed, Feb 19, 2003 at 03:42:56PM -0600, John W. Eaton wrote:
>  
>
>>On 19-Feb-2003, Albert Chin <[hidden email]> wrote:
>>
>>| While building CVS on IRIX 6.5.19 with GCC 3.2.2. Any ideas?
>>
>>| g++ -c -I/opt/TWWfsw/readline42a/include -L/opt/TWWfsw/ncurses5/include -I/opt/TWWfsw/libfftw21/include -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -I../glob -I../glob -DHAVE_CONFIG_H  -O2 syscalls.cc -o syscalls.o
>>| syscalls.cc: In function `Octave_map mk_stat_map(const file_stat&)':
>>| syscalls.cc:69: conversion from `ino_t' to `const octave_value' is ambiguous
>>
Octave is looking for ino_t

>>
>>What is the actual type of ino_t on your system?
>>    
>>
>
>typedef unsigned __uint32_t;
>typedef __uint32_t o_ino_t;
>
You have reported o_ino_t

If you look a few lines down in the header, you will
see that ino_t is 64 bit.  I put a static_cast<double>
around it for my IRIX build.  Is there a system independent
way of representing 64 bit values?

Paul Kienzle
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Failure building CVS on IRIX 6.5 with GCC

Albert Chin-69
On Wed, Feb 19, 2003 at 06:47:33PM -0500, Paul Kienzle wrote:

> Albert Chin wrote:
>
> >On Wed, Feb 19, 2003 at 03:42:56PM -0600, John W. Eaton wrote:
> >
> >
> >>On 19-Feb-2003, Albert Chin <[hidden email]> wrote:
> >>
> >>| While building CVS on IRIX 6.5.19 with GCC 3.2.2. Any ideas?
> >>
> >>| g++ -c -I/opt/TWWfsw/readline42a/include -L/opt/TWWfsw/ncurses5/include
> >>-I/opt/TWWfsw/libfftw21/include -I. -I.. -I../liboctave -I../src
> >>-I../libcruft/misc  -I../glob -I../glob -DHAVE_CONFIG_H  -O2 syscalls.cc
> >>-o syscalls.o
> >>| syscalls.cc: In function `Octave_map mk_stat_map(const file_stat&)':
> >>| syscalls.cc:69: conversion from `ino_t' to `const octave_value' is
> >>ambiguous
> >>
> Octave is looking for ino_t
>
> >>
> >>What is the actual type of ino_t on your system?
> >>  
> >>
> >
> >typedef unsigned __uint32_t;
> >typedef __uint32_t o_ino_t;
> >
> You have reported o_ino_t
>
> If you look a few lines down in the header, you will
> see that ino_t is 64 bit.  I put a static_cast<double>
> around it for my IRIX build.  Is there a system independent
> way of representing 64 bit values?

You're right:
  typedef unsigned long long __uint64_t;
  typedef __uint64_t ino_t;

--
albert chin ([hidden email])


Reply | Threaded
Open this post in threaded view
|

Re: Failure building CVS on IRIX 6.5 with GCC

Paul Kienzle
In reply to this post by Albert Chin-69
Albert Chin wrote:

>On Wed, Feb 19, 2003 at 03:42:56PM -0600, John W. Eaton wrote:
>  
>
>>On 19-Feb-2003, Albert Chin <[hidden email]> wrote:
>>
>>| While building CVS on IRIX 6.5.19 with GCC 3.2.2. Any ideas?
>>
>>| g++ -c -I/opt/TWWfsw/readline42a/include -L/opt/TWWfsw/ncurses5/include -I/opt/TWWfsw/libfftw21/include -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -I../glob -I../glob -DHAVE_CONFIG_H  -O2 syscalls.cc -o syscalls.o
>>| syscalls.cc: In function `Octave_map mk_stat_map(const file_stat&)':
>>| syscalls.cc:69: conversion from `ino_t' to `const octave_value' is ambiguous
>>
>>What is the actual type of ino_t on your system?
>>    
>>
>
>typedef unsigned __uint32_t;
>typedef __uint32_t o_ino_t;
>
FWIW, building octave 2.1.45 with Mips PRO C++ 7.30
gives the following result:

octave:1> sprintf("%d is %d ", 1, 2)
error: memory exhausted -- trying to return to prompt

I think I would have noticed this in January when I was
playing with 2.1.40.  Anything changed since then which
might affect sprintf?

BTW, I've compiled most of octave-forge with CC
as well, but it took some doing.  Aside from the sprintf
problem, all the oct-file tests succeeded.  Symbolic,
QHull and JPG were not included.

Paul Kienzle
[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Failure building CVS on IRIX 6.5 with GCC

John W. Eaton-6
On 20-Feb-2003, Paul Kienzle <[hidden email]> wrote:

| FWIW, building octave 2.1.45 with Mips PRO C++ 7.30
| gives the following result:
|
| octave:1> sprintf("%d is %d ", 1, 2)
| error: memory exhausted -- trying to return to prompt
|
| I think I would have noticed this in January when I was
| playing with 2.1.40.  Anything changed since then which
| might affect sprintf?

The place to look is the octave_vsprintf stuff in src/utils.cc.  It's
kind of ugly.  There are several different ways the nonstandard
vsnprintf functions behave and I haven't tried to account for all of
them.  The last time I tried to clean this up, my head started
spinning and I had to stop and do something else for a while (it's now
been a long while, and I still don't want to look at it).

jwe