Subject: Re: dlopening a c++ DSO with EH [was Re: Xerces-P link problems]
To: Nick Hudson <skrll@netbsd.org>
From: Emmanuel Dreyfus <p99dreyf@criens.u-psud.fr>
List: tech-toolchain
Date: 04/03/2001 20:58:16
> This will be because perl is a c binary and __eh_alloc is for exception
> handling in c++. Adding -fexceptions should help us on the way, but then
> the linker won't add in the necessary stuff from -lgcc because its not
> referenced.
>=20
> One solution would be to use -Wl,-whole-archive for libgcc.a - maybe.

This is the original link command:

gcc  -L/usr/pkg/lib -Wl,-E -Wl,-R/usr/pkg/lib -o perl perlmain.o
lib/auto/DynaLoader/DynaLoader.a  libperl.a `cat ext.libs` -lm -lcrypt=20

I had no success with this:

gcc  -L/usr/pkg/lib -Wl,-export-dynamic -Wl,-E -Wl,-R/usr/pkg/lib -o
perl perlmain.o lib/auto/DynaLoader/DynaLoader.a  libperl.a `cat
ext.libs` -lm -lcrypt -nostdlib -fexceptions -lc -Wl,--whole-archive
-Wl,-lgcc /usr/lib/crt0.o

But this works (I just replaced gcc by c++):

c++  -L/usr/pkg/lib -Wl,-E -Wl,-R/usr/pkg/lib -o perl perlmain.o
lib/auto/DynaLoader/DynaLoader.a  libperl.a `cat ext.libs` -lm -lcrypt=20

Is there any drawback to replace gcc by c++ in the whole perl build
process?

The previous command gave me __eh_alloc. I retried xerces-p and it now
bitches about __pure_virtual. I wonder if this problem is really about
the way perl is built...

--=20
Emmanuel Dreyfus.
"L'achitecture x86 est impossible =E0 aimer." (John Hennessy)
p99dreyf@criens.u-psud.fr