gmane.comp.python.lxml.devel

Stefan Behnel | 12 May 18:26

Re: 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

headers

Kumar McMillan | 12 May 18:37

Re: install lxml 2.0.5 on Mac OS X Leopard - why is it so hard?

On Mon, May 12, 2008 at 11:26 AM, Stefan Behnel <stefan_ml <at> behnel.de> wrote:
>  > 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

headers

Stefan Behnel | 12 May 20:39

Re: install lxml 2.0.5 on Mac OS X Leopard - why is it so hard?

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

(Continue reading)

headers

maru | 13 May 07:58

Re: install lxml 2.0.5 on Mac OS X Leopard - why is itso hard?

On Mon, 12 May 2008 20:39:57 +0200, Stefan Behnel <stefan_ml <at> behnel.de>
wrote:
<snip>
> 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

headers

Kumar McMillan | 13 May 17:41

Re: install lxml 2.0.5 on Mac OS X Leopard - why is it so hard?

On Mon, May 12, 2008 at 1:39 PM, Stefan Behnel <stefan_ml <at> behnel.de> wrote:
> 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

(Continue reading)