"Lincoln A. Baxter" <[EMAIL PROTECTED]> writes:
> I have been trying to build the perl XML::Xerces module for two days
> now.
Sorry, that sounds painful. I hope we can help you get it running. I
just discovered gentoo the other day, it looks like a valuable
distribution. I do all my development on debian as I find I can't live
without the debian package manager.
> I am running on a current gentoo linux system, and have need to get this
> working on a Solaris 8 system at work. If I cann't get this to work on
> a linux system (usually the easiest to get things to build on), I doubt
> I'll be about to succeed in solaris land.
Yes, linux is usually much simpler than Solaris.
> I have built the xerces c++ libraries from source (version 2.3.0 since
> that is what the CPAN module requires), following the instructions on
> the apache website. It builds and installs fine.
Ok, that should eliminate compiler version problems.
> I then go to build XML::Xerces, and everything builds fine.
> make test however fails to load Xerces.so with an undefined symbol
> error: .../XML-Xerces-2.3.0-4/blib/arch/auto/XML/Xerces/Xerces.so:
> undefined symbol: _ZTI19PerlCallbackHandler at
> /usr/lib/perl5/5.8.0/i686-linux/DynaLoader.pm line 229.
>
> It looks like we are running afoul of C++ name mangling, but I get the
> same result whether XML::Xerces is built with gcc or g++.
gcc will auto detect a C++ file and run g++, so that is not the
problem.
You are getting a dynamic loading error that is triggered by
Test::Harness - it uses a loader flag that causes an error if you have
any undefined symbols in your library. Sometimes this is the result of
a single misnamed symbol, and sometimes this is indicative of a bigger
problem like not locating the proper version of a library, or building
C++ libraries with different compilers or compiler versions.
Try just running a single test on the command line:
perl -w -Mblib t/actualCast.t
and see if it runs at all - if it does than it might be a minor
issue, if not something bigger is happening.
The symbol the loader is complaining about is from the callback
handler library, Handler.a, built in the Handler/ directory. Try
looking for the symbol:
$ nm blib/arch/auto/Handler/Handler.a |grep ZTI19PerlCallbackHandler
00000000 V _ZTI19PerlCallbackHandler
U _ZTI19PerlCallbackHandler
U _ZTI19PerlCallbackHandler
U _ZTI19PerlCallbackHandler
Is what I get. This is some code that is hand-written to handle
registration of callback methods - like ErrorHandler's,
ContentHandler's, EntityResolver's, etc. Xerces expects a C++ object
so we must do some fancy footwork to be able to register Perl object's
instead. Up until very recently this code was giving me a *big*
headache, but with a recent upgrade of gcc the issue resolved and
enabled me to make the code much simpler and cleaner. Perhaps this is
what is causing the problem - I'm using gcc-3.2.3.
> With this last build, I made sure I built the xerces library WITHOUT
> thread support (since my perl is built without thread support).
Hmmm... My Perl is also built without thread support, but I build
xerces-c *with* thread support (the default), but I don't think this
is the issue.
> Various other tries using various build parameters have all yeilded
> the same basic results (but with difference symbols being
> undefined).
Which ones?
I'd also like to see the output of make for XML-Xerces, perhaps it is
informative.
Cheers,
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
