From bug-octave-request at bevo dot che dot wisc dot edu  Tue Dec 15 16:11:03 1998
Subject: Re: Compile error -- undefined symbol set_new_handler
From: Brian Tyrrell <tyrrell at ll dot mit dot edu>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
Cc: bug-octave at bevo dot che dot wisc dot edu
Date: Tue, 15 Dec 1998 17:13:18 -0500

At 04:04 PM 12/15/98 -0600, you wrote:
>On 15-Dec-1998, Brian Tyrrell <tyrrell at ll dot mit dot edu> wrote:
>
>| I found the following thread concerning changes to set_new_handler on the
>| egcs mailing list archive:
>| 
>| http://www.cygnus.com/ml/egcs/1998-Aug/0811.html
>| 
>| ---------------------------------------------------
>| It appears that previously set_new_handler needed to be inside an
>| extern "C" { ... } block.  At least the sgml-tools SRPM thinks that
>| is the case.
>
>  ...
>
>| ------------------------------------------
>| Yes.  set_new_handler is supposed to have C++ linkage.
>
>  ...
>
>| Write an autoconf test :-0
>| 
>| It should be relatively easy to try and build a trivial test program
>| which does not enclose it in an extern "C" block, then compile it.
>| 
>| If it fails due to an undefined reference to set_new_handler, then it
>| needs to be enclosed in an extern "C" block.
>| 
>| jeff
>| ---------------------------------------
>| 
>| Nah, people shouldn't be declaring it themselves; they should just
>| #include .
>| 
>| Jason
>
>(Unfortunately, the browser from which you pasted this text interprets
>the `< ... >' that follows the #include as something special, and
>doesn't show us what it is.  I'll assume that it is <new>, which would
>make sense.  In the current sources, Octave's sighandlers.cc file
>already includes <new>.  Are you getting an incorrect version of that
>file for some reason?
>
>jwe
> 

I looked at the source for the page and it does say <new>

I also looked at sighandlers.cc and it does #include <new>