From owner-bug-octave at bevo dot che dot wisc dot edu Wed Dec 11 11:46:22 1996 Subject: C++ compile error on Sun SPARC SunOS4.1.4 From: "John W. Eaton" To: "Andrew J. Deighan" Cc: bug-octave at bevo dot che dot wisc dot edu Date: Wed, 11 Dec 1996 11:45:35 -0600 On 11-Dec-1996, Andrew J. Deighan wrote: : Bug report for Octave 2.0 configured for sparc-sun-sunos4.1.4 : : The compilation fails in the src directory when trying to compile the : sighandlers.cc file. : : The output is: : : making all in src : cd src ; /home/gph/deighan/SOFTWARE/OTHERS/make-3.75/bin/make all : make[2]: Entering directory `/tmp_mnt/work/andy/OCTAVE/octave-2.0/src' : c++ -c -I. -I.. -I../liboctave -I../src -I../glob -I../libcruft/misc -DHAVE_CONFIG_H -fno-implicit-templates -g -O2 -Wall sighandlers.cc : sighandlers.cc: In function `void my_friendly_exit(const char *, int)': : sighandlers.cc:128: passing `void (*)()' as argument 2 of `octave_set_signal_handler(int, void (*)(int))' : sighandlers.cc: In function `void (* octave_set_signal_handler(int, void (*)(int)))(int)': : sighandlers.cc:168: warning: ANSI C++ prohibits conversion from `(int)' to `(...)' : sighandlers.cc: In function `void sigint_handler(int)': : sighandlers.cc:274: warning: unused parameter `int sig' : sighandlers.cc: In function `struct octave_interrupt_handler * octave_ignore_interrupts()': ... It is likely that this problem can be fixed by editing a copy of the signal.h include file in gcc's private include directory. The following information is from the INSTALL.OCTAVE file distributed with Octave (also part of the manual): * You may need to edit some files in the gcc include subdirectory to add prototypes for functions there. For example, Ultrix 4.2 needs proper declarations for the `signal()' and the `SIG_IGN' macro in the file `signal.h'. On some systems the `SIG_IGN' macro is defined to be something like this: #define SIG_IGN (void (*)())1 when it should really be something like: #define SIG_IGN (void (*)(int))1 to match the prototype declaration for `signal()'. The gcc fixincludes/fixproto script should probably fix this when gcc installs its modified set of header files, but I don't think that's been done yet. jwe