Stefan Behnel schrieb:

Hi,

since there were problems also with libiconv on MacOS recently, I added libiconv to the list of libraries that "--static-deps" builds.

I'd be happy to get some feedback on this to see if it actually works for those who reported problems.

http://codespeak.net/lxml/build.html#subversion http://codespeak.net/lxml/build.html#building-lxml-on-macos-x

Note that the trunk builds as lxml version "2.3dev" now. Copying over the buildlibxml.py script to another lxml version should also work.

http://codespeak.net/svn/lxml/trunk/buildlibxml.py

Stefan

I copied the new 'buildlibxml.py' into a clean lxml-2.2.2 directory and started a build with '-- static-deps'. Everything seems to work fine (libiconv, libxml2, and libxslt build nicely) except form some minor errors like: - 'make[3]: [install-data-local] Error 71 (ignored)' - 'make[2]: [xsltproc.html] Error 4 (ignored)' Unfortunately -- after installing -- I get this ImportError on doing 'import lxml.etree':

ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/site-packages/lxml-2.2.2-py2.5-macosx-10.3-ppc.egg/lxml/ etree.so, 2): Symbol not found: _libiconv_close

Referenced from: /Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/site-packages/lxml-2.2.2-py2.5-macosx-10.3-ppc.egg/lxml/ etree.so

Expected in: dynamic lookup

Speculating if during one of the last steps (lxml?) libiconv isn't linked correctly? Where could I look for this? As the problem is AFAICT only related to the PPC platform (and if running MacOS X 10.4.x?), would it make sense to build libiconv statically only 'if platform.processor() == 'powerpc' and major_version == 8:'? This could possibly help avoid any side effects on Intel or 10.5 systems. Just a thought... Thanks a lot! Pascal