#61699 closed defect (fixed)
gdk-pixbuf2 @2.42.0 breaks py-gobject3
Reported by: | fhgwright (Fred Wright) | Owned by: | dbevans (David B. Evans) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.6.4 |
Keywords: | Cc: | michaelld (Michael Dickens) | |
Port: | gdk-pixbuf2 |
Description
There's some kind of a path screwup related to libgdk_pixbuf-2.0.0.dylib
in the new gdk-pixbuf2
, resulting in import failures from py-jobject3
. This can be demonstrated as follows:
With the previous version:
MacPro:~ fw$ port installed gdk-pixbuf2 | grep active gdk-pixbuf2 @2.40.0_1+x11 (active) MacPro:~ fw$ python -c 'import gi; from gi.repository import Gtk' -c:1: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
(the warning is harmless for this purpose, and the gi.require_version
call is omitted for simplicity)
With the new version:
MacPro:~ fw$ port installed gdk-pixbuf2 | grep active gdk-pixbuf2 @2.42.0_0+x11 (active) MacPro:~ fw$ python -c 'import gi; from gi.repository import Gtk' ** (process:1685): WARNING **: 19:59:36.238: Failed to load shared library 'libgdk_pixbuf-2.0.0.dylib' referenced by the typelib: dlopen(libgdk_pixbuf-2.0.0.dylib, 9): image not found Traceback (most recent call last): File "<string>", line 1, in <module> File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gi/importer.py", line 145, in load_module importlib.import_module('gi.repository.' + dep.split("-")[0]) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py", line 37, in import_module __import__(name) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gi/importer.py", line 145, in load_module importlib.import_module('gi.repository.' + dep.split("-")[0]) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py", line 37, in import_module __import__(name) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gi/importer.py", line 146, in load_module dynamic_module = load_overrides(introspection_module) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gi/overrides/__init__.py", line 118, in load_overrides override_mod = importlib.import_module(override_package_name) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py", line 37, in import_module __import__(name) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gi/overrides/GdkPixbuf.py", line 32, in <module> class Pixbuf(GdkPixbuf.Pixbuf): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gi/overrides/__init__.py", line 195, in override assert g_type != TYPE_NONE AssertionError
The exact error messages vary with the Python version, but the effect is the same.
Some poking around with dtruss
indicates that the problem is that it's trying to load libgdk_pixbuf-2.0.0.dylib
instead of /opt/local/lib/libgdk_pixbuf-2.0.0.dylib
. In fact, it works if one is currently in the /opt/local/lib
directory:
MacPro:~ fw$ cd /opt/local/lib MacPro:lib fw$ port installed gdk-pixbuf2 | grep active gdk-pixbuf2 @2.42.0_0+x11 (active) MacPro:lib fw$ python -c 'import gi; from gi.repository import Gtk' -c:1: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
This does not seem to be a simple install-name issue:
MacPro:~ fw$ otool -L /opt/local/lib/libgdk_pixbuf-2.0.0.dylib /opt/local/lib/libgdk_pixbuf-2.0.0.dylib: /opt/local/lib/libgdk_pixbuf-2.0.0.dylib (compatibility version 4201.0.0, current version 4201.0.0) /opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.5.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) /opt/local/lib/libglib-2.0.0.dylib (compatibility version 5801.0.0, current version 5801.3.0) /opt/local/lib/libgobject-2.0.0.dylib (compatibility version 5801.0.0, current version 5801.3.0) /opt/local/lib/libgmodule-2.0.0.dylib (compatibility version 5801.0.0, current version 5801.3.0) /opt/local/lib/libgio-2.0.0.dylib (compatibility version 5801.0.0, current version 5801.3.0)
This is all from 10.9.5, but the same symptom is present in 10.13.6 (and probably others).
Change History (20)
comment:1 Changed 4 years ago by kencu (Ken)
comment:2 Changed 4 years ago by mf2k (Frank Schima)
Cc: | dbevans removed |
---|---|
Owner: | set to dbevans |
Status: | new → assigned |
comment:3 Changed 4 years ago by michaelld (Michael Dickens)
I just pushed the current round of fixes to GO-I ... please update your ports & reinstall gdk-pixbuf2
and see if it works. Hopefully so!
comment:4 Changed 4 years ago by michaelld (Michael Dickens)
Cc: | michaelld added |
---|
comment:5 follow-ups: 8 10 Changed 4 years ago by fhgwright (Fred Wright)
Yes, that fixes it, but it required rebuilding gdk-pixbuf2. Specifically:
Reactivating the installed gdk-pixbuf2 @2.42.0 didn't work.
Reinstalling gdk-pixbuf2 @2.42.0 from the binary archive didn't work.
Rebuilding gdk-pixbuf2 @2.42.0 from source did work.
So I guess gdk-pixbuf2 needs a revbump. Perhaps other dependents as well.
comment:6 Changed 4 years ago by michaelld (Michael Dickens)
Thanks for the confirmation that the changes work. Yes, we need to rev-bump all GO-I dependent ports, to make sure the changes propagate correctly. Haven't had (taken) time to do that yet.
comment:7 Changed 4 years ago by fhgwright (Fred Wright)
It would make sense to prioritize ports that have been updated since the GO-I breakage, since all installs and upgrades would have been impacted. The others would still need revbumping to cover installs from source.
comment:8 follow-up: 9 Changed 4 years ago by ra1nb0w
Replying to fhgwright:
Yes, that fixes it, but it required rebuilding gdk-pixbuf2. Specifically:
You can simply force the rebuild
sudo port -sn upgrade --force gobject-introspection gdk-pixbuf2
Anyway, go-i* requires rev-dump to avoid other similar ticket.
comment:9 Changed 4 years ago by fhgwright (Fred Wright)
Replying to ra1nb0w:
Replying to fhgwright:
Yes, that fixes it, but it required rebuilding gdk-pixbuf2. Specifically:
You can simply force the rebuild
sudo port -sn upgrade --force gobject-introspection gdk-pixbuf2
Actually, just:
sudo port -sn upgrade --force gdk-pixbuf2
Since gobject-introspection
was already revbumped. And already done as noted above.
Anyway, go-i* requires rev-dump to avoid other similar ticket.
Not go-i* itself (which was already revbumped with the fix), but its dependents. This ticket can be closed as soon as gdk-pixbuf2
is revbumped, but it's probably not the only failure.
comment:10 Changed 4 years ago by fhgwright (Fred Wright)
Replying to fhgwright:
Yes, that fixes it, but it required rebuilding gdk-pixbuf2.
It seems that I posted too soon. It's still failing (same symptom) on 10.10, 10.11, and 10.13. I haven't tested it on 10.14+, and 10.4-10.5 have other issues. It does work on 10.6-10.9 and 10.12.
comment:11 follow-up: 12 Changed 4 years ago by Bachsau (Bachsau)
I've been following all the instructions in this thread and still get the error on macOS 10.14.6 when trying to launch a PyGObject based application I wrote. I'm using the quartz variant btw.
** (__main__.py:49979): WARNING **: 22:59:34.817: Failed to load shared library 'libatk-1.0.0.dylib' referenced by the typelib: dlopen(libatk-1.0.0.dylib, 9): image not found Traceback (most recent call last): File "/Users/Sven/Cloud/Projekte/Mixtool/Application/src/__main__.py", line 49, in <module> from gi.repository import GLib, GObject, Gio, Pango, GdkPixbuf, Gdk, Gtk File "<frozen importlib._bootstrap>", line 983, in _find_and_load File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 668, in _load_unlocked File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible File "/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/gi/importer.py", line 145, in load_module dynamic_module = load_overrides(introspection_module) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/gi/overrides/__init__.py", line 118, in load_overrides override_mod = importlib.import_module(override_package_name) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/gi/overrides/Gtk.py", line 131, in <module> class Widget(Gtk.Widget): File "/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/gi/module.py", line 168, in __getattr__ interfaces = tuple(interface for interface in get_interfaces_for_object(info) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/gi/module.py", line 94, in get_interfaces_for_object interfaces.append(getattr(module, name)) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/gi/module.py", line 207, in __getattr__ wrapper = metaclass(name, bases, dict_) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/gi/types.py", line 247, in __init__ register_interface_info(cls.__info__.get_g_type()) TypeError: must be an interface}}}
comment:12 Changed 4 years ago by fhgwright (Fred Wright)
Replying to Bachsau:
I've been following all the instructions in this thread and still get the error on macOS 10.14.6 when trying to launch a PyGObject based application I wrote. I'm using the quartz variant btw.
** (__main__.py:49979): WARNING **: 22:59:34.817: Failed to load shared library 'libatk-1.0.0.dylib' referenced by the typelib: dlopen(libatk-1.0.0.dylib, 9): image not found
[...]
Since the load failure here is for libatk
rather than libgdk_pixbuf2
, it may not be the same bug. Or even if it's the same underlying bug in gobject-introspection
, it might still require a different workaround.
comment:13 Changed 4 years ago by fhgwright (Fred Wright)
I can now confirm that it fails on 10.14 and 10.15, though I was able to work around it by rolling back gdk-pixbuf2
to 2.40.0_1
and atk
to 2.36.0_0
(which was possible since I still had the old installs). It looks like atk
was just updated recently. I haven't retested earlier OS versions since the atk
update.
comment:14 Changed 4 years ago by michaelld (Michael Dickens)
I have no issues with my 10.15 or 11.X installs, but then I wrote the fixes & know how to confirm them ... you can get an idea of which need to be rebuild from source via:
grep "shared-library" /opt/local/share/gir-1.0/*.gir | grep -v /opt/local/lib
and then look at the filename of the .gir
file. For Fred's issues, it looks like as he notes gdk-pixbuf2
and atk
need to be rebuilt, after gobject-introspection
. If these are built from source in the correct order with GO-I first & the ports are up to date, then the GIR files should be valid.
comment:15 Changed 4 years ago by fhgwright (Fred Wright)
It looks like it indeed works if all three are rebuilt with gobject-introspection
first. But I thought that gobject-introspection
had already been revbumped after the fix, making explicitly rebuilding it unnecessary. Apparently that's not the case, which is why new broken dependents (such as the new atk
) are still being created.
This is for up through 10.13; I can't test 10.14 or 10.15 right now.
comment:16 Changed 4 years ago by fhgwright (Fred Wright)
I've now tested 10.14 and 10.15 as well, with the same result - the problem can be fixed by rebuilding, but only if gobject-introspection
is rebuilt before atk
and gdk-pixbuf2
. And (for unrelated reasons) I needed to do a full reinstall of MacPorts in my 10.13 VM, which still had the bug until I rebuilt these three ports from source. That indicates that the latest binary archives are still broken. Either:
1) gobject-introspection
was fixed without a revbump.
or
2) One of its build dependencies was modified (with the effect of fixing the bug) without its getting revbumped.
comment:17 Changed 4 years ago by nortcele
I had a similar problem with a gtk3 application that did not display images correctly under 10.10.5, 10.13.6 and 10.14.6 (with a fresh install of all dependancies). The error is:
*** Could not locate symbol gdk_pixbuf_loader_new at /opt/local/lib/perl5/vendor_perl/5.28/AMC/Gui/Zooms.pm line 268.
After forcing a reinstall with sudo port -sn upgrade --force gobject-introspection atk gdk-pixbuf2
everything is back in order.
comment:18 Changed 4 years ago by fhgwright (Fred Wright)
Just to reiterate: gobject-introspection
is still in need of a revbump, because dependents built against its latest binary archive are broken. In addition, both gdk-pixbuf2
and atk
need revbumps to pick this up, as well as probably many others. But revbumping those three would be a good start. I guess if nothing happens soon, I could submit a PR myself.
comment:19 Changed 4 years ago by michaelld (Michael Dickens)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:20 Changed 4 years ago by michaelld (Michael Dickens)
I rev-bumped some of these ports to fix this issue. It might not get every single last one, but it gets critical ones with other tickets open. Not all GO-I dependent ports require a rev-bump; let's do those as needed moving forward ... might not be any more than I just did, who knows?
There are a couple of open tickets and two open PRs about gobject-introspection being broken. I believe that is what is causing these errors.
We really should stop updating and revbumping anything that uses gobject-introspection until this gets fixed, because many things that use it appear to be broken, and it's just getting worse as we build more.
Your best bet I think, if you still have any around, would be to roll back to a gobject-introspection from about a month ago or so, until this gets straightened out.