nautilus-python fails to load on 32- and 64-bit systems: g_module_open libpython failed: No such file or directory

Bug #1170017 reported by Adam Dingle on 2013-04-17
170
This bug affects 46 people
Affects Status Importance Assigned to Milestone
RabbitVCS
Unknown
Unknown
nautilus-compare
Undecided
Unassigned
nautilus-python
New
Medium
nautilus-python (Debian)
Fix Released
Unknown
nautilus-python (Ubuntu)
Undecided
Barry Warsaw
Raring
Undecided
Unassigned
python-caja (Ubuntu)
Undecided
Unassigned
Raring
Undecided
Unassigned

Bug Description

I'm running Ubuntu 13.04 (Raring). To see the problem, do these steps on a 64-bit system:

1. Install the python-nautilus package.
2. Install any extension that uses nautilus-python, e.g. the rabbitvcs-nautilus package.
3. From a terminal window, run 'nautilus -q' to exit Nautilus, then run 'nautilus' to start it again.

You'll see this:

(nautilus:3810): Nautilus-Python-WARNING **: g_module_open libpython failed: /usr/lib/libpython2.7.so.1.0: cannot open shared object file: No such file or directory
ImportError: could not import gobject (error was: '/usr/lib/x86_64-linux-gnu/libpyglib-gi-2.0-python2.7.so.0: undefined symbol: _Py_ZeroStruct')

(nautilus:3810): Nautilus-Python-WARNING **: pygobject initialization failed

And of course then the extension will not work.

The problem is that nautilus-python is looking for libpython2.7.so in /usr/lib, but on this system it lives in /usr/lib/x86_64-linux-gnu/. The nautilus-python sources have a macro in m4/python.m4 which attempts to detect a 64-bit library directory at build time, but it fails on Ubuntu because it only recognizes such directories if their names end in "lib64".

Adam Dingle (adam-yorba) wrote :

When building from source, you can work around this by configuring like this:

$ ./configure PYTHON_LIB_LOC=/usr/lib/x86_64-linux-gnu

Changed in nautilus-python:
importance: Unknown → Medium
status: Unknown → New
gervin23 (gervin23) wrote :

confirmed here on 64bit machine in 13.04

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nautilus-python (Ubuntu):
status: New → Confirmed
Hồng Quân (ng-hong-quan) wrote :

To workaround, make symbolic link /usr/lib/libpython2.7.so.1.0 pointing to /usr/lib/x86_64-linux-gnu/libpython2.7.so

Doug McMahon (mc3man) wrote :

Don't have a 32 bit install but would it not also be affected as filelist for libpython2.7 shows -
/usr/lib/i386-linux-gnu/libpython2.7.so.1.0

Dr. Amr Osman (dr3mro) wrote :

Description: allows nautilus-python to work in 13.04 amd64 but I know nothing about m4's
this is a working patch i have got from a friend online
not my patch
it solves the issue
i have made a deb on ppa:nae-team/ppa
https://launchpad.net/~nae-team/+archive/ppa

The attachment "m4-test.diff" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Doug McMahon (mc3man) wrote :

Went ahead & did a 32 bit 13.04 install & like I previously mentioned it is also affected in same manner.
In this case no clue as the python.m4 says if not amd64 it will use the default of /lib, where that is set no idea
(doesn't seem to be in python.m4, maybe in lib-prefix.m4??

In any event for amd64 it is fixed either with a symlink, a DEB_CONFIGURE_EXTRA_FLAGS for local amd64 build or the .m4 patch

Really needs to be properly fixed though interest in seems quite low

Barry Warsaw (barry) wrote :

I've adapted the patch in comment #6 by Dr. Amr Osman (dr3mro). Built and tested locally on saucy and it seemed to work for me, so I uploaded it. Thanks!

Changed in nautilus-python (Ubuntu):
assignee: nobody → Barry Warsaw (barry)
status: Confirmed → In Progress

On 05/28/2013 04:38 PM, Barry Warsaw wrote:
> I've adapted the patch in comment #6 by Dr. Amr Osman (dr3mro). Built
> and tested locally on saucy and it seemed to work for me, so I uploaded
> it. Thanks!
>
> ** Changed in: nautilus-python (Ubuntu)
> Assignee: (unassigned) => Barry Warsaw (barry)
>
> ** Changed in: nautilus-python (Ubuntu)
> Status: Confirmed => In Progress
>
Did you test it on an i386 install?

I tried your diff on i386 - no go as seen during build -
-DPYTHON_VERSION=\"2.7\" -DPY_LIB_LOC="\"/usr/lib\"" -I/usr/include/python2.7 -I/usr/include/i386-linux-gnu/python2.7

so I modified my orig. patch to work on both i386 & amd_64, though as mentioned know nothing about m4 & such - just some logical T&E
attaching

Doug McMahon (mc3man) wrote :

More in line with how Barry did though still separate patch

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nautilus-python - 1.1-3ubuntu2

---------------
nautilus-python (1.1-3ubuntu2) saucy; urgency=low

  [ Dr.Amr Osman ]
  * debian/patches/02_python_multiarch_path.patch: Add 64bit multiarch
    search paths for libpython2.7.so. (LP: #1170017)
 -- Barry Warsaw <email address hidden> Tue, 28 May 2013 16:26:27 -0400

Changed in nautilus-python (Ubuntu):
status: In Progress → Fix Released
Doug McMahon (mc3man) wrote :
Barry Warsaw (barry) wrote :

Thanks Doug. I've applied your patch and uploaded to 1.1-3ubuntu3. Tested on both amd64 and i386.

When will the fix be released for raring?

Luke Faraone (lfaraone) on 2013-07-10
Changed in nautilus-python (Ubuntu Raring):
status: New → Triaged
Doug McMahon (mc3man) wrote :

Until such time that this is fixed in 13.04 I left a testing ppa up with raring packages
(basically the same as the saucy fix except done as an additional patch
https://launchpad.net/~mc3man/+archive/n-p-testfix

Changed in nautilus-python (Debian):
status: Unknown → Fix Released
Norbert (nrbrtx) wrote :

This bug exists in Ubuntu 12.04.5 too.
I was trying to port TortoiseHG to Caja (see https://bitbucket.org/nrbrtx/caja-thg) and got a problem in Ubuntu 12.04.

After adding MATE PPAs and installing caja-python and my script I have the following error on Caja start:

     (caja:13871): Caja-Python-WARNING **: g_module_open libpython failed: /usr/lib/i386-linux-gnu//libpython2.7.so.1.0: cannot open shared object file: No such file or directory
     ImportError: could not import gobject (error was: '/usr/lib/libpyglib-gi-2.0-python2.7.so.0: undefined symbol: _Py_ZeroStruct')
     Error in sys.excepthook:
     Traceback (most recent call last):
       File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 66, in apport_excepthook
         from apport.fileutils import likely_packaged, get_recent_crashes
       File "/usr/lib/python2.7/dist-packages/apport/__init__.py", line 1, in <module>
         from apport.report import Report
       File "/usr/lib/python2.7/dist-packages/apport/report.py", line 16, in <module>
         from xml.parsers.expat import ExpatError
       File "/usr/lib/python2.7/xml/parsers/expat.py", line 4, in <module>
         from pyexpat import *
     ImportError: /usr/lib/python2.7/lib-dynload/pyexpat.so: undefined symbol: _Py_ZeroStruct

     Original exception was:
     ImportError: could not import gobject (error was: '/usr/lib/libpyglib-gi-2.0-python2.7.so.0: undefined symbol: _Py_ZeroStruct')

     (caja:13871): Caja-Python-WARNING **: pygobject initialization failed

     (caja:13871): Caja-Python-WARNING **: caja_python_init_python failed

As a temporary solution I made a symlink:
   sudo ln -s /usr/lib/libpython2.7.so.1.0 /usr/lib/i386-linux-gnu/libpython2.7.so.1.0

After that TortoiseHG Caja extension works on Ubuntu 12.04 as expected.

Please fix this bug on Ubuntu or MATE PPA side.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in python-caja (Ubuntu Raring):
status: New → Confirmed
Changed in python-caja (Ubuntu):
status: New → Confirmed
Norbert (nrbrtx) wrote :

I subscribed Ubuntu MATE developers to inform them about the problem.

Mike Gabriel (sunweaver) wrote :

I just tested this issue in Debian. The problem does not exist with python-caja 1.8.0-1 in Debian unstable (and neither with the follow-up version 1.8.1-1, about to upload).

Mike (aka sunweaver)

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package python-caja - 1.8.1-1

---------------
python-caja (1.8.1-1) unstable; urgency=medium

  [ Vangelis Mouhtsis ]
  * debian/rules:
    + Replace on dh_install --list-missing -> --fail-missing
  * debian/control:
    + Bump Standards: to 3.9.6. No changes needed.

  [ Mike Gabriel ]
  * New upstream release.
    - Detect Python variables via pkg-config. (LP: #1170017).
  * debian/patches:
    + Add 1001_multi-arch-libdir-in-pkgconfig.patch. Put multi-arch linker
      path in caja-python.pc.
  * debian/rules:
    + Provide an empty caja-python/extensions folder (with .placeholder file).

 -- Mike Gabriel <email address hidden> Fri, 24 Oct 2014 22:30:57 +0200

Changed in python-caja (Ubuntu):
status: Confirmed → Fix Released
Norbert (nrbrtx) wrote :

Bug still affects caja-python and/or gir1.2-caja packages.
Here are the contents of .xsession-errors:

(caja:5096): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.40.2/./gobject/gsignal.c:2580: instance '0x9135d30' has no handler with id '5503'

(caja:5096): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.40.2/./gobject/gsignal.c:2580: instance '0x93a9f90' has no handler with id '5741'

(caja:5096): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.40.2/./gobject/gsignal.c:2580: instance '0x9193730' has no handler with id '5748'

(caja:5096): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.40.2/./gobject/gsignal.c:2580: instance '0x937a100' has no handler with id '5755'

(caja:5096): GLib-CRITICAL **: Source ID 593 was not found when attempting to remove it

(caja:5096): GLib-CRITICAL **: Source ID 594 was not found when attempting to remove it

(caja:5096): GLib-CRITICAL **: Source ID 595 was not found when attempting to remove it

(caja:5096): Eel-WARNING **: "unique eel_ref_str" hash table still has 4 elements at quit time (keys above)

(caja:5096): Eel-WARNING **: "caja-directory.c: directories" hash table still has 5 elements at quit time
** Message: Initializing gksu extension...

(caja:5714): Caja-Python-WARNING **: g_module_open libpython failed: /usr/lib/libpython2.7.so.1.0: cannot open shared object file: No such file or directory
ImportError: could not import gobject (error was: '/usr/lib/python2.7/dist-packages/gi/_gi.so: undefined symbol: _Py_ZeroStruct')
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 63, in apport_excepthook
    from apport.fileutils import likely_packaged, get_recent_crashes
  File "/usr/lib/python2.7/dist-packages/apport/__init__.py", line 5, in <module>
    from apport.report import Report
  File "/usr/lib/python2.7/dist-packages/apport/report.py", line 16, in <module>
    from xml.parsers.expat import ExpatError
  File "/usr/lib/python2.7/xml/parsers/expat.py", line 4, in <module>
    from pyexpat import *
ImportError: /usr/lib/python2.7/lib-dynload/pyexpat.i386-linux-gnu.so: undefined symbol: _Py_ZeroStruct

Original exception was:
ImportError: could not import gobject (error was: '/usr/lib/python2.7/dist-packages/gi/_gi.so: undefined symbol: _Py_ZeroStruct')

(caja:5714): Caja-Python-WARNING **: pygobject initialization failed

(caja:5714): Caja-Python-WARNING **: caja_python_init_python failed

It is produced on Caja start.
Please fix this bug, it makes Caja Python extensions unusable (for example Caja TortoiseHG [https://bitbucket.org/nrbrtx/caja-thg] extension does not work).

tags: added: apport-collected third-party-packages trusty

ApportVersion: 2.14.1-0ubuntu3.5
Architecture: i386
CasperVersion: 1.340
DistroRelease: Ubuntu 14.04
LiveMediaBuild: Ubuntu MATE 14.04.1 "Trusty Tahr" - final i386 (20141111)
Package: python-caja 1.8.1-1~trusty1 [origin: LP-PPA-ubuntu-mate-dev-trusty-mate]
PackageArchitecture: i386
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.13.0-39.66-generic 3.13.11.8
Tags: third-party-packages trusty
Uname: Linux 3.13.0-39-generic i686
UnreportableReason: This is not an official Ubuntu package. Please remove any third party package and try again.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True

apport information

summary: - nautilus-python fails to load on 64-bit systems: g_module_open libpython
- failed: No such file or directory
+ nautilus-python fails to load on 32- and 64-bit systems: g_module_open
+ libpython failed: No such file or directory
Rolf Leggewie (r0lf) wrote :

raring has seen the end of its life and is no longer receiving any updates. Marking the raring task for this ticket as "Won't Fix".

Changed in nautilus-python (Ubuntu Raring):
status: Triaged → Won't Fix
Rolf Leggewie (r0lf) on 2014-12-05
Changed in python-caja (Ubuntu Raring):
status: Confirmed → Won't Fix
Märt Põder (boamaod) on 2015-07-14
Changed in nautilus-compare:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.