Subject: Xerces-P link problems
To: None <email@example.com, firstname.lastname@example.org>
From: Emmanuel Dreyfus <email@example.com>
Date: 04/01/2001 22:46:10
I'm still working on xerces-p, and I wonder if the problem I encounter
are caused by the way Xerces-C is linked or the way Perl is linked.
At run time, perl complain because __eh_alloc is an undefined symbol.
__eh_malloc is normally statically linked in a binary, through libgcc.a
The perl executable does not contain the __eh_alloc symbol, an libxerces
does require it. I think this is why we end up with a problem.
It is not possible to link the Perl xerces module with -lgcc, because
libgcc.a is not built as PIC. linking with -lgcc will cause link errors.
I tried picking up the __eh_alloc definition from gcc/cp/exception.cc:
extern "C" void * malloc (size_t);
extern "C" void *
__eh_alloc (size_t size)
void *p = malloc (size);
if (p == 0)
I compiled this with -nostdlib -fPIC and linked it in xerces-p. It then
complain about the terminate symbol missing. With the same trick, I
added the missing symbol, then I needed __terminate, __builtin_new,
__terminate, __builtin_delete, __builtin_vec_delete, _builtin_vec_new...
All theses are okay, the definition are quite simple (most of them are
Then it started asking for __sjthrow. This can be found in
gcc/libgcc2.c, and it's getting much more difficult: I have to include
more and more snipets from /usr/src/gnu. Hence I think this is not the
good solution, and maybe we need to rework the perl package or the
I think the problem is in perl, but I'm not sure. The big question is
why perl does not contain all these symbols? Is perl linked with
libgcc.a? If not, why isn't it? Could we link it with libgcc.a?
Or maybe these symbols references should not be in xerces-c? What are
they used for?
Il ne suffit pas de crier l'iMac, l'iMac! en sautant comme un cabri...