Re: Undefined symbol errors in make test

"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.