* set_new_handler change
@ 1998-08-23 23:15 Jeffrey A Law
1998-08-24 0:56 ` Jason Merrill
0 siblings, 1 reply; 6+ messages in thread
From: Jeffrey A Law @ 1998-08-23 23:15 UTC (permalink / raw)
To: jason; +Cc: egcs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: set_new_handler change
1998-08-23 23:15 set_new_handler change Jeffrey A Law
@ 1998-08-24 0:56 ` Jason Merrill
1998-08-25 14:32 ` Gary Thomas
0 siblings, 1 reply; 6+ messages in thread
From: Jason Merrill @ 1998-08-24 0:56 UTC (permalink / raw)
To: law; +Cc: egcs
>>>>> Jeffrey A Law <law@cygnus.com> writes:
> 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?
Yes. set_new_handler is supposed to have C++ linkage.
Jason
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: set_new_handler change
1998-08-25 14:32 ` Gary Thomas
@ 1998-08-24 10:48 ` Jeffrey A Law
1998-08-24 10:48 ` Jason Merrill
1998-08-26 9:55 ` Joe Buck
1 sibling, 1 reply; 6+ messages in thread
From: Jeffrey A Law @ 1998-08-24 10:48 UTC (permalink / raw)
To: Gary Thomas; +Cc: Jason Merrill, egcs
In message < XFMail.980824185820.gdt@linuxppc.org >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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: set_new_handler change
1998-08-24 10:48 ` Jeffrey A Law
@ 1998-08-24 10:48 ` Jason Merrill
0 siblings, 0 replies; 6+ messages in thread
From: Jason Merrill @ 1998-08-24 10:48 UTC (permalink / raw)
To: law; +Cc: Gary Thomas, egcs
>>>>> Jeffrey A Law <law@cygnus.com> writes:
> In message < XFMail.980824185820.gdt@linuxppc.org >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
Nah, people shouldn't be declaring it themselves; they should just
#include <new>.
Jason
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: set_new_handler change
1998-08-24 0:56 ` Jason Merrill
@ 1998-08-25 14:32 ` Gary Thomas
1998-08-24 10:48 ` Jeffrey A Law
1998-08-26 9:55 ` Joe Buck
0 siblings, 2 replies; 6+ messages in thread
From: Gary Thomas @ 1998-08-25 14:32 UTC (permalink / raw)
To: Jason Merrill; +Cc: egcs, law
On 24-Aug-98 Jason Merrill wrote:
>>>>>> Jeffrey A Law <law@cygnus.com> writes:
>
> > 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?
>
> 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@linuxppc.org | "Fine wine is a necessity of
... opinions expressed here are mine | life for me"
and no one else would claim them! |
| Thomas Jefferson
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: set_new_handler change
1998-08-25 14:32 ` Gary Thomas
1998-08-24 10:48 ` Jeffrey A Law
@ 1998-08-26 9:55 ` Joe Buck
1 sibling, 0 replies; 6+ messages in thread
From: Joe Buck @ 1998-08-26 9:55 UTC (permalink / raw)
To: Gary Thomas; +Cc: jason, egcs, law
> > > Did we intentionally change this behavior?
> >
> > 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.
There are two possible interpretations of this:
1) I have Netscape source (OK, Mozilla). Here, doing
#include <new>
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1998-08-26 9:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-08-23 23:15 set_new_handler change Jeffrey A Law
1998-08-24 0:56 ` Jason Merrill
1998-08-25 14:32 ` Gary Thomas
1998-08-24 10:48 ` Jeffrey A Law
1998-08-24 10:48 ` Jason Merrill
1998-08-26 9:55 ` Joe Buck
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).