[lxml-dev] lxml setup.py exslt link flag
Hey, I came across a slight issue with the part of lxml's setup.py that adds a link flag for exslt when libxslt is installed in a directory with a name containing the string 'xslt'. not a huge deal, and probably a somewhat odd case, but I thought I'd mention it. If I understand correctly, to generate the link flag for libexslt, the result of 'xslt-config --libs' is taken and searched for an element containing 'xslt' and a new element is inserted which has 'exslt' instead. setup.py:117: ================================================= xslt_libs = flags('xslt-config --libs') # compile also against libexslt! for i, libname in enumerate(xslt_libs): if 'exslt' in libname: break if 'xslt' in libname: xslt_libs.insert(i, libname.replace('xslt', 'exslt')) break ================================================== In my case, I was working with an install of libxslt in: /home/ltucker/devel/deliverance.buildout/parts/libxslt and 'xslt-config --libs' returns: --------------------------------------------------------------------- -L/home/ltucker/devel/deliverance.buildout/parts/libxslt/lib -L/home/ltucker/devel/deliverance.buildout/parts/libxml2/lib -lxslt -lxml2 -lz -lm --------------------------------------------------------------------- in this case, the snippet above produces a list like --------------------------------------------------------------------- -L/home/ltucker/devel/deliverance.buildout/parts/libexslt/lib -L/home/ltucker/devel/deliverance.buildout/parts/libxslt/lib -L/home/ltucker/devel/deliverance.buildout/parts/libxml2/lib -lxslt -lxml2 -lz -lm --------------------------------------------------------------------- (adding a -L line rather than a -l) The final result was an etree.so that mysteriously didn't have a dependency on libexslt and produced run-time link errors. I believe this problem would apply to the lxml buildout as well, but it doesn't call the parts/libxslt/bin/xslt-config. (Do questions about the lxml buildout go to this list?) As a related side note, it might be nice to have the setup.py complain if 'xslt-config' can't be found. If it isn't around, it appears to silently create an etree.so with no dependencies on libxml2/xslt/exslt. - Luke
Hi, Luke Tucker wrote:
I came across a slight issue with the part of lxml's setup.py that adds a link flag for exslt when libxslt is installed in a directory with a name containing the string 'xslt'.
--------------------------------------------------------------------- -L/home/ltucker/devel/deliverance.buildout/parts/libxslt/lib -L/home/ltucker/devel/deliverance.buildout/parts/libxml2/lib -lxslt -lxml2 -lz -lm ---------------------------------------------------------------------
in this case, the snippet above produces a list like
--------------------------------------------------------------------- -L/home/ltucker/devel/deliverance.buildout/parts/libexslt/lib -L/home/ltucker/devel/deliverance.buildout/parts/libxslt/lib -L/home/ltucker/devel/deliverance.buildout/parts/libxml2/lib -lxslt -lxml2 -lz -lm ---------------------------------------------------------------------
Sure, it replaces the first occurrence, which usually is "-lxslt", so it's expected to add "-lexslt" at that position. Not very robust, as your example shows... Can we rely on every supported compiler to accept "-lxslt" as library parameter? Well, I guess most people use gcc anyway...
I believe this problem would apply to the lxml buildout as well, but it doesn't call the parts/libxslt/bin/xslt-config.
Don't know, never tried.
Do questions about the lxml buildout go to this list?
Definitely the best place for it.
As a related side note, it might be nice to have the setup.py complain if 'xslt-config' can't be found. If it isn't around, it appears to silently create an etree.so with no dependencies on libxml2/xslt/exslt.
As I said, not the most robust code ever. I don't have much time currently, so if you could come up with a patch... Stefan
Hi Luke, Luke Tucker wrote:
I came across a slight issue with the part of lxml's setup.py that adds a link flag for exslt when libxslt is installed in a directory with a name containing the string 'xslt'.
If I understand correctly, to generate the link flag for libexslt, the result of 'xslt-config --libs' is taken and searched for an element containing 'xslt' and a new element is inserted which has 'exslt' instead.
In my case, I was working with an install of libxslt in:
/home/ltucker/devel/deliverance.buildout/parts/libxslt
and 'xslt-config --libs' returns:
--------------------------------------------------------------------- -L/home/ltucker/devel/deliverance.buildout/parts/libxslt/lib -L/home/ltucker/devel/deliverance.buildout/parts/libxml2/lib -lxslt -lxml2 -lz -lm ---------------------------------------------------------------------
I committed a little patch to the trunk that should make setup.py a little (!) more robust against this kind of problem. Please check if it works for you. Stefan
Thanks, that does the trick for me. - Luke On Tue, 2006-11-21 at 08:51 +0100, Stefan Behnel wrote:
Hi Luke,
Luke Tucker wrote:
I came across a slight issue with the part of lxml's setup.py that adds a link flag for exslt when libxslt is installed in a directory with a name containing the string 'xslt'.
If I understand correctly, to generate the link flag for libexslt, the result of 'xslt-config --libs' is taken and searched for an element containing 'xslt' and a new element is inserted which has 'exslt' instead.
In my case, I was working with an install of libxslt in:
/home/ltucker/devel/deliverance.buildout/parts/libxslt
and 'xslt-config --libs' returns:
--------------------------------------------------------------------- -L/home/ltucker/devel/deliverance.buildout/parts/libxslt/lib -L/home/ltucker/devel/deliverance.buildout/parts/libxml2/lib -lxslt -lxml2 -lz -lm ---------------------------------------------------------------------
I committed a little patch to the trunk that should make setup.py a little (!) more robust against this kind of problem. Please check if it works for you.
Stefan
!DSPAM:1014,4562b07b69181362196140!
participants (2)
-
Luke Tucker -
Stefan Behnel