[lxml-dev] lxml Mac installation idea

Mark Bestley lxml{ at bestley.co.uk
Tue Nov 11 21:32:23 CET 2008


Guntsche Michael <mike at it-loops.com> writes:


> I had tossed around several E-Mails with Paul Everitt today to take a  
> closer look at the iconv issue but you beat me to it, thanks. :)
> As for the static build, my feeling is that the majority of the issues  
> here steam from the fact that while the python app is universal the  
> self-compiled libraries are often i386 only. I had my shares of  
> problems with this before so I compiled every related library as  
> universal and now I no longer have problems.
>

As you said before we need to have some more information
from someone with a broken setup.

My macports setup is intel only and I use its python.
If you want to use Apple Python or I think the python.org prebuilt you need the libraries to be universal.

> Some possible solutions I can add:
>
>   * use macports to compile everything as Universal Binary

I think macports is not fully universal - if the compile is simple it
will work but otherwise a maintainer has to alter the compile and that
has not been done in all cases. From your experience it seems to be OK
for lxml. My macports install is single architecture.

If you are using macports then use its python much easier than mix and
match. There is a lxml port and the easiest way to run is install that
via macports e.g. 
# single architecture
sudo port install py25-lxml
# universal - Michael I assume this is what you did
sudo port install py25-lxml +universal

If you then need a newer version of lxml the the normal setup.py and not
building libxml2 etc will work I think.


>   * Explain in the README how to do this yourself, or provide a script  
> etc.

>
> I do not really like the idea of static builds, since the static  
> library has to be universal as well which means bigger files.
>
I don't understand this point as the dynamic libraries have to be
universal as well if python is universal.

There are also some 64 bit architectures for OSX which implies that the
build architectures should be derived from those used to build python.
I think setup.py does this for the C code in the python package e.g.
etree.so but the correct flags are not passed to libxml2

-- 
Mark



More information about the lxml-dev mailing list