in reply to XML::LibXML::Common 0.13 on linux - undefined symbol

It says it finds lxml2 but then contradicts itself. Im sure that this will cause future problems...

I think so, too - in fact, it's probably the cause of the *present* problem.
When MakeMaker says Note (probably harmless): No library found for -lxml2 that means that MakeMaker is not going to pass that -lxml2 link along, so no attempt will be made to link to libxml2.a. Assuming that libxml2.a is the name of your xml2 import library, the absence of that link is the likely cause of the error you see.

I would replace the existing Makefile.PL with:
use ExtUtils::MakeMaker; WriteMakefile( 'NAME' => 'XML::LibXML::Common', 'VERSION_FROM' => 'Common.pm', # finds $VERSION 'AUTHOR' => 'Christian Glahn <christian.glahn@uibk.ac.at>', 'ABSTRACT' => 'Routines and Constants common for XML::LibXML +and XML::GDOME', 'LIBS' => '-lxml2', );
UPDATE: Added the LIBS parameter to the above proposed Makefile.PL.

And then, if the libxml2 library and headers are not in a location where they will be found by default, start with:
perl Makefile.PL INC="-I/path/to/xml_headers" LIBS="-L/path/to/xml_lib + -lxml2"
Otherwise just start with perl Makefile.PL as normal. (Again, I've assumed that 'libxml2.a' is the name of the library that needs to be found.)

That approach worked fine for me recently.

Cheers,
Rob

Replies are listed 'Best First'.
Re^2: XML::LibXML::Common 0.13 on linux - undefined symbol
by almut (Canon) on May 12, 2009 at 23:33 UTC
    I've assumed that 'libxml2.a' is the name of the library that needs to be found.

    Actually, when you specify -lxml2 on the compiler/linker command line, gcc will happily use either a static (.a) or a shared lib (.so).  In fact it even defaults to using the shared lib when both a .a and .so file are found.

    In other words, as there usually is a shared lib available these days (when the library is installed at all), linking will happen against that shared one, unless you take special precautions (like explicitly requesting static linking, or temporarily moving away the shared lib, or specifying the full path to the .a file directly instead of -lxml2).

      gcc will happily use either a static (.a) or a shared lib (.so)

      Yes - thanks for correcting that. (On Win32, gcc is also capable of linking to the dll.)
      One difficulty in trying to solve the op's problem is that I don't know the name of the file that needs to be linked in. The point I was trying to make was that, if the linking to that file is achieved with '-lxml2', then the linking won't take place, simply because MakeMaker has removed that '-lxml2' link.

      Cheers,
      Rob
        ..then the linking won't take place, simply because MakeMaker has removed that '-lxml2' link.

        That's absolutely correct, and I wasn't questioning that  (I was just commenting on your focus on the .a file :)

        As to the contradicting Makefile.PL messages (the have_library() routine obviously did find it!), I think it would be best if the OP simply looked at which commands are actually being run by the Makefile, in order to figure out whether the -lxml2 together with an appropriate -L/... is there on the command line, as it should.