Thanks for getting back to me... On Thu, 2003-12-18 at 01:18, Jason E. Stewart wrote: > "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.
Once you get to know the gentoo portage system you would LOVE it. Its a cross between debian's apt, and BSD ports. I now understand why the BSD folks are so fanatical... All dependencies managed for you (automagically). It is sweet. I will NEVER use an RPM based system again. > > 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. EVERYTHING, on a gentoo system is normally built from sources so that should not usually be a problem. I was just eliminating variables. > > > 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 It failed (but I show not the output) see below... > 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 > [EMAIL PROTECTED] [~/perl.add.modules/XML-Xerces-2.3.0-4] nm blib/arch/auto/Handler/Handler.a |grep ZTI19PerlCallbackHandler [EMAIL PROTECTED] [~/perl.add.modules/XML-Xerces-2.3.0-4] Well I guess this explained the error.... but (see below) I have know idea why this build did not have it. > 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. Output of gcc --version: gcc (GCC) 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3, propolice) > > 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. Great, that was a bit of a pain. (I'd like to create a gentoo ebuild for this so that its easier for the next guy, if we can figure this out) > > > Various other tries using various build parameters have all yeilded > > the same basic results (but with difference symbols being > > undefined). > > Which ones? Some of them were string libraries: MANGLEDNAME_stricmp() for instance. > > I'd also like to see the output of make for XML-Xerces, perhaps it is > informative. I just rebuilt it so you can see it: [EMAIL PROTECTED] [~/perl.add.modules/XML-Xerces-2.3.0-4] echo $XERCESCROOT /var/tmp/portage/xerces-c-2.3.0-r6/work/xerces-c-src_2_3_0 [EMAIL PROTECTED] [~/perl.add.modules/XML-Xerces-2.3.0-4] echo $LD_LIBRARY_PATH /var/tmp/portage/xerces-c-2.3.0-r6/work/xerces-c-src_2_3_0/lib [EMAIL PROTECTED] [~/perl.add.modules/XML-Xerces-2.3.0-4] ls $LD_LIBRARY_PATH libxerces-c.so libxerces-c.so.23 libxerces-c.so.23.0 [EMAIL PROTECTED] [~/perl.add.modules/XML-Xerces-2.3.0-4] make clean [output deleted] [EMAIL PROTECTED] [~/perl.add.modules/XML-Xerces-2.3.0-4] perl Makefile.PL Using XERCES_LIB = /var/tmp/portage/xerces-c-2.3.0-r6/work/xerces-c-src_2_3_0/lib Using XERCES_INCLUDE = /var/tmp/portage/xerces-c-2.3.0-r6/work/xerces-c-src_2_3_0/include using config file: /var/tmp/portage/xerces-c-2.3.0-r6/work/xerces-c-src_2_3_0/src/xercesc/config.status Found CXX = g++ Found CXXFLAGS = -w -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -DAPP_NO_THREADS -DXML_USE_NO_THREADS -DXML_USE_NETACCESSOR_SOCKET Found LDFLAGS = Using Xerces-C version info from /var/tmp/portage/xerces-c-2.3.0-r6/work/xerces-c-src_2_3_0/include/xercesc/util/XercesVersion.hpp Checking to see if libxerces is in your library path...Success!! Using Xerces-C version: 2.3.0 Checking if your kit is complete... Looks good Processing hints file hints/linux.pl Writing Makefile for Handler Writing Makefile for XML::Xerces [EMAIL PROTECTED] [~/perl.add.modules/XML-Xerces-2.3.0-4] make cp Xerces.pm blib/lib/XML/Xerces.pm make -C Handler static make[1]: Entering directory `/home/lab/perl.add.modules/XML-Xerces-2.3.0-4/Handler' g++ -c -I. -IHandler -I/var/tmp/portage/xerces-c-2.3.0-r6/work/xerces-c-src_2_3_0/include -w -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -DAPP_NO_THREADS -DXML_USE_NO_THREADS -DXML_USE_NETACCESSOR_SOCKET -D_REENTRANT -O -DVERSION=\"\" -DXS_VERSION=\"\" -fpic "-I/usr/lib/perl5/5.8.0/i686-linux/CORE" PerlCallbackHandler.cpp g++ -c -I. -IHandler -I/var/tmp/portage/xerces-c-2.3.0-r6/work/xerces-c-src_2_3_0/include -w -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -DAPP_NO_THREADS -DXML_USE_NO_THREADS -DXML_USE_NETACCESSOR_SOCKET -D_REENTRANT -O -DVERSION=\"\" -DXS_VERSION=\"\" -fpic "-I/usr/lib/perl5/5.8.0/i686-linux/CORE" PerlContentCallbackHandler.cpp g++ -c -I. -IHandler -I/var/tmp/portage/xerces-c-2.3.0-r6/work/xerces-c-src_2_3_0/include -w -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -DAPP_NO_THREADS -DXML_USE_NO_THREADS -DXML_USE_NETACCESSOR_SOCKET -D_REENTRANT -O -DVERSION=\"\" -DXS_VERSION=\"\" -fpic "-I/usr/lib/perl5/5.8.0/i686-linux/CORE" PerlDocumentCallbackHandler.cpp g++ -c -I. -IHandler -I/var/tmp/portage/xerces-c-2.3.0-r6/work/xerces-c-src_2_3_0/include -w -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -DAPP_NO_THREADS -DXML_USE_NO_THREADS -DXML_USE_NETACCESSOR_SOCKET -D_REENTRANT -O -DVERSION=\"\" -DXS_VERSION=\"\" -fpic "-I/usr/lib/perl5/5.8.0/i686-linux/CORE" PerlErrorCallbackHandler.cpp rm -rf ../blib/arch/auto/Handler/Handler.a /usr/bin/ar cr ../blib/arch/auto/Handler/Handler.a PerlCallbackHandler.o PerlContentCallbackHandler.o PerlDocumentCallbackHandler.o PerlErrorCallbackHandler.o && : ../blib/arch/auto/Handler/Handler.a chmod 755 ../blib/arch/auto/Handler/Handler.a make[1]: Leaving directory `/home/lab/perl.add.modules/XML-Xerces-2.3.0-4/Handler' /home/lab/perl.add.modules/XML-Xerces-2.3.0-4/Handler make[1]: Entering directory `/home/lab/perl.add.modules/XML-Xerces-2.3.0-4/Handler' make[1]: Leaving directory `/home/lab/perl.add.modules/XML-Xerces-2.3.0-4/Handler' g++ -c -I. -IHandler -I/var/tmp/portage/xerces-c-2.3.0-r6/work/xerces-c-src_2_3_0/include -w -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -DAPP_NO_THREADS -DXML_USE_NO_THREADS -DXML_USE_NETACCESSOR_SOCKET -D_REENTRANT -DDEBIAN -D_GNU_SOURCE -O -DVERSION=\"2.3.0-4\" -DXS_VERSION=\"2.3.0-4\" -fpic "-I/usr/lib/perl5/5.8.0/i686-linux/CORE" Xerces.cpp Running Mkbootstrap for XML::Xerces () chmod 644 Xerces.bs rm -f blib/arch/auto/XML/Xerces/Xerces.so LD_RUN_PATH="/var/tmp/portage/xerces-c-2.3.0-r6/work/xerces-c-src_2_3_0/lib" gcc -shared -L/usr/local/lib Xerces.o -o blib/arch/auto/XML/Xerces/Xerces.so blib/arch/auto/Handler/Handler.a -lpthread -L/var/tmp/portage/xerces-c-2.3.0-r6/work/xerces-c-src_2_3_0/lib -lxerces-c chmod 755 blib/arch/auto/XML/Xerces/Xerces.so cp Xerces.bs blib/arch/auto/XML/Xerces/Xerces.bs chmod 644 blib/arch/auto/XML/Xerces/Xerces.bs [EMAIL PROTECTED] [~/perl.add.modules/XML-Xerces-2.3.0-4] perl -w -Mblib t/actualCast.t 1..11 ok 1 - module loaded ok 2 - The object isa XML::Xerces::DOMNode ok 3 - The object isa XML::Xerces::DOMElement ok 4 - The object isa XML::Xerces::Grammar ok 5 - The object isa XML::Xerces::DTDGrammar ok 6 - The object isa XML::Xerces::Grammar ok 7 - The object isa XML::Xerces::SchemaGrammar ok 8 # skip return of CallbackHandler's not implemented ok 9 # skip return of CallbackHandler's not implemented # Looks like you planned 11 tests but only ran 9. [EMAIL PROTECTED] [~/perl.add.modules/XML-Xerces-2.3.0-4] SOB! it works ( I think ). In fact they all mostly ran... certainly no ld undefined symbol errors. Even make test works with the following summary Failed Test Stat Wstat Total Fail Failed List of Failed ------------------------------------------------------------------------------- t/DOMDocument.t 62 15872 35125 62 0.18% 662-723 t/actualCast.t 2 512 11 4 36.36% 10-11 18 subtests skipped. Failed 2/39 test scripts, 94.87% okay. 64/35408 subtests failed, 99.82% okay. I wonder if it worked this time because I defined LD_LIBRARY_PATH BEFORE I started the build? Is this test failure rate acceptable, or do we need to look deeper? Thanks so much for getting back to me, I look forward to any perls of wisdom you shed... Lincoln --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
