[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