[ome-devel] XML::LibXML and Later Versions of libxml2

Ilya Goldberg igg at nih.gov
Thu Jun 1 16:56:37 BST 2006


I did some experimentation on installing dependencies in non-standard  
places.
The sand-box was to create a "hello world" dynamic library, and build  
a perl XS module around it.
Both the library and the perl module were then installed in a non- 
standard place (i.e. /OME/lib), and tested from mod_perl.
There were a couple of problems:
On FC2, MakeMaker didn't specify "LD_RUN_PATH" when building the  
bundle for perl, so that required manually editing the Makefile.  The  
resulting code bundle for perl had an 'unknown' location for the  
dynamic library as reported by ldd.  FC1 did the right thing with it.
On OS X, the dynamic library didn't "take" until Apache was  
completely shut down and started again ("apachectl restart" didn't  
work).  There were no errors reported - it just silently didn't  
work.  The path to the library was correctly specified when checked  
with otool -L.

The technique basically involves specifying a PREFIX= for 'perl  
Makefile.PL', --libdir= for ./configure when building the C lib (or -- 
prefix), and setting:
     LIBS              => ['-L/OME/lib -lhello '],
in Makefile.PL

These are fairly minor things to get around (assuming that's the full  
range of brokenness), and this will allow us to install our own  
dependencies wherever we want without interfering with things  
installed on the system.  The installer can check for much more  
specific versions when looking at what's installed on the system, and  
install our own c libraries and perl modules in /OME/lib or wherever.
Or, we can just always install our own collection of dependencies no  
matter what.  We could easily have binaries available for several  
different platforms that are in use, and fall back to compiling on  
unrecognized systems.

This would essentially make the dependency issues handled  
equivalently to Java, where everything under the Sun is distributed  
in the .jar.  The advantages ('known good' dependencies distributed  
with the installation) as well as the disadvantages (we get to manage  
upgrades of the dependencies) are then the same.

-Ilya



On May 19, 2006, at 12:48 PM, Ilya Goldberg wrote:

> Thanks for that, Chris.
> I think its worth-while thinking about packaging some of these
> dependencies with the code-base or at least the distribution (like
> its done with Java).
> We could go all the way and package all of the perl dependencies and
> call "use lib /OME/perl/deps".  That would be equivalent to a Java
> distro with a CLASSPATH.
> Its not the "style" outside of Java for OSS apps, but we could
> certainly adopt it for perl and still not step on anybody's toes.  It
> would get around all kinds of installation issues.
> What do you think of that?
> -Ilya
>
> On May 12, 2006, at 6:57 AM, Chris Allan wrote:
>
>> Hello all,
>>
>> Over the past couple of days I've been fighting with some OME install
>> problems that have come down to XML parsing errors. First, some
>> background:
>>
>> callan at valewalker OME $ equery list libxml2
>> [ Searching for package 'libxml2' in all categories among: ]
>> * installed packages
>> [I--] [  ] dev-libs/libxml2-2.6.23 (2)
>>
>> Our good friend Christian Glahn (phish) who wrote much of the
>> XML::LibXML Perl module has not released a new version in over 2
>> years. Normally this wouldn't be a problem, however libxml2
>> development has happily moved forward (http://xmlsoft.org/news.html)
>> since the 1.58 release of XML::LibXML on the 4th April of 2004. In
>> fact, there have been no less than 15 libxml2 releases since then (my
>> Gentoo libxml2-2.6.23 being based on the 14th).
>>
>> Now, since XML::LibXML provides Perl bindings to the libxml2 C
>> library using Swig and Perl XS, libxml2 API changes can affect things
>> in weird and wonderful ways such as "Bad file descriptors" errors
>> when attempting to load certain OME XML files during an OME install.
>> Less than pleasant, less than descriptive and a little bit arcane.
>> However, there is a solution...
>>
>> Through the power of CVS tree hunting and pecking (http://axkit.org/
>> cgi-bin/viewcvs.cgi/XML-LibXML/ and http://axkit.org/cvs.xml for
>> those interested) I've now got a working install using a CVS version
>> of XML::LibXML. Checkout here: http://users.openmicroscopy.org.uk/
>> ~callan/XML-LibXML-20060512.tar.bz2
>>
>> If you've got later versions of libxml2 and are having general XML
>> parsing weirdness, might want to give an install of that a try.
>>
>> Ciao.
>>
>> -Chris
>> _______________________________________________
>> ome-devel mailing list
>> ome-devel at lists.openmicroscopy.org.uk
>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>>
>
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>



More information about the ome-devel mailing list