Why libpython2.7 symbols don't load even if linked?

Asked by JPi on 2016-04-17

We are trying to use python C api and although our library is compiled and linked against libpython2.7, when executing the program symbols from that library are not found.
We get errors like

error: pyexec: /usr/lib/python2.7/dist-packages/numpy/core/multiarray.so: undefined symbol: PyExc_SystemError

Very similar to the problem described here

https://bugs.kde.org/show_bug.cgi?id=330032

By adding LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 in our environment before running the program solves the issue but this is nto a solution, just a workaround.

The thing is that in Debian this doesn't happen (currently testing on Ubuntu vivid), but it also happens in Fedora
https://bitbucket.org/mtmiller/pytave/issues/3/dlopen-hack

Would you be able to give us a hint on how we could solve this for Ubuntu?

Thanks

Question information

Language:
English Edit question
Status:
Answered
For:
Ubuntu python2.7 Edit question
Assignee:
No assignee Edit question
Last query:
2016-04-18
Last reply:
2016-04-19
Manfred Hampl (m-hampl) said : #1

What is the output of the commands

uname -a
lsb_release -crid
grep libpython2.7 /etc/ld.so.cache
grep x86_64-linux-gnu /etc/ld.so.conf
ls -l /usr/lib/x86_64-linux-gnu/libpython2.7*

Remark:
Ubuntu vivid has entered end of life status two months ago, see https://wiki.ubuntu.com/Releases

JPi (ajuanpi) said : #2

Thanks for the answer. I updated today to Wily and I get the same error. Woudl you know how is libpython2.7 built in Ubuntu. Is --enable-shared passed as a flag for configure? How can one see the config.log of the distributed compiled libraries (if it is possible)?

Again, the problem is not present in Debian

The info you requested below

> uname -a

Linux AsusK55VJ-ubuntu 4.2.0-35-generic #40-Ubuntu SMP Tue Mar 15 22:15:45 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

> lsb_release -crid

Distributor ID: Ubuntu
Description: Ubuntu 15.10
Release: 15.10
Codename: wily

> grep libpython2.7 /etc/ld.so.cache

Binary file /etc/ld.so.cache matches

> grep x86_64-linux-gnu /etc/ld.so.conf

nothing

ls -l /usr/lib/x86_64-linux-gnu/libpython2.7*

JPi (ajuanpi) said : #3

The last command gives

> ls -l /usr/lib/x86_64-linux-gnu/libpython2.7*

lrwxrwxrwx 1 root root 51 Okt 14 2015 /usr/lib/x86_64-linux-gnu/libpython2.7.a -> ../python2.7/config-x86_64-linux-gnu/libpython2.7.a
lrwxrwxrwx 1 root root 19 Okt 14 2015 /usr/lib/x86_64-linux-gnu/libpython2.7_d.so -> libpython2.7_d.so.1
lrwxrwxrwx 1 root root 21 Okt 14 2015 /usr/lib/x86_64-linux-gnu/libpython2.7_d.so.1 -> libpython2.7_d.so.1.0
-rw-r--r-- 1 root root 6733568 Okt 14 2015 /usr/lib/x86_64-linux-gnu/libpython2.7_d.so.1.0
lrwxrwxrwx 1 root root 17 Okt 14 2015 /usr/lib/x86_64-linux-gnu/libpython2.7.so -> libpython2.7.so.1
lrwxrwxrwx 1 root root 19 Okt 14 2015 /usr/lib/x86_64-linux-gnu/libpython2.7.so.1 -> libpython2.7.so.1.0
-rw-r--r-- 1 root root 3574616 Okt 14 2015 /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0

JPi (ajuanpi) said : #4

And just to ratify that the library we build indeed is linked against libpython

ldd pyeval.oct | grep python
 libboost_python-py27.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.58.0 (0x00007f907b7ce000)
 libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007f907b254000)

Thanks

Manfred Hampl (m-hampl) said : #5

I suggest you create a bug report.

Can you help with this problem?

Provide an answer of your own, or ask JPi for more information if necessary.

To post a message you must log in.