what do I need to correctly port boost python extensions
Hello to everyone, I get confused trying to port my boost python extension module. So I've made a shared object file test.so which actually perfectly works in the original development directory. However, when I copy this file to another Linux machine (I also copy some extra libraries such as libboost_python-gcc344-1_39.so.1.39.0 and make sure that both .so files are in PATH and LD_LIBRARY_PATH) I recieve "Import Error: undefined symbol: /home/username/bin/libboost_python-gcc34-1_39.so.1.39.0: PyUnicodeUCS4_FromEncodedObject". I aslo istalled the same version (compared to one which was used for creation of the module) of Python to the Linux machine where I try to use my extension. Can anyone explain me where could the problem be. Also I would clarify what is the general way to export just created modules? As I understand the order is following: 1) create .so object (look for it in /bin/compiler-name/release-or-debug/module-name.so directory) 2) copy this file as well as other necessary library to some /bin or /lib directory (for convenience) - and make sure they are in PATH and LD_LIBRARY_PATH variables. 3) import the module in python interpreter. Do I need to do something else (define some other variables or make some other changes) in order to make my module work? Thanks a lot Alexey
Alexey Akimov <alexey.akimov85@gmail.com> writes:
I get confused trying to port my boost python extension module. So I've made a shared object file test.so which actually perfectly works in the original development directory. However, when I copy this file to another Linux machine (I also copy some extra libraries such as
I am not very familiar with Py++ yet, but .so libraries are not supposed to be copied around from machine to machine unless your runtime environment is exactly the same. You should probably compile test.so (and any other required libraries) on the target machine (i.e., copy the sources and not the binaries from the development system). Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
Thanks, Nikolaus However I am still wondering if there is a way to avoid rebuilding the extension when one travel from machine to machine. Of course that should definitely work, but it seems unpractical for many purposes or at least inconvenient. Suppose I want to run some calculations on a cluster using the extension. That means I need the library to be copied on every machine of that cluster (may be I am wrong with this but this is most straightforward way to clone the process). Also this makes lot of potential troubles for other users who would want to work with such extension - do they need to rebuild extension module every time? I hope that there may exist some fancy way to avoid rebuilding the module (also to do this the user would need boost python installed, what may require some extra-work for that user). So if anyone knows if this is still possible - please, let me know. Alexey 2009/12/14 Nikolaus Rath <Nikolaus@rath.org>
Alexey Akimov <alexey.akimov85@gmail.com> writes:
I get confused trying to port my boost python extension module. So I've made a shared object file test.so which actually perfectly works in the original development directory. However, when I copy this file to another Linux machine (I also copy some extra libraries such as
I am not very familiar with Py++ yet, but .so libraries are not supposed to be copied around from machine to machine unless your runtime environment is exactly the same.
You should probably compile test.so (and any other required libraries) on the target machine (i.e., copy the sources and not the binaries from the development system).
Best,
-Nikolaus
-- »Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
_______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Alexey Akimov <alexey.akimov85@gmail.com> writes:
However I am still wondering if there is a way to avoid rebuilding the extension when one travel from machine to machine.
The only way is to have exactly the same runtime environment (i.e., having installed the same distributions with the same version on the same architecture). Otherwise you have to recompile.
Suppose I want to run some calculations on a cluster using the extension. That means I need the library to be copied on every machine of that cluster (may be I am wrong with this but this is most straightforward way to clone the process).
Well, in a cluster you might be able to configure your systems sufficiently homogenous that it works.
Also this makes lot of potential troubles for other users who would want to work with such extension - do they need to rebuild extension module every time?
No, only once when they install it on their machine.
I hope that there may exist some fancy way to avoid rebuilding the module (also to do this the user would need boost python installed, what may require some extra-work for that user).
No, there is no way to avoid that. Say hello to the realities of software distribution :-). -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
On Mon, Dec 14, 2009 at 8:25 PM, Alexey Akimov <alexey.akimov85@gmail.com> wrote:
Hello to everyone,
I get confused trying to port my boost python extension module. So I've made a shared object file test.so which actually perfectly works in the original development directory. However, when I copy this file to another Linux machine (I also copy some extra libraries such as libboost_python-gcc344-1_39.so.1.39.0 and make sure that both .so files are in PATH and LD_LIBRARY_PATH) I recieve "Import Error: undefined symbol: /home/username/bin/libboost_python-gcc34-1_39.so.1.39.0: PyUnicodeUCS4_FromEncodedObject". I aslo istalled the same version (compared to one which was used for creation of the module) of Python to the Linux machine where I try to use my extension. Can anyone explain me where could the problem be.
In my opinion you compiled the module against Python version/build which is differ from the "run" environment.
Also I would clarify what is the general way to export just created modules? As I understand the order is following: 1) create .so object (look for it in /bin/compiler-name/release-or-debug/module-name.so directory) 2) copy this file as well as other necessary library to some /bin or /lib directory (for convenience) - and make sure they are in PATH and LD_LIBRARY_PATH variables.
You can use "ldd" command to find out dependencies. In the case, you have few interpreters it also can help you to see what python*.so will be actually used.
3) import the module in python interpreter.
Do I need to do something else (define some other variables or make some other changes) in order to make my module work?
In case you have few modules, sometimes you need to tweak "dlopen" flags. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/
participants (3)
-
Alexey Akimov -
Nikolaus Rath -
Roman Yakovenko