On Saturday 17 August 2002 09:47 am, Thierry Vignaud wrote: > i'll answer anyway: we limit the numbers of package because of its > limited size, and the odds're hight that not so many people want > octave :-(
Hello Thierry and others: Octave -2.1.36 does not compile with gcc-3.2.0. I wrote the Octave list and John Eaton, the developer, has tried to diagnose the problems with it. There does not appear to be a quick fix for this problem. However Scilab runs quite well in Mandrake 9.0 beta 2. This may be an acceptable substitute. Below is the backtrace I sent him and his comments at the end: | Starting program: /home/calc/octave-2.1.36/src/octave | GNU Octave, version 2.1.36 (i686-pc-linux-gnu). | Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002 John W. Eaton. | This is free software; see the source code for copying conditions. | There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or | FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'. | | Report bugs to <[EMAIL PROTECTED]>. | | octave:1> 1 | ans = 1 | octave:2> 1+1 | | Program received signal SIGSEGV, Segmentation fault. | 0x4021788b in malloc () from /lib/i686/libc.so.6 | Current language: auto; currently c | (gdb) where | #0 0x4021788b in malloc () from /lib/i686/libc.so.6 | #1 0x4017f2b3 in operator delete(void*) () from /usr/lib/libstdc++.so.5 | #2 0x4017f30f in operator delete[](void*) () from | /usr/lib/libstdc++.so.5 | #3 0x40125b7d in std::strstreambuf::~strstreambuf() () from | /usr/lib/libstdc++.so.5 | #4 0x4012759c in std::ostrstream::~ostrstream() () from | /usr/lib/libstdc++.so.5 | #5 0x0819968c in fold (e=0xbfffef70) at pt-pr-code.h:50 | #6 0x0819a518 in make_binary_op (op=7081, op1=0x85a6000, | tok_val=0x85a6000, op2=0x85a6000) at parse.y:1965 | #7 0x081973a8 in yyparse() () at parse.y:727 | #8 0x081b6b94 in main_loop() () at toplev.cc:126 | #9 0x080d9d9a in main (argc=1, argv=0xbffff924) at octave.cc:581 | #10 0x401c2082 in __libc_start_main () from /lib/i686/libc.so.6 | (gdb) OK, I think this is due to significant change in the way gcc ostrstream works. Unless there's some option I don't know about, I don't think there will be any quick fix other than to use an earlier version of gcc. jwe
