Re: [lxml-dev] install lxml 2.0.5 on Mac OS X Leopard - why is it so hard?
Hi, Mike Meyer wrote:
Apple's official position is that static linking of applications is unsupported. They don't provide static versions of any of the system libraries.
Likewise, macports doesn't provide static libraries for the libraries it installs, and the docs don't hint at anyway to get it to do so.
Great! Now that would have been too easy anyway, wouldn't it? :-/ Thanks for the infos. Now, anyone for a plan B? Stefan
On Mon, May 12, 2008 at 11:26 AM, Stefan Behnel
Likewise, macports doesn't provide static libraries for the libraries it installs, and the docs don't hint at anyway to get it to do so.
Great! Now that would have been too easy anyway, wouldn't it? :-/
Thanks for the infos. Now, anyone for a plan B?
It looks to me like the typical way to do this in an OS X app is to compile your static libs then bundle them with your application (and as Mike pointed out, Apple does not recommend this). Obviously there is a ram penalty for that (the custom lib). I don't see lxml distributing static libs just for OS X :) The best thing I can think of is to get --static working for libxml2.a files and then I can submit to you the steps I took to build my static libs from source (assuming I can get that all to work). Would that be useful? If it proves too cumbersome I might just continue to use the DYLD_FORCE_FLAT_NAMESPACE var at runtime even though that's bound to bite me someday. Unlike Mike I am fortunate enough not to be using lxml in *production* on OS X ... yet also misfortunate enough to be the only one who sees segfaults :( K
Kumar McMillan wrote:
The best thing I can think of is to get --static working for libxml2.a files and then I can submit to you the steps I took to build my static libs from source (assuming I can get that all to work).
I think a buildout will help here, as previously proposed a couple of times. http://pypi.python.org/pypi/zc.buildout http://pypi.python.org/pypi/zc.recipe.cmmi We can configure it to build only the static versions of libxml2 and libxslt, and then build against those. ------------------------ [libxml2] recipe = zc.recipe.cmmi url = http://ftp.gnome.org/pub/GNOME/sources/libxml2/2.6/libxml2-2.6.32.tar.gz extra_options = --without-python --enable-shared --enable-static [libxslt] recipe = zc.recipe.cmmi url = http://ftp.gnome.org/pub/GNOME/sources/libxslt/1.1/libxslt-1.1.22.tar.bz2 extra_options = --with-libxml-prefix=${buildout:directory}/parts/libxml2/ --without-python --disable-shared --enable-static [lxml] recipe = zc.recipe.egg:custom egg = lxml include-dirs = ${buildout:directory}/parts/libxml2/include/libxml2 ${buildout:directory}/parts/libxslt/include library-dirs = ${buildout:directory}/parts/libxml2/lib ${buildout:directory}/parts/libxslt/lib ------------------------ lxml's setup.py would then need to be changed to automatically compile statically on the Mac-OS platform. Although maybe we should only do that if buildout is running (sys.modules?). Stefan
On Mon, 12 May 2008 20:39:57 +0200, Stefan Behnel
lxml's setup.py would then need to be changed to automatically compile statically on the Mac-OS platform. Although maybe we should only do that if buildout is running (sys.modules?).
Please leave the dynamic build as default option since it makes building universal libraries so much easier. A static build if buildout is used would be better in my opinion. Kind regards, Michael
On Mon, May 12, 2008 at 1:39 PM, Stefan Behnel
Kumar McMillan wrote:
The best thing I can think of is to get --static working for libxml2.a files and then I can submit to you the steps I took to build my static libs from source (assuming I can get that all to work).
I think a buildout will help here, as previously proposed a couple of times.
ah, yes, excellent idea. I've started fiddling with it and have libxml2/libxslt building static libs no problem; this might just work. It looks like zc.recipe.egg isn't going to cut it though, as I can't find a way to pass in custom setup.py flags like --static (which I think is still needed to find libxml2.a, etc). I found collective.recipe.distutils which might work. I found some issues with it already but patching as I go. More as it happens - Kumar
http://pypi.python.org/pypi/zc.buildout http://pypi.python.org/pypi/zc.recipe.cmmi
We can configure it to build only the static versions of libxml2 and libxslt, and then build against those.
------------------------ [libxml2] recipe = zc.recipe.cmmi url = http://ftp.gnome.org/pub/GNOME/sources/libxml2/2.6/libxml2-2.6.32.tar.gz extra_options = --without-python --enable-shared --enable-static
[libxslt] recipe = zc.recipe.cmmi url = http://ftp.gnome.org/pub/GNOME/sources/libxslt/1.1/libxslt-1.1.22.tar.bz2 extra_options = --with-libxml-prefix=${buildout:directory}/parts/libxml2/ --without-python --disable-shared --enable-static
[lxml] recipe = zc.recipe.egg:custom egg = lxml include-dirs = ${buildout:directory}/parts/libxml2/include/libxml2 ${buildout:directory}/parts/libxslt/include library-dirs = ${buildout:directory}/parts/libxml2/lib ${buildout:directory}/parts/libxslt/lib ------------------------
lxml's setup.py would then need to be changed to automatically compile statically on the Mac-OS platform. Although maybe we should only do that if buildout is running (sys.modules?).
Stefan
participants (3)
-
Kumar McMillan -
maru -
Stefan Behnel