From bug-octave-request at bevo dot che dot wisc dot edu  Tue Dec 15 15:46:57 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 16:49:37 -0500


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.

However, if I build the sgml-tools SRPM, I get an undefined reference
to set_new_handler.  Looking in libgcc.a in the egs-1.1 tree it appears
as if the name is c++ mangled -- which would imply that set_new_handler
should not be placed in extern "C" blocks.

Did we intentionally change this behavior?  Just want to make sure I
don't declare this a non-issue if the change was really an accident.

Note this is the last issue with the  x86 RedHat build.  Now to actually
install all the RPMs and see if I can bootstrap again :-)

jeff

------------------------------------------
Yes.  set_new_handler is supposed to have C++ linkage.

------------------------------------------
What should be done with existing apps that were built with the old
linkage?  A most useful example that comes to mind is NetScape.  This
is a case where getting the application built using the new linkage
may be difficult or impossible.

------------------------------------------------------------------------
Gary Thomas                              |
email: gdt at linuxppc dot org|                                    | "Fine wine is a necessity of
   ... opinions expressed here are mine  |        life for me"
       and no one else would claim them! |
                                         |      Thomas Jefferson
------------------------------------------------------------------------

------------------------------------------------------

 In message you write:
  > > Yes.  set_new_handler is supposed to have C++ linkage.
  > > 
  > 
  > What should be done with existing apps that were built with the old
  > linkage?  A most useful example that comes to mind is NetScape.  This
  > is a case where getting the application built using the new linkage
  > may be difficult or impossible.
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
----------------------------------------

There are two possible interpretations of this:

1) I have Netscape source (OK, Mozilla).  Here, doing

        #include 

in any files referencing set_new_handler fixes the problem (the proper
declaration of set_new_handler is provided).  If the code explicitly
declares set_new_handler extern "C", that's a bug, remove the bug.

2) I have a dynamically linked Netscape binary.  But set_new_handler is
in libgcc.a, which is always statically linked.  Your old binary will
keep working.

So what is the problem?
------------------------------------------------