GNOME Bugzilla – Bug 745957
GTK+/Quartz >= 3.14.8: Symbol not found: _gtk_drag_cancel (MyPaint 1.1.1-alpha)
Last modified: 2015-06-02 04:28:57 UTC
Attempting to launch MyPaint 1.1.1-alpha with GTK+/Quartz >= 3.14.8 installed fails with these console messages: $ mypaint CRITICAL: mypaint: We are not correctly installed or compiled! CRITICAL: mypaint: script: '/Volumes/mp-trunk/quartz/bin/mypaint' CRITICAL: mypaint: deduced prefix: u'/Volumes/mp-trunk/quartz' CRITICAL: mypaint: lib_shared: u'/Volumes/mp-trunk/quartz/share/mypaint' CRITICAL: mypaint: lib_compiled: u'/Volumes/mp-trunk/quartz/lib/mypaint' Traceback (most recent call last):
+ Trace 234827
= get_paths()
from lib import mypaintlib
_mypaintlib = swig_import_helper()
import _mypaintlib
Referenced from: /Volumes/mp-trunk/quartz/lib/libgtk-3.0.dylib Expected in: flat namespace in /Volumes/mp-trunk/quartz/lib/libgtk-3.0.dylib $ The launch failure does not occur - after downgrading GTK+/Quartz to 3.14.7 - if MyPaint 1.1.1-alpha was compiled with GTK+/X11 3.14 I'm not sure where the error message actually originates from - AFAICT (I'm not a developer myself) the symbol '_gtk_drag_cancel' is not exported by libgtk-3.0.dylib with Quartz backend, but is present if GTK+ is compiled with the X11 backend: $ nm -gU /Volumes/mp-trunk/x11/lib/libgtk-3.0.dylib | grep drag_cancel 0000000000286908 T _gtk_drag_cancel 000000000028698a t _gtk_drag_cancel_internal $ nm -gU /Volumes/mp-trunk/quartz/lib/libgtk-3.0.dylib | grep drag_cancel $ The failure to launch MyPaint is likely related to this commit in gtk-3-14: https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-14&id=62616a716fb8dae4b59ab9dbc8d068364d1ba63e Unfortunately, I don't have a build environment set up to test with either backend of latest GTK+ 3.15.x or git master to verify whether the issue still happens or not. System info: * Mac OS X 10.7.5 * GTK+ 3.14 and dependencies installed via MacPorts (two separate MacPorts trees in different prefixes: one for X11-based builds, one for Quartz-based builds (no X11 headers or libs available here)) * MyPaint 1.1.1-alpha is installed via MacPorts: https://trac.macports.org/browser/trunk/dports/graphics/MyPaint/Portfile#L95
A name starting with '_' indicates that it's an internal symbol, and that it should not be used outside of GTK+; if it's exposed in the shared object, it's just an oversight or the result of wrong compilation flags. I've also checked in Git, and there's no _gtk_drag_cancel symbol defined in the gtk-3-14 branch. On the gtk-3-14 branch, gtk_drag_cancel() is an internal symbol, which is not exported in the shared object; the symbol has been made public in the current master branch, and will be available in GTK+ 3.16, once it's released. If MyPaint requires gtk_drag_cancel(), then it will need to bump its dependency of GTK+ to 3.16.
1) I did not find any reference to gtk_drag_cancel() in MyPaint's code https://github.com/mypaint/mypaint/search?utf8=%E2%9C%93&q=gtk_drag_cancel&type=Code 2) the same MyPaint build started to fail after upgrading GTK+/Quartz from 3.14.7 to 3.14.8 (no changes otherwise) 3) the same MyPaint build works again after downgradint GTK+/Quartz from 3.14.8 to 3.14.7, or from 3.14.9 to 3.14.7 4) The X11 backend is not affected (MyPaint using GTK+/X11 3.14.9 works just fine) Juszt curious - how could this be a MyPaint issue? Where or what exactly would I have to look for?
The module that causes the error (_mypaintlib.so) is a C module that only uses GTK to workaround one or two special problems that were not possible from Python or gobject inspection. Most likely the error has nothing to do with the MyPaint code itself (it seems that drag_cancel was never used through all mypaint history), but with the way the module was compiled/linked. Probably it could be caused if _mypaintlib.so was compiled with a git snapshot of gtk headers, but the gtk library loaded at runtime is older, and at load time it just tries to find all symbols that were known at compile time.
(In reply to Martin Renold from comment #3) > Most likely the error has nothing to do with the MyPaint code itself (it > seems that drag_cancel was never used through all mypaint history), but with > the way the module was compiled/linked. Probably it could be caused if > _mypaintlib.so was compiled with a git snapshot of gtk headers, but the gtk > library loaded at runtime is older, and at load time it just tries to find > all symbols that were known at compile time. MyPaint had been uninstalled and reinstalled (compiled from source) several times since the issue first occurred (to exclude any interference with remnants of older versions). The library '_mypaintlib.so' is removed from the system when the port is uninstalled, and no build files are retained at any time (they are removed after the port is installed). The original symptom: MyPaint installed earlier crashed on launch with GTK+/Quartz >= 3.14.8. Uninstalling and recompiling MyPaint from source did not help, downgrading GTK+/Quartz to 3.14.7 did. The symptom now is the same: A new (more recent) snapshot from MyPaint git master compiled from source against (headers and libs of) GTK+/Quartz 3.14.9 crashes on launch, but works if GTK+ is downgraded to 3.14.7 (without recompiling MyPaint). The symptom is the same the other way round: First uninstalling MyPaint completely, downgrade GTK+ to 3.14.7 and then reinstall MyPaint (compiled from source): works with GTK+/Quartz 3.14.7, crashes once GTK+/Quartz is upgraded again to 3.14.9. MyPaint with GTK+/X11 has never exposed this issue. MyPaint compiled against (headers and libs of) GTK+/X11 3.14.9 launches ok; and it still launches ok if GTK+/X11 is downgraded to GTK+/X11 3.14.7 (without recompiling MyPaint).
Created attachment 304319 [details] [review] Add stub function definition in gtk/gtkdnd-quartz.c for 'gtk_dnd_cancel' Problem persists with latest stable Gtk+/Quartz 3.16.3. 1) in gtk/gtkdnd.h, 'gtk_drag_cancel' is declared (unconditionally) 2) the header is included in gtk/gtkdnd.c as well as in gtk/gtkdnd-quartz.c 3) the function definition is only in gtkdnd.c 4) gtkdnd.c is not built with the Quartz backend (see Makefile.am) --> 'gtk_drag_cancel' is not available with Quartz backend Adding a stub function definition for 'gtk_dnd_cancel' in gtk/gtkdnd-quartz.c (see attached diff) allows MyPaint to launch without error if using the patched build of current stable Gtk+/Quartz 3.16.3. The diff is based on the workaround recommended in bug 705978, and was not tested for any negative side-effects. Any chance you could reopen this report and acknowledge this is an issue in the Quartz backend (gtk_dnd_cancel declared in the shared header, but never defined for the Quartz backend) and should be addressed in Gtk+?
Forgot to mention that in addition to the diff attached in comment 5 (stub definition of gtk_dnd_cancel), the patched Gtk+/Quartz 3.16.3 build which allowed to launch MyPaint also included the changes from this recent commit to the gtk-3-16 branch: 673013ac67e322ff86193001131255fc24a68d5e
https://git.gnome.org/browse/gtk+/commit/?id=c160ba0696dc5ffaece04941cf24344bf76bab65 made gtk_drag_cancel a public function but didn't stub it out in gtkdnd-quartz.c, and backported to 3.14 in https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-14&id=c160ba0696dc5ffaece04941cf24344bf76bab65 in spite of the "Since 3.16" annotation. I think we'll need to actually implement something for this so that we don't leak the drag context. I'll look at it in more detail shortly.
Sorry, the backport was https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-14&id=62616a716fb8dae4b59ab9dbc8d068364d1ba63e Anyway, I've implemented gtk_drag_cancel in gtkdnd-quartz.c and pushed to gtk-3-14, gtk-3-16, and master. Thanks for the persistence and detective work!
Thank you for reconsidering the report and for the fix! Tested successfully on OS X 10.7.5 using - MyPaint 1.2.0-alpha.20150523+git.b7836aa8 - Gtk+ 3.16.3 patched with 90ee25f, 873cc0e, 673013a and 6ff49ee (Quartz as well as X11 backend tested in separate build setups) The Quartz-based MyPaint build launches ok now and basic usage works as expected. It does expose a regression (crash) later on when attempting to open the Layers window (works ok with X11 backend) - I will file a separate report about that later (once I have more details available).
(In reply to Emmanuele Bassi (:ebassi) from comment #1) > A name starting with '_' indicates that it's an internal symbol, and that it > should not be used outside of GTK+; if it's exposed in the shared object, > it's just an oversight or the result of wrong compilation flags. I've also > checked in Git, and there's no _gtk_drag_cancel symbol defined in the > gtk-3-14 branch. Just a quick note...on darwin compilers, essentially *all* symbols get an underscore prefix added in the binary symbol table. A private symbol would appear to begin with '__' in the binary image, one for the standard "leading '_' means private symbol" in the API, and the second by compiler nature in the ABI of it.