[lxml-dev] Help getting lxml to work reliably on MacOS-X
Hi, it looks like many Mac users have problems with lxml on their platform. This usually involves installing up-to-date dependencies (libxml2/libxslt) in addition to the system libraries. I would like to get these problems resolved. To get a start on this, we must collect some information. We had a few reports, but I need to know in more detail what people did, what they tried, and to what avail. So here is a list of questions for Mac users. Please help us by answering them. Some instructions follow at the end. When building lxml, please move any installed Cython versions out of the way and run the build on the unpacked lxml-2.0.tar.gz release sources. It must say "trying to build without Cython" at the beginning. Please provide the following information: - what package management system (fink/macports) do you use? - are you using the stock Python or one that is installed separately? - what library versions are you using of libxml2, libxslt, zlib, libiconv? - which library versions are preinstalled on your platform? (I do not know how to find that out, can anyone provide instructions here?) - what library versions does lxml.etree find? (see below) Just in case there are people who actually have a working installation, - has anyone successfully built lxml statically against libxml2/libxslt? * does it work reliably? (see "Testing" below) * did you build with the --without-threads option? * does it work with *and* without that option? - has anyone managed to get lxml working reliably (see "Testing" below) with a dynamic build? * did you set DYLD_LIBRARY_PATH? * is DYLD_LIBRARY_PATH required for you or does it work without? * is there anything special you did to make it work? * if there are crashes, is the install unusable or are there things you can still do reliably? If lxml crashes for you, - does it work if you set DYLD_LIBRARY_PATH at runtime? (dynamic builds only) - does it work when building with the --without-threads option? - does it crash when running the normal tests? - if the tests pass fine, does it crash with the "ot-test" script below? Every reply is appreciated. You can reply in private e-mail, if you prefer, although it might be helpful to others to see your answer. Thanks in advance, Stefan Here are some instructions: * Checking library versions Please report the library versions that lxml.etree thinks it is using: http://codespeak.net/lxml/FAQ.html#i-think-i-have-found-a-bug-in-lxml-what-s... * Setting DYLD_LIBRARY_PATH When you run tests or an application with lxml, you can pass the environment variable DYLD_LIBRARY_PATH to your program. It needs to be set to the directory (or directories) where lxml's library dependencies are installed, i.e. libxml2 and libxslt. http://codespeak.net/lxml/build.html#providing-newer-library-versions-on-mac... * Testing When I say "works reliably", I mean, without crashes. The first thing to verify that is to run "make test". If it already crashes here, there is no need to try the script below. Please report anything you can find out about the crash in this case. A debugger run and/or a stack trace might give us some useful hints here. If the normal tests pass, please try another test. Here is an XML document and a script that fires off a bunch of threads to parse the document and run multiple XSLTs over it. The archive is about 1MB. http://codespeak.net/lxml/ot-test.zip It's kind of a worst-case scenario that I use to find problems, so if you have a working installation of lxml 2.0, please run it to see if it crashes for you. Parsing may fail (usually for threads 7-9), that's fine, but it must not crash with your otherwise working setup. It normally starts up 16 threads, which should require a couple of hundred MB of memory. If you find that it runs out of memory, you can try running less threads instead by passing the number to the script at the command line.
On Feb 4, 2008 2:45 AM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Hi,
it looks like many Mac users have problems with lxml on their platform. This usually involves installing up-to-date dependencies (libxml2/libxslt) in addition to the system libraries. I would like to get these problems resolved.
For whatever it's worth, I could usually get lxml to work by itself, when it was the only thing imported in the python interpreter. The problem came when it was imported in a webapp with a bunch of other modules. I believe threading may also have been involved. I'll try to fill out a full report in the next few days, but I've actually obviated my need for lxml by porting lxml.html.clean to BeautifulSoup. It runs nicely and all the tests pass after adjusting for whitespace differences.
On Feb 4, 2008, at 9:45, Stefan Behnel wrote: <snip>
When building lxml, please move any installed Cython versions out of the way and run the build on the unpacked lxml-2.0.tar.gz release sources. It must say "trying to build without Cython" at the beginning.
Slight difference here Cython 0.9.6.11 and lxml from current trunk.
Please provide the following information:
- what package management system (fink/macports) do you use?
- are you using the stock Python or one that is installed separately?
- what library versions are you using of libxml2, libxslt, zlib, libiconv?
- which library versions are preinstalled on your platform? (I do not know how to find that out, can anyone provide instructions here?)
With tiger the preinstalled libraries are lxml2: 2.6.16 lxslt: 1.1.11 To get this information just run /usr/bin/xml2-config --version /usr/bin/xslt-config --version Leopard should have newer libraries but I have no machine right now to check that.
- what library versions does lxml.etree find? (see below)
The OS is Macosx Tiger 10.4.11 Python is version 2.5.1 universal binary from www.python.org package management for (libxml2, libxslt) is macports TESTED VERSION: 2.0.0-51232 Python: (2, 5, 1, 'final', 0) lxml.etree: (2, 0, 0, 51232) libxml used: (2, 6, 31) libxml compiled: (2, 6, 31) libxslt used: (1, 1, 22) libxslt compiled: (1, 1, 22) All libraries are universal built libraries from macports and linked dynamically. I have not tried static, since macports by default ONLY compiles dynamic libraries and everyhing seems to be working fine for me.
Just in case there are people who actually have a working installation,
- has anyone successfully built lxml statically against libxml2/ libxslt?
As said before dynamically linked only.
* does it work reliably? (see "Testing" below)
ot-test runs through without any crashes. Threads 7-9 throw exceptions though, as you said.
* did you build with the --without-threads option? * does it work with *and* without that option?
Dynamically linked only
- has anyone managed to get lxml working reliably (see "Testing" below) with a dynamic build?
* did you set DYLD_LIBRARY_PATH? * is DYLD_LIBRARY_PATH required for you or does it work without? * is there anything special you did to make it work?
DYLD_LIBRARY_PATH is not set at all. All I had to do for lxml to find the correct libraries was to make sure that xml2-config and xslt-config from my macports installation is found BEFORE the stock versions in /usr/bin. This way etree links against the correct libraries.
* if there are crashes, is the install unusable or are there things you can still do reliably?
No crashes at all. If you need any more information just tell me. Kind regards, Michael
Hi, Michael Guntsche wrote:
On Feb 4, 2008, at 9:45, Stefan Behnel wrote: <snip>
When building lxml, please move any installed Cython versions out of the way and run the build on the unpacked lxml-2.0.tar.gz release sources. It must say "trying to build without Cython" at the beginning.
Slight difference here Cython 0.9.6.11 and lxml from current trunk.
:) ... if even that works, I really don't know what ...
With tiger the preinstalled libraries are
lxml2: 2.6.16 lxslt: 1.1.11
To get this information just run
/usr/bin/xml2-config --version /usr/bin/xslt-config --version
Ah, sure, thanks. Those libraries are definitely too old and too buggy.
ot-test runs through without any crashes. Threads 7-9 throw exceptions though, as you said.
Then that really looks like a safe setup.
DYLD_LIBRARY_PATH is not set at all. All I had to do for lxml to find the correct libraries was to make sure that xml2-config and xslt-config from my macports installation is found BEFORE the stock versions in /usr/bin. This way etree links against the correct libraries.
Hmmm, could others comment on this? Does this make a difference? Especially for those, who must currently set the DYLD var? Stefan
On Feb 4, 2008, at 19:55, Stefan Behnel wrote:
DYLD_LIBRARY_PATH is not set at all. All I had to do for lxml to find the correct libraries was to make sure that xml2-config and xslt-config from my macports installation is found BEFORE the stock versions in /usr/bin. This way etree links against the correct libraries.
Hmmm, could others comment on this? Does this make a difference? Especially for those, who must currently set the DYLD var?
Just had a look at setupinfo.py and CHANGES.txt, only "xslt-config" is used to find the corrent CFLAGS and libs, but since xml2-config and xslt-config should always be in the same directory this should not be much of a problem. So just make sure the new xslt-config is found first and you should be safe. /Michael
Hey, On 2008-02-04 09:45:37 +0100, Stefan Behnel <stefan_ml@behnel.de> said:
Hi,
it looks like many Mac users have problems with lxml on their platform. This usually involves installing up-to-date dependencies (libxml2/libxslt) in addition to the system libraries. I would like to get these problems resolved.
To get a start on this, we must collect some information. We had a few reports, but I need to know in more detail what people did, what they tried, and to what avail. So here is a list of questions for Mac users. Please help us by answering them. Some instructions follow at the end.
When building lxml, please move any installed Cython versions out of the way and run the build on the unpacked lxml-2.0.tar.gz release sources. It must say "trying to build without Cython" at the beginning.
Please provide the following information:
- what package management system (fink/macports) do you use?
We use buidout for the development/deployment. Via buildout we build basically everything to be sure we get consistent results: [libxml2] recipe = zc.recipe.cmmi url = http://ftp.gnome.org/pub/GNOME/sources/libxml2/2.6/libxml2-2.6.26.tar.gz extra_options = --without-python [libxslt] recipe = zc.recipe.cmmi url = http://ftp.gnome.org/pub/GNOME/sources/libxslt/1.1/libxslt-1.1.16.tar.bz2 extra_options = --with-libxml-prefix=${buildout:directory}/parts/libxml2/ --without-python [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 rpath = ${buildout:directory}/parts/libxml2/lib ${buildout:directory}/parts/libxslt/lib
- are you using the stock Python or one that is installed separately?
Custom built python wich *nothing* else installed. [....] I'll look after the other things when i've got more time. But basically since using buildout we're fine :) -- Christian Zagrodnick gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
Hi, Christian Zagrodnick wrote:
We use buildout for the development/deployment. Via buildout we build basically everything to be sure we get consistent results
Martijn also made a buildout script for lxml a while ago: http://faassen.n--tree.net/blog/view/weblog/2006/10/03/0 I guess this is really helpful. Definitely for production environments, but it might also come in handy for Mac users. Can someone enlighten me how finding libxml2/libxslt works here at runtime? Martijn, you suggested adding this to lxml back then. I think we should have this in SVN so that people can use it straight away. Stefan
On 05.02.2008, at 21:22, Stefan Behnel wrote:
Hi,
Christian Zagrodnick wrote:
We use buildout for the development/deployment. Via buildout we build basically everything to be sure we get consistent results
Martijn also made a buildout script for lxml a while ago:
http://faassen.n--tree.net/blog/view/weblog/2006/10/03/0
I guess this is really helpful. Definitely for production environments, but it might also come in handy for Mac users.
Can someone enlighten me how finding libxml2/libxslt works here at runtime?
Well, the generated scripts use the compiled lxml: % grep lxml bin/test '/Users/zagy/.../develop-eggs/lxml-2.0-py2.4-macosx-10.5-i386.egg', And actually I thought the `rpath` option was there to do that: rpath: A new-line separated list of directories to search for dynamic libraries at run time. But that doesn't exactly seem to work as it really seems lxml would use the system libraries at runtime. Gotta ask jim. -- Christian Zagrodnick gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
On 2008-02-07 08:52:40 +0100, Christian Zagrodnick <cz@gocept.com> said:
On 05.02.2008, at 21:22, Stefan Behnel wrote:
Hi,
Christian Zagrodnick wrote:
We use buildout for the development/deployment. Via buildout we build basically everything to be sure we get consistent results
Martijn also made a buildout script for lxml a while ago:
http://faassen.n--tree.net/blog/view/weblog/2006/10/03/0
I guess this is really helpful. Definitely for production
environments, but it might also come in handy for Mac users.
Can someone enlighten me how finding libxml2/libxslt works here at
runtime?
Well, the generated scripts use the compiled lxml:
% grep lxml bin/test '/Users/zagy/.../develop-eggs/lxml-2.0-py2.4-macosx-10.5-i386.egg',
And actually I thought the `rpath` option was there to do that:
rpath: A new-line separated list of directories to search for dynamic
libraries at run time.
But that doesn't exactly seem to work as it really seems lxml would
use the system libraries at runtime. Gotta ask jim.
Right, so actually buildout does the right thing. The main problem is, that lxml runs the wrong xslt-config. So I was bascially buildint libxml2 and libxslt just for the fun of it. The question is if lxml really always needs to call xslt-config. Or how one would set the path in the buildout so that the right xslt-config is called. If I manually set the path it works like charm: % PATH=`pwd`/parts/libxslt/bin:$PATH bin/buildout -- Christian Zagrodnick gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
Hi, Christian Zagrodnick wrote:
The main problem is, that lxml runs the wrong xslt-config. So I was basically building libxml2 and libxslt just for the fun of it.
The question is if lxml really always needs to call xslt-config. Or how one would set the path in the buildout so that the right xslt-config is called.
If I manually set the path it works like charm:
% PATH=`pwd`/parts/libxslt/bin:$PATH bin/buildout
You can now pass "--with-xslt-config=XXX" to setup.py. Stefan
On 2008-02-08 20:43:18 +0100, Stefan Behnel <stefan_ml@behnel.de> said:
Hi,
Christian Zagrodnick wrote:
The main problem is, that lxml runs the wrong xslt-config. So I was basically building libxml2 and libxslt just for the fun of it.
The question is if lxml really always needs to call xslt-config. Or how one would set the path in the buildout so that the right xslt-config is called.
If I manually set the path it works like charm:
% PATH=`pwd`/parts/libxslt/bin:$PATH bin/buildout
You can now pass "--with-xslt-config=XXX" to setup.py.
Gotta check how we best pass that along in buildout. -- Christian Zagrodnick gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
On 2008-02-09 14:33:43 +0100, Christian Zagrodnick <cz@gocept.com> said:
On 2008-02-08 20:43:18 +0100, Stefan Behnel <stefan_ml@behnel.de> said:
Hi,
Christian Zagrodnick wrote:
The main problem is, that lxml runs the wrong xslt-config. So I was basically building libxml2 and libxslt just for the fun of it.
The question is if lxml really always needs to call xslt-config. Or how one would set the path in the buildout so that the right xslt-config is called.
If I manually set the path it works like charm:
% PATH=`pwd`/parts/libxslt/bin:$PATH bin/buildout
You can now pass "--with-xslt-config=XXX" to setup.py.
Gotta check how we best pass that along in buildout.
So in the *next* version of zc.recipe.egg (i.e. >1.0.0), the following will probably work. It works with the trunk of zc.recipe.egg (but this is neither released nor has it been reviewed by Jim Fulton, yet): [libxml2] recipe = zc.recipe.cmmi url = http://ftp.gnome.org/pub/GNOME/sources/libxml2/2.6/libxml2-2.6.30.tar.gz extra_options = --without-python [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 [lxml-environment] PATH=${buildout:directory}/parts/libxslt/bin:%(PATH)s [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 rpath = ${buildout:directory}/parts/libxml2/lib ${buildout:directory}/parts/libxslt/lib environment = lxml-environment Regards, -- Christian Zagrodnick gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
Hi, Christian Zagrodnick wrote:
On 2008-02-09 14:33:43 +0100, Christian Zagrodnick <cz@gocept.com> said:
On 2008-02-08 20:43:18 +0100, Stefan Behnel <stefan_ml@behnel.de> said:
Christian Zagrodnick wrote:
The main problem is, that lxml runs the wrong xslt-config. So I was basically building libxml2 and libxslt just for the fun of it.
The question is if lxml really always needs to call xslt-config. Or how one would set the path in the buildout so that the right xslt-config is called.
If I manually set the path it works like charm:
% PATH=`pwd`/parts/libxslt/bin:$PATH bin/buildout You can now pass "--with-xslt-config=XXX" to setup.py.
... and --with-xml2-config=YYY, just in case you installed both in different places.
Gotta check how we best pass that along in buildout.
So in the *next* version of zc.recipe.egg (i.e. >1.0.0), the following will probably work. It works with the trunk of zc.recipe.egg (but this is neither released nor has it been reviewed by Jim Fulton, yet):
[lxml-environment] PATH=${buildout:directory}/parts/libxslt/bin:%(PATH)s [...]
... and, you can also set the XML2_CONFIG and XSLT_CONFIG environment variables to make sure setup.py really picks up the right config. Stefan
- what package management system (fink/macports) do you use? MacPorts
- are you using the stock Python or one that is installed separately? Python2.5.1 from MacPorts
- what library versions are you using of libxml2, libxslt, zlib, libiconv? % port installed |egrep 'libxml2|xslt|zlib|iconv' libiconv @1.12_0+darwin_8 (active) libxml2 @2.6.31_0 (active) libxslt @1.1.22_0 (active) py25-zlib @2.5.1_0 (active) zlib @1.2.3_1 (active)
- which library versions are preinstalled on your platform? (I do not know how to find that out, can anyone provide instructions here?) What library?
- what library versions does lxml.etree find? (see below) from lxml import etree print "lxml.etree: ", etree.LXML_VERSION lxml.etree: (2, 0, 0, 0) print "libxml used: ", etree.LIBXML_VERSION libxml used: (2, 6, 31) print "libxml compiled: ", etree.LIBXML_COMPILED_VERSION libxml compiled: (2, 6, 31) print "libxslt used: ", etree.LIBXSLT_VERSION libxslt used: (1, 1, 22) print "libxslt compiled: ", etree.LIBXSLT_COMPILED_VERSION libxslt compiled: (1, 1, 22)
- does it crash when running the normal tests? Ran 1101 tests in 12.232s
FAILED (errors=14) make: *** [test_inplace] Error 1
Hello,
- what package management system (fink/macports) do you use? macports
- are you using the stock Python or one that is installed separately? the stock Python bundled with Leopard
- what library versions are you using of libxml2, libxslt, zlib, libiconv? $ port installed |egrep 'libxml2|xslt|zlib|iconv' libiconv @1.12_0 (active) libxml2 @2.6.31_0 (active) libxslt @1.1.22_0 (active) zlib @1.2.3_1 (active)
When I'm trying to make the install, I get the following errors : MacBook-Pro:Downloads jibaku$ sudo easy_install lxml==2.0.2 Searching for lxml==2.0.2 Reading http://pypi.python.org/simple/lxml/ Reading http://codespeak.net/lxml Best match: lxml 2.0.2 Downloading http://codespeak.net/lxml/lxml-2.0.2.tgz Processing lxml-2.0.2.tgz Running lxml-2.0.2/setup.py -q bdist_egg --dist-dir /tmp/easy_install--6uwin/lxml-2.0.2/egg-dist-tmp-25cVmi Building lxml version 2.0.2. NOTE: Trying to build without Cython, pre-generated 'src/lxml/etree.c' needs to be available. warning: no previously-included files found matching 'doc/pyrex.txt' ld warning: in /opt/local/lib/libxslt.dylib, file is not of required architecture ld warning: in /opt/local/lib/libexslt.dylib, file is not of required architecture ld warning: in /opt/local/lib/libxml2.dylib, file is not of required architecture ld warning: in /opt/local/lib/libz.dylib, file is not of required architecture ld warning: in /opt/local/lib/libxslt.dylib, file is not of required architecture ld warning: in /opt/local/lib/libexslt.dylib, file is not of required architecture ld warning: in /opt/local/lib/libxml2.dylib, file is not of required architecture ld warning: in /opt/local/lib/libz.dylib, file is not of required architecture ld warning: in /opt/local/lib/libxslt.dylib, file is not of required architecture ld warning: in /opt/local/lib/libexslt.dylib, file is not of required architecture ld warning: in /opt/local/lib/libxml2.dylib, file is not of required architecture ld warning: in /opt/local/lib/libz.dylib, file is not of required architecture No eggs found in /tmp/easy_install--6uwin/lxml-2.0.2/egg-dist-tmp-25cVmi (setup script problem?) Thanks in advance -- Fabien SCHWOB
Hi, Fabien wrote:
- what package management system (fink/macports) do you use? macports
- are you using the stock Python or one that is installed separately? the stock Python bundled with Leopard
- what library versions are you using of libxml2, libxslt, zlib, libiconv? $ port installed |egrep 'libxml2|xslt|zlib|iconv' libiconv @1.12_0 (active) libxml2 @2.6.31_0 (active) libxslt @1.1.22_0 (active) zlib @1.2.3_1 (active)
When I'm trying to make the install, I get the following errors :
MacBook-Pro:Downloads jibaku$ sudo easy_install lxml==2.0.2 Searching for lxml==2.0.2 Reading http://pypi.python.org/simple/lxml/ Reading http://codespeak.net/lxml Best match: lxml 2.0.2 Downloading http://codespeak.net/lxml/lxml-2.0.2.tgz Processing lxml-2.0.2.tgz Running lxml-2.0.2/setup.py -q bdist_egg --dist-dir /tmp/easy_install--6uwin/lxml-2.0.2/egg-dist-tmp-25cVmi Building lxml version 2.0.2. NOTE: Trying to build without Cython, pre-generated 'src/lxml/etree.c' needs to be available. warning: no previously-included files found matching 'doc/pyrex.txt' ld warning: in /opt/local/lib/libxslt.dylib, file is not of required architecture ld warning: in /opt/local/lib/libexslt.dylib, file is not of required architecture
Just guessing, but this looks like a problem with your setup. It seems to use the correct libraries in /opt/local (although it doesn't look like building anything here). But somehow they do not seem to fit either your Python or the compiler, so apparently it can't build against them. Is this on Intel or PPC? Maybe others can comment on this? Stefan
On Fri, 14 Mar 2008 17:30:32 +0100 Stefan Behnel <stefan_ml@behnel.de> wrote:
Hi,
Fabien wrote:
- what package management system (fink/macports) do you use? macports
- are you using the stock Python or one that is installed separately? the stock Python bundled with Leopard
- what library versions are you using of libxml2, libxslt, zlib, libiconv? $ port installed |egrep 'libxml2|xslt|zlib|iconv' libiconv @1.12_0 (active) libxml2 @2.6.31_0 (active) libxslt @1.1.22_0 (active) zlib @1.2.3_1 (active)
When I'm trying to make the install, I get the following errors :
MacBook-Pro:Downloads jibaku$ sudo easy_install lxml==2.0.2 Searching for lxml==2.0.2 Reading http://pypi.python.org/simple/lxml/ Reading http://codespeak.net/lxml Best match: lxml 2.0.2 Downloading http://codespeak.net/lxml/lxml-2.0.2.tgz Processing lxml-2.0.2.tgz Running lxml-2.0.2/setup.py -q bdist_egg --dist-dir /tmp/easy_install--6uwin/lxml-2.0.2/egg-dist-tmp-25cVmi Building lxml version 2.0.2. NOTE: Trying to build without Cython, pre-generated 'src/lxml/etree.c' needs to be available. warning: no previously-included files found matching 'doc/pyrex.txt' ld warning: in /opt/local/lib/libxslt.dylib, file is not of required architecture ld warning: in /opt/local/lib/libexslt.dylib, file is not of required architecture
Just guessing, but this looks like a problem with your setup. It seems to use the correct libraries in /opt/local (although it doesn't look like building anything here). But somehow they do not seem to fit either your Python or the compiler, so apparently it can't build against them. Is this on Intel or PPC?
Maybe others can comment on this?
IIRC, macports builds binaries for your system, not universal binaries. /usr/bin/python, on the other hand, is a universal binary. See if the library ports have a universal variant, and if so, try installing that. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Hello,
IIRC, macports builds binaries for your system, not universal binaries. /usr/bin/python, on the other hand, is a universal binary. See if the library ports have a universal variant, and if so, try installing that.
Yes ! It nearly works. Now when I'm trying to install lxml with easy_install I get the following (in verbose mode) : http://pastebin.com/f4c1468c8 The build seems to be ok, but it fails when installing. -- Fabien SCHWOB _____________________________________________________________ Derrière chaque bogue, il y a un développeur, un homme qui s'est trompé. (Bon, OK, parfois ils s'y mettent à plusieurs).
participants (7)
-
Christian Zagrodnick -
Fabien -
Jon Rosebaugh -
js -
Michael Guntsche -
Mike Meyer -
Stefan Behnel