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

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

Replies are listed 'Best First'.
Re^3: XML::LibXML::Common 0.13 on linux - undefined symbol
by syphilis (Archbishop) on May 13, 2009 at 00:18 UTC
    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.