From octave-maintainers-request at bevo dot che dot wisc dot edu Thu Feb 20 21:47:41 2003
Subject: Re: Failure building CVS on IRIX 6.5 with GCC
From: Paul Kienzle <pkienzle at users dot sourceforge dot net>
To: octave-maintainers at bevo dot che dot wisc dot edu
Date: Thu, 20 Feb 2003 22:48:01 -0500

Albert Chin wrote:

>On Wed, Feb 19, 2003 at 03:42:56PM -0600, John W. Eaton wrote:
>  
>
>>On 19-Feb-2003, Albert Chin <octave-maintainers at thewrittenword dot com> 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
pkienzle at users dot sf dot net