2014-01-07 4 views
6

Bearbeiten: Ich habe versucht, fast jede Bibliothek in /usr/lib/girepository-1.0 bis vertreten vertreten und sie alle außer Gtk und Gdk funktionieren. Ich habe den Titel aktualisiert, um dies widerzuspiegeln.Warum segmentiert mein PyGObject selbstständig beim Import von Gtk oder Gdk?


Ich brauche eine selbst gebaute pygobject Bibliothek mit meinem selbst gebauten Python 3.3.3 zu gehen. Ich installierte alle Abhängigkeiten für PyGObject mit . Ich fand, dass die Version des Arbeitssystems PyGObject 3.2.2 war, also überprüfte ich Version 3.2.2 der Quelle vom Git Repo. Ich lief:

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

Alles kompiliert und installiert schön. Ich öffnete ein neues CMD und setzen Sie das Arbeitsverzeichnis ~, dann:

~$ 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) 
~$

Ich habe LD_LIBRARY_PATH-/home/tomas/.pyenv/versions/3.3.3/lib eingestellt und überprüft, dass die richtige Bibliothek geladen wird:

~$ 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)

ich importiert auch das Modul mit python -vv: Pastebin

den letzten Zeilen zeigt, dass der Core-Dump direkt nach dem Import gi.repository.Atk passiert:

Importieren nur gi.repository.Atk segfault nicht.

Ich habe auch versucht, die Systemversion der Bibliothek (sudo dpkg -P python3-gi) zu entfernen, falls es in irgendeiner Weise stören würde.


Ich weiß nicht, was ich sonst tun soll. Weiß jemand oder hat er eine Idee, was das Problem sein könnte? Bitte hinterlassen Sie einen Kommentar, wenn Sie eine Idee von etwas haben, was ich versuchen könnte oder wenn ich mehr Informationen zur Verfügung stellen kann.

+0

Können Sie einen StackTrace bekommen, wenn es passiert? – drahnr

+0

@drahnr: Ich kann [eine Stack-Trace aus dem Kern] drucken (http://pastebin.com/raw.php?i=19rETAKn), aber es ist nicht sehr hilfreich, ohne eine Symboltabelle. – Hubro

+0

Können Sie Python mit Debug-Symbolen neu kompilieren? Beachten Sie, ich bin mir nicht sicher, dass das hilft, aber ich denke, es ist ein Ausgangspunkt. Sie sollten auch auf der gtk-devel-Mailingliste posten - vielleicht haben einige der Kernentwickler/Introspect-Betreuer einen Hinweis. – drahnr

Antwort

5

PyGObject hat starke Voraussetzungen für Glib und Python.

Für was es wert ist, ich Batch-Build verschiedene Kombinationssätze, um die Arbeit zu finden.

Bitte beachten Sie, dass, wie Simon Feltman in einem Kommentar unten erläutert, pycairo keine strenge Abhängigkeit ist und möglicherweise mit der Konfigurationsoption --enable-cairo=no deaktiviert wird. Es erscheint nur hier, da ich diese Tests unter Verwendung der Standard Build-Optionen durchgeführt habe.

Hier sind die Ergebnisse auf meinem Debian Wheezy/Wheezy-updates 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) 

Viele Kombinationen einfach nicht bauen, weil sie auf meinem System eine neuere Version von GLib als verfügbar erfordern . In einigen Fällen erfordert das Skript setup.py python-2, daher ist der Installationsprozess in einer Python-3-Umgebung fehlgeschlagen. Ich brauchte nicht dauern, um zu verstehen, warum einige Kombinationen führen zu einem Segmentierungsfehler zur Laufzeit.

Wie Sie sehen können, ist Ihre beste Wette (mindestens heute auf Debian) zu bauen pycairo-1.10 + pygobject-3.2 + python 3.2. alles, was aktueller ist, erfordert mindestens eine neuere Version von GLib ...

+2

Beachten Sie, dass Pycairo keine strikte Abhängigkeit ist. Es ist für GUI-Code benötigt, der benutzerdefinierte Widget-Zeichnung mit Kairo durchführen muss. Dies kann mit dem configure-Flag "--enable-cairo = no" entfernt werden, und die meisten Distributionen teilen dies in ein separates Paket auf. In Bezug auf eine Python-Entwicklungsabhängigkeit ist es immerhin eine Python C-Erweiterung. Soweit PyGObject "pedantisch" ist, ist das tatsächlich ein nützliches Feedback für mich als Betreuer! –

+1

Danke Simon für deinen Kommentar ... und deine Zeit als Betreuer für PyGObject;) Vielleicht ist das Wort "pedantisch" im Englischen negativer, als ich dachte? Wie auch immer, nimm meine Worte nicht falsch: Ich war größtenteils enttäuscht, dass ich keine neuere Version als 3.2 auf meiner Debian-Box verwenden konnte. Alle obigen Ergebnisse verwenden die Standard-Build-Optionen. Um ehrlich zu sein, als ich mich mit dem gleichen Problem ("Segmentierungsfehler") wie der OP abmühte, habe ich nur diese paar "schnellen und schmutzigen" Builds als Test durchgeführt ... ohne die verschiedenen Konfigurationsoptionen zu erkunden ! Schande über mich ... –

+0

@SimonFeltman Ich habe die ersten paar Absätze der Antwort umformuliert, um Ihren Kommentar zu berücksichtigen. Zögern Sie nicht, lassen Sie es mich wissen, wenn Sie denken, dass diese Antwort noch einige Probleme hat. –

Verwandte Themen