On Aug 1, 2006, at 10:55 PM, Michael Glaesemann wrote:
On Aug 1, 2006, at 23:04 , Sherm Pendley wrote:
Nothing so far has indicated a bug in the module. Quite the
contrary - the crash dump suggests otherwise:
Binary Images Description:
0x605000 - 0x6dafff libiconv.2.dylib /opt/local/lib/
libiconv.2.dylib
0x1008000 - 0x10f0fff libxml2.2.dylib /opt/local/lib/
libxml2.2.dylib
...
0x92a4a000 - 0x92b28fff libxml2.2.dylib /usr/lib/
libxml2.2.dylib
0x92b45000 - 0x92c32fff libiconv.2.dylib /usr/lib/libiconv.
2.dylib
Figure out why this module is linked against both copies of libxml
& libiconv, and I'd bet you'll have solved this problem.
Thanks for pointing this out. I don't have a lot of experience
reading crash dumps, and your explanation is helpful as an
introduction.
Try moving /opt aside before building & testing the module. Before
you do, use otool to see which of these XML::LibXML::XPathContext
is linked against - it may also be that one (or more) of its
prerequisites (XML::LibXML for instance) is also linked the one
in /opt.
I've been trying to figure out where the XML::LibXML::XPathContext
object files are located, but can't find it. (Am I correct in
thinking that's what I should be looking for?) I'm looking in /
Library/Perl/5.8.6.
So far so good. What you're looking for is /Library/Perl/5.8.6/darwin-
thread-multi-2level/auto/XML/LibXML/XPathContext.bundle.
And looking at the otool man page, it looks like I want to use
otool -L when I finally find it, correct?
Yep. You can pass multiple file names to otool, so you can actually
get a quick list of everything all your modules are linked against
like this:
find /Library/Perl/5.8.6 -name '*.bundle' -print0 | xargs -0 otool -L
sherm--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
