[lxml-dev] current trunk includes static build for libiconv

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

Stefan Behnel schrieb:
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':
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

Pascal Oberndoerfer wrote:
Could you post the command line options of the calls to gcc that distutils print during the build?
I doubt that there are any side effects. By now, I actually think it's better to provide a really static build with all external dependencies, rather than relying on things being set up by the system itself. If you request a static build, you get one, that's all. Stefan

Stefan Behnel schrieb:
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':
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

Pascal Oberndoerfer wrote:
Could you post the command line options of the calls to gcc that distutils print during the build?
I doubt that there are any side effects. By now, I actually think it's better to provide a really static build with all external dependencies, rather than relying on things being set up by the system itself. If you request a static build, you get one, that's all. Stefan
participants (2)
-
Pascal Oberndoerfer
-
Stefan Behnel