Emmanuel Dreyfus wrote:
> 
> > 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.
> >
> > 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
> 
> 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
> 
> 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...

Well the problem is that we can't link libgcc into a DSO as its not
available compiled -fPIC and even this causes versioning problems.

The workaround I've used is as I've described - adding -export-dynamic
to the loading binary. You've hit problem because your mixing c++ and c.
I don't know the solution to this...

Nick

-- 
aka skrll@netbsd.org, skrll@excite.co.uk