C++ Exception handling with shared libs in current is broken again
Hi all,
I do know now why I have again problems with building openoffice.
It seems that exceptions over shared libraries are broken again in
CURRENT.
Alexander, do you have a idea why this got broken again ?
Attached is your test programm ...
Martin
STABLE:
[EMAIL PROTECTED]:~/cxxtest$ export LD_LIBRARY_PATH=.
[EMAIL PROTECTED]:~/cxxtest$ ./arf
calling foo
in baz
foo caught Bax thowing...
returned from foo
CURRENT:
[EMAIL PROTECTED]:~/cxxtest$ export LD_LIBRARY_PATH=.
[EMAIL PROTECTED]:~/cxxtest$ ./arf
abort trap
... The exception is not catched at all ...
Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED]
--
ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering sh file. Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# Makefile
# foo.cc
# main.cc
#
echo x - Makefile
sed 's/^X//' Makefile 'END-of-Makefile'
XCXX=g++
XLD=ld
XCXXFLAGS=-g -fpic -fexceptions
X
Xall: arf
X
Xarf: main.o foo.so
X ${CXX} -o arf main.o foo.so
X
X
Xfoo.so: foo.o
X ${LD} -Bshareable -o foo.so foo.o
X
Xclean:
X rm -f arf *.o *.so
END-of-Makefile
echo x - foo.cc
sed 's/^X//' foo.cc 'END-of-foo.cc'
X#include stdio.h
X
Xint Foo ();
X
Xint Baz ()
X{
Xchar *msg = Bax thowing...;
Xprintf (in baz\n);
Xthrow msg;
Xprintf (baz should not be here.\n);
X}
X
X
Xint Foo ()
X{
Xtry {
XBaz ();
X} catch (char *msg) {
Xprintf (foo caught %s\n, msg);
X}
X}
END-of-foo.cc
echo x - main.cc
sed 's/^X//' main.cc 'END-of-main.cc'
X#include stdio.h
X
Xint Foo ();
X
Xint
Xmain ()
X{
Xtry {
Xprintf (calling foo\n);
XFoo ();
Xprintf (returned from foo\n);
X} catch (char *msg) {
Xprintf (exception from foo: %s\n, msg);
X} catch (...) {
Xprintf (unknown exception\n);
X}
X}
END-of-main.cc
exit
Re: C++ Exception handling with shared libs in current is broken again
I do know now why I have again problems with building openoffice.
It seems that exceptions over shared libraries are broken again in
CURRENT.
Alexander, do you have a idea why this got broken again ?
rtld from 19.October has the same problem. I guess it must be gcc3.2
which is the problem.
[This response addresses your other thread as well:
ld -Bsharable broken in CURRENT ?]
Hi Martin,
If you really want to directly use ld to build a shared C++ image,
then you will need to do additional study because a lot of things
changed between gcc 2 (used longjump-based EH) and gcc 3 (dwarf-region
based EH, requires more environment support). From gcc 3.2.2
documentation as installed on CURRENT (regarding the *only* supported
way to make a C++ shared library): However, if a library or main
executable is supposed to throw or catch exceptions, you must link it
using the G++ or GCJ driver, as appropriate for the languages used in
the program, or using the option @option{-shared-libgcc} [to the gcc
driver], such that it is linked with the shared @file{libgcc}.
Now, FreeBSD might have guaranteed other ways in the past, but from
the gcc side of things, this is the only supported way to make a C++
shared image with gcc3 on modern ELF platforms:
foo.so: foo.o
${CXX} -shared -o foo.so foo.o
Regards,
Loren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: C++ Exception handling with shared libs in current is broken again
Thank you even I have found that out myself too :) Using ld directly is a no-go for a gcc3.2 platform. Linking with the crt files fixes the problem. OK, cool. BTW, in case you care, the exact reason why you now need the startup file wrappers in the shared image with gcc3 style EH but not with gcc2 style EH: There are special ELF constructors/destructors hook symbols which are registered/found on a per-shared image basis by the Dwarf EH walking code... If those aren't present, then it doesn't work (the gcc mainline reports an error message before coring with your example code). Although it seems odd, all that support comes in the startup code. Did using ld directly ever work on CURRENT after the first upgrade to gcc 3? I suppose it might have worked the gcc 2.95 way in gcc 3.1 since we were slow to adopt support for some of the newer ELF features in the FSF copy of gcc. -Loren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
