Hello!
I need to install a current release of lxml into a virtualenv on a VPS. This VPS however has some memory quota that doesn't allow me to build it package there. I tried therefore to build a distribution on my laptop (the same architecture, but other linux distro). I used:
$ CFLAGS='-fPIC' python setup.py bdist_egg --static_deps
After installing the egg (with easy_install) on the server I get this:
import lxml.etree
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/pythonista/www/virtualenv/pc-qa/lib/python3.2/site-packages/lxml-3.1.2-py3.2-linux-x86_64.egg/lxml/etree.py", line 7, in <module> __bootstrap__() File "/home/pythonista/www/virtualenv/pc-qa/lib/python3.2/site-packages/lxml-3.1.2-py3.2-linux-x86_64.egg/lxml/etree.py", line 6, in __bootstrap__ imp.load_dynamic(__name__,__file__) ImportError: /home/pythonista/www/virtualenv/pc-qa/lib/python3.2/site-packages/lxml-3.1.2-py3.2-linux-x86_64.egg/lxml/etree.cpython-32mu.so: cannot open shared object file: No such file or directory
So apparently my distribution is still dependent on some files from the base machine. If I try to ldd etree.cpython-32mu.so I get a message that it is not a dynamic package, so I don't know what file does it look for.
So what is the correct way to create a static, binary distribution for lxml, that I could install on a different machine?
Greetings Szymon Pyżalski
Hi,
"lxml" lxml-bounces@lxml.de schrieb am 20.04.2013 13:49:17:
From: Szymon Pyżalski zefciu@gmail.com
import lxml.etree
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/pythonista/www/virtualenv/pc-qa/lib/python3.2/site-packages/ lxml-3.1.2-py3.2-linux-x86_64.egg/lxml/etree.py", line 7, in <module> __bootstrap__() File "/home/pythonista/www/virtualenv/pc-qa/lib/python3.2/site-packages/ lxml-3.1.2-py3.2-linux-x86_64.egg/lxml/etree.py", line 6, in __bootstrap__ imp.load_dynamic(__name__,__file__) ImportError: /home/pythonista/www/virtualenv/pc-qa/lib/python3.2/site-packages/ lxml-3.1.2-py3.2-linux-x86_64.egg/lxml/etree.cpython-32mu.so: cannot open shared object file: No such file or directory
So apparently my distribution is still dependent on some files from the base machine. If I try to ldd etree.cpython-32mu.so I get a message that it is not a dynamic package, so I don't know what file does it look for.
Sounds strange. Could it be that the ldd you used expects 64bit ELF objects but you hand it a 32bit etree.so? The naming scheme seems to suggest s.th. like this ("etree.cpython-32mu.so"). So maybe you're building a 32bit target and try to use it on (non 32bit-enabled) 64bit system?
Holger
Landesbank Baden-Wuerttemberg Anstalt des oeffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz HRA 12704 Amtsgericht Stuttgart
Holger Joukl, 22.04.2013 12:49:
"etree.cpython-32mu.so" So maybe you're building a 32bit target and try to use it on (non 32bit-enabled) 64bit system?
The "32" in "etree.cpython-32mu.so" just refers to the CPython version. Recent Py3 versions make it easier to install shared libraries in system specific versions by encoding version information in the file name.
Stefan
Hi,
On Monday, April 22, 2013 19:09:00 Stefan Behnel wrote:
Holger Joukl, 22.04.2013 12:49:
"etree.cpython-32mu.so" So maybe you're building a 32bit target and try to use it on (non 32bit-enabled) 64bit system?
The "32" in "etree.cpython-32mu.so" just refers to the CPython version. Recent Py3 versions make it easier to install shared libraries in system specific versions by encoding version information in the file name.
Oh, I see, thanks for clarification. Working with too freakin' old Python versions, I am still
But the ldd failing to interpret the file error sounds just like s.th. I encountered lately, which indeed stemmed from a 32 vs 64bit situation in my case.
Holger
Le 22/04/2013 22:25, jholg@gmx.de a écrit :
Hi,
On Monday, April 22, 2013 19:09:00 Stefan Behnel wrote:
Holger Joukl, 22.04.2013 12:49:
"etree.cpython-32mu.so" So maybe you're building a 32bit target and try to use it on (non 32bit-enabled) 64bit system?
The "32" in "etree.cpython-32mu.so" just refers to the CPython version. Recent Py3 versions make it easier to install shared libraries in system specific versions by encoding version information in the file name.
Oh, I see, thanks for clarification. Working with too freakin' old Python versions, I am still
But the ldd failing to interpret the file error sounds just like s.th. I encountered lately, which indeed stemmed from a 32 vs 64bit situation in my case.
The 'file' tool should be able to identify the architecture of a .so file, independently of the architecture running the tool.
participants (5)
-
Holger Joukl -
jholg＠gmx.de -
Simon Sapin -
Stefan Behnel -
Szymon Pyżalski