Why is my self-tuning PyGObject segfault when importing Gtk or Gdk?

Change I tried to import almost every library provided in /usr/lib/girepository-1.0 via gi.repository and all of them work except for Gtk and Gdk. I updated the name to reflect this.


I need the PyGObject built-in library for my built-in Python 3.3.3. I installed all the dependencies for PyGObject using sudo apt-get build-dep python3-gi . I found that the PyGObject version of the working system was 3.2.2, so I checked the source version 3.2.2 from the Git repository. I ran:

  autoreconf --force --install
 ./configure --prefix = / home / tomas / .pyenv / versions / 3.3.3
 make
 make install 

Everything is compiled and installed beautifully. I opened a new CMD and set the working directory ~ , and then:

  ~ $ python
 Python 3.3.3 (default, Dec 21 2013, 23:12:28) 
 [GCC 4.6.3] on linux
 Type "help", "copyright", "credits" or "license" for more information.
 >>> from gi.repository import Gtk
 Segmentation fault (core dumped)
 ~ $ 

I set LD_LIBRARY_PATH in /home/tomas/.pyenv/versions/3.3.3/lib and found that the correct library is loading:

  ~ $ ldd .pyenv / versions / 3.3.3 / lib / python3.3 / site-packages / gi / _gi.so
     linux-vdso.so.1 => (0x00007fffcdf51000)
     libgirepository-1.0.so.1 => /usr/lib/libgirepository-1.0.so.1 (0x00007f45d8304000)
     libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f45d80b5000)
     libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f45d7dbf000)
     libpyglib-gi-2.0-python.so.0 => /home/tomas/.pyenv/versions/3.3.3/lib/libpyglib-gi-2.0-python.so.0 (0x00007f45d7bba000)
     libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f45d799d000)
     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f45d75dc000)
     libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f45d72e0000)
     libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f45d70dc000)
     libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f45d6d8c000)
     libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f45d6b84000)
     libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f45d6947000)
     librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f45d673e000)
     /lib64/ld-linux-x86-64.so.2 (0x00007f45d877b000)
     libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f45d653a000)
     libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f45d6323000)
     libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f45d6103000)
     libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f45d5ee7000) 

I also imported the module with python -vv : Pastebin

The last few lines show that the main dump occurs immediately after importing gi.repository.Atk :

  # trying /home/tomas/.pyenv/versions/3.3.3/lib/python3.3/site-packages/gi/repository/Atk.cpython-33m.so
 # trying /home/tomas/.pyenv/versions/3.3.3/lib/python3.3/site-packages/gi/repository/Atk.abi3.so
 # trying /home/tomas/.pyenv/versions/3.3.3/lib/python3.3/site-packages/gi/repository/Atk.so
 # trying /home/tomas/.pyenv/versions/3.3.3/lib/python3.3/site-packages/gi/repository/Atk.py
 # trying /home/tomas/.pyenv/versions/3.3.3/lib/python3.3/site-packages/gi/repository/Atk.pyc
 # trying /home/tomas/.pyenv/versions/3.3.3/lib/python3.3/site-packages/gi/overrides/Atk.cpython-33m.so
 # trying /home/tomas/.pyenv/versions/3.3.3/lib/python3.3/site-packages/gi/overrides/Atk.abi3.so
 # trying /home/tomas/.pyenv/versions/3.3.3/lib/python3.3/site-packages/gi/overrides/Atk.so
 # trying /home/tomas/.pyenv/versions/3.3.3/lib/python3.3/site-packages/gi/overrides/Atk.py
 # trying /home/tomas/.pyenv/versions/3.3.3/lib/python3.3/site-packages/gi/overrides/Atk.pyc
 import 'gi.repository.Atk' # 
 Segmentation fault (core dumped) 

Importing only gi.repository.Atk not segfault.

I also tried uninstalling the system version of the library ( sudo dpkg -P python3-gi ) if it somehow interferes.


I do not know what else to do. Does anyone know or have an idea of ​​what might be the problem? Please leave a comment if you have an idea about something that I could try, or if I can provide more information.

+6
source share
1 answer

PyGObject has strong background on Glib and Python.

For what it's worth, I collect several sets of combinations to find workers.

Note that, as Simon Feltman explained in the comment below, pycairo is not a strict dependency and can be disabled using the --enable-cairo=no configure parameter. It only appears here when I performed these tests using standard build options.

Here are the results of my Debian Wheezy / Wheezy-backports system (GLib 2.33):

 python pygobject pycairo compile ... import Gtk 3.1 3.0 1.0 NO (pycairo) 3.1 3.0 1.10 YES OK 3.1 3.0 1.2 NO (pycairo) 3.1 3.0 1.4 NO (pycairo) 3.1 3.0 1.6 NO (pycairo) 3.1 3.0 1.8 NO (pycairo) 3.1 3.2 1.0 NO (pycairo) 3.1 3.2 1.10 YES OK 3.1 3.2 1.2 NO (pycairo) 3.1 3.2 1.4 NO (pycairo) 3.1 3.2 1.6 NO (pycairo) 3.1 3.2 1.8 NO (pycairo) 3.1 3.4 1.0 NO (pycairo) 3.1 3.4 1.10 NO (pygobject) 3.1 3.4 1.2 NO (pycairo) 3.1 3.4 1.4 NO (pycairo) 3.1 3.4 1.6 NO (pycairo) 3.1 3.4 1.8 NO (pycairo) 3.1 3.6 1.0 NO (pycairo) 3.1 3.6 1.10 NO (pycairo) 3.1 3.6 1.2 NO (pycairo) 3.1 3.6 1.4 NO (pycairo) 3.1 3.6 1.6 NO (pycairo) 3.1 3.6 1.8 NO (pycairo) 3.1 3.8 1.0 NO (pycairo) 3.1 3.8 1.10 NO (pygobject) 3.1 3.8 1.2 NO (pycairo) 3.1 3.8 1.4 NO (pycairo) 3.1 3.8 1.6 NO (pycairo) 3.1 3.8 1.8 NO (pycairo) 3.2 3.0 1.0 NO (pycairo) 3.2 3.0 1.10 YES OK 3.2 3.0 1.2 NO (pycairo) 3.2 3.0 1.4 NO (pycairo) 3.2 3.0 1.6 NO (pycairo) 3.2 3.0 1.8 NO (pycairo) 3.2 3.2 1.0 NO (pycairo) 3.2 3.2 1.10 YES OK 3.2 3.2 1.2 NO (pycairo) 3.2 3.2 1.4 NO (pycairo) 3.2 3.2 1.6 NO (pycairo) 3.2 3.2 1.8 NO (pycairo) 3.2 3.4 1.0 NO (pycairo) 3.2 3.4 1.10 NO (pygobject) 3.2 3.4 1.2 NO (pycairo) 3.2 3.4 1.4 NO (pycairo) 3.2 3.4 1.6 NO (pycairo) 3.2 3.4 1.8 NO (pycairo) 3.2 3.6 1.0 NO (pycairo) 3.2 3.6 1.10 NO (pycairo) 3.2 3.6 1.2 NO (pycairo) 3.2 3.6 1.4 NO (pycairo) 3.2 3.6 1.6 NO (pycairo) 3.2 3.6 1.8 NO (pycairo) 3.2 3.8 1.0 NO (pycairo) 3.2 3.8 1.10 NO (pygobject) 3.2 3.8 1.2 NO (pycairo) 3.2 3.8 1.4 NO (pycairo) 3.2 3.8 1.6 NO (pycairo) 3.2 3.8 1.8 NO (pycairo) 3.3 3.0 1.0 NO (pycairo) 3.3 3.0 1.10 YES SEGMENTATION FAULT 3.3 3.0 1.2 NO (pycairo) 3.3 3.0 1.4 NO (pycairo) 3.3 3.0 1.6 NO (pycairo) 3.3 3.0 1.8 NO (pycairo) 3.3 3.2 1.0 NO (pycairo) 3.3 3.2 1.10 YES SEGMENTATION FAULT 3.3 3.2 1.2 NO (pycairo) 3.3 3.2 1.4 NO (pycairo) 3.3 3.2 1.6 NO (pycairo) 3.3 3.2 1.8 NO (pycairo) 3.3 3.4 1.0 NO (pycairo) 3.3 3.4 1.10 NO (pygobject) 3.3 3.4 1.2 NO (pycairo) 3.3 3.4 1.4 NO (pycairo) 3.3 3.4 1.6 NO (pycairo) 3.3 3.4 1.8 NO (pycairo) 3.3 3.6 1.0 NO (pycairo) 3.3 3.6 1.10 NO (pycairo) 3.3 3.6 1.2 NO (pycairo) 3.3 3.6 1.4 NO (pycairo) 3.3 3.6 1.6 NO (pycairo) 3.3 3.6 1.8 NO (pycairo) 3.3 3.8 1.0 NO (pycairo) 3.3 3.8 1.10 NO (pygobject) 3.3 3.8 1.2 NO (pycairo) 3.3 3.8 1.4 NO (pycairo) 3.3 3.8 1.6 NO (pycairo) 3.3 3.8 1.8 NO (pycairo) 

Many combinations simply will not be created because they require a newer version of GLib than is available on my system. In some cases, setup.py script requires python-2, so the installation process failed in a python-3-only environment. It didn't take me a while to figure out why some combinations cause a segmentation error at runtime.

As you can see, your best bet (at least today on Debian) is to create pycairo-1.10 + pygobject-3.2 + python 3.2. something more modern will require at least a later version of GLib ...

+5
source

All Articles