gtkmm3: regression: atkmm-api disabled, causing inkscape failure: symbol not found: __ZN3Gtk6Widget20get_accessible_vfuncEv

[ryandesign (Ryan Carsten Schmidt)]

On my Monterey x86_64 Mac this happens when I try to launch inkscape:

% inkscape
dyld[19259]: Symbol not found: (__ZN3Gtk6Widget20get_accessible_vfuncEv)
  Referenced from: '/opt/local/lib/libinkscape_base.dylib'
  Expected in: '/opt/local/lib/libgtkmm-3.0.1.dylib'
zsh: abort      inkscape

% port provides /opt/local/lib/libinkscape_base.dylib /opt/local/lib/libgtkmm-3.0.1.dylib
/opt/local/lib/libinkscape_base.dylib is provided by: inkscape
/opt/local/lib/libgtkmm-3.0.1.dylib is provided by: gtkmm3

% port -qv installed inkscape gtkmm3
  gtkmm3 @3.24.7_0+x11 (active) requested_variants='' platform='darwin 21' archs='x86_64' date='2023-05-30T20:42:00-0500'
  inkscape @1.2.2_3+x11 (active) requested_variants='' platform='darwin 21' archs='x86_64' date='2023-06-03T04:01:29-0500'

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

  inkscape @1.2.2_3+x11 (active) requested_variants='' platform='darwin 21' archs='x86_64' date='2023-06-03T04:01:29-0500'

The installation date shown here is misleading in that I did not build from source on that date; I used the private binary produced by the buildbot on 2023-05-05.

Downgrading gtkmm3 to 3.24.2_0 works. This suggests something significant happened between gtkmm3 3.24.2 and 3.24.7. Unfortunately the gtkmm3 3.24.2->3.24.7 update in MacPorts was an overhaul of the port with many changes, making it difficult to know what may have caused this.

One significant change that happened then for MacPorts is that the port switched from autotools to meson. It also switched dependencies from atkmm, cairomm, glibmm, and pangomm to atkmm-1.6, cairomm-1.0, glibmm-2.4, and pangomm-1.4.

Looking in the gtkmm3 code, get_accessible_vfunc is only defined and used if GTKMM_ATKMM_ENABLED is defined. This makes me think that maybe the new gtkmm3 is not using atkmm, and that the fact that gtkmm3 was using atkmm at the time inkscape was built somehow seeped into the build of inkscape. I think this confirms it:

% port -q installed gtkmm3 and active
  gtkmm3 @3.24.2_0+x11 (active)
% otool -L /opt/local/lib/libgtkmm-3.0.dylib 
/opt/local/lib/libgtkmm-3.0.dylib:
	/opt/local/lib/libgtkmm-3.0.1.dylib (compatibility version 3.0.0, current version 3.0.0)
	/opt/local/lib/libgdkmm-3.0.1.dylib (compatibility version 3.0.0, current version 3.0.0)
	/opt/local/lib/libatkmm-1.6.1.dylib (compatibility version 3.0.0, current version 3.0.0)
	/opt/local/lib/libgiomm-2.4.1.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libpangomm-1.4.1.dylib (compatibility version 2.0.0, current version 2.30.0)
	/opt/local/lib/libglibmm-2.4.1.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libcairomm-1.0.1.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libsigc-2.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libgtk-3.0.dylib (compatibility version 2405.0.0, current version 2405.19.0)
	/opt/local/lib/libgdk-3.0.dylib (compatibility version 2405.0.0, current version 2405.19.0)
	/opt/local/lib/libpangocairo-1.0.0.dylib (compatibility version 4801.0.0, current version 4801.10.0)
	/opt/local/lib/libpango-1.0.0.dylib (compatibility version 4801.0.0, current version 4801.10.0)
	/opt/local/lib/libharfbuzz.0.dylib (compatibility version 20901.0.0, current version 20901.0.0)
	/opt/local/lib/libatk-1.0.0.dylib (compatibility version 23610.0.0, current version 23610.1.0)
	/opt/local/lib/libcairo-gobject.2.dylib (compatibility version 11707.0.0, current version 11707.0.0)
	/opt/local/lib/libcairo.2.dylib (compatibility version 11707.0.0, current version 11707.0.0)
	/opt/local/lib/libgdk_pixbuf-2.0.0.dylib (compatibility version 4201.0.0, current version 4201.2.0)
	/opt/local/lib/libgio-2.0.0.dylib (compatibility version 6201.0.0, current version 6201.6.0)
	/opt/local/lib/libgobject-2.0.0.dylib (compatibility version 6201.0.0, current version 6201.6.0)
	/opt/local/lib/libglib-2.0.0.dylib (compatibility version 6201.0.0, current version 6201.6.0)
	/opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.5.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1200.3.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)

% port -q installed gtkmm3 and active            
  gtkmm3 @3.24.7_0+x11 (active)
% otool -L /opt/local/lib/libgtkmm-3.0.dylib 
/opt/local/lib/libgtkmm-3.0.dylib:
	/opt/local/lib/libgtkmm-3.0.1.dylib (compatibility version 3.0.0, current version 3.0.0)
	/opt/local/lib/libgdkmm-3.0.1.dylib (compatibility version 3.0.0, current version 3.0.0)
	/opt/local/lib/libgiomm-2.4.1.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libglibmm-2.4.1.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libgobject-2.0.0.dylib (compatibility version 7601.0.0, current version 7601.2.0)
	/opt/local/lib/libglib-2.0.0.dylib (compatibility version 7601.0.0, current version 7601.2.0)
	/opt/local/lib/libsigc-2.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libgtk-3.0.dylib (compatibility version 2406.0.0, current version 2406.32.0)
	/opt/local/lib/libgdk-3.0.dylib (compatibility version 2406.0.0, current version 2406.32.0)
	/opt/local/lib/libcairomm-1.0.1.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libpangomm-1.4.1.dylib (compatibility version 2.0.0, current version 2.30.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.23.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)

So I would guess the solution is to make gtkmm3 use atkmm again. The presence of the atkmm-1.6 dependency shows the port is intending to use atkmm but something appears to be going wrong.

Looking at ​the most recent gtkmm3 build log from the buildbot, it says:

Dependency atkmm-1.6 found: YES 2.28.0 (cached)

         Build atkmm API: false

I tried leaving gtkmm3 at 3.24.7_0 and rebuilding inkscape 1.2.2_3 from source in trace mode but this failed.

I tried rebuilding gtkmm3 3.24.7_0 in trace mode but this failed.

[kencu (Ken)]

might be this, in the Portfile:

configure.args-append \
                    -Dbuild-atkmm-api=false

toggle that to true, perhaps

[Christopher Nielsen <mascguy@…>]

In 9c9f7df2244e125f511a8438d0d718f216c33a9a/macports-ports (master):

gtkmm3: regression: set build-atkmm-api=true
See: #67568

[mascguy (Christopher Nielsen)]

Sorry about this, here's the quick backstory:

I went through multiple rounds of testing, when validating the various updates to the libs tracked by issue:65859.

During that validation, I tested every currently-installed app by launching them, and quickly kicking the tires of each. But none of them failed with that error. (Inkscape included.) The important thing to note is that I purposely didn't rebuild any apps like Inkscape either, to mirror the update scenario for all of our users.

So I'm not entirely clear how this slipped through without being caught sooner. And I would have expected a Trac ticket to be submitted by now, but there haven't been any reports that I'm aware of.

The one difference is that I use Quartz ports exclusively, but I don't think that should have any bearing on the missing symbol in question: The accessibility-related API should exist and function similarly, regardless of whether the libs are installed as Quartz or X11.

I'm reasonably confident that everything else is OK, but I'll re-review all of the updates regardless. And great catch Ryan, thanks for bringing this to my attention!

[mascguy (Christopher Nielsen)]

p.s. Let me know whether the latest commit fixes the issue for you, after it comes through. Until then, I'll leave the ticket open, just-in-case...

[Christopher Nielsen <mascguy@…>]

In e6b2a795ad846c2673023b96dc8d053e54980a87/macports-ports (master):

gtkmm3 rdependents: rev-bump for gtkmm3 fix

• goocanvasmm2 already done via separate commit

See: #67568

[mascguy (Christopher Nielsen)]

FYI, while there technically shouldn't be a need to rev-bump all rdependents of gtkmm3 - enabling accessibility features shouldn't cause ABI breakage, it's only when going from enabled to disabled that does - I rev-bumped them anyway, to ensure we're in a known, consistent state.

[mascguy (Christopher Nielsen)]

Ryan, is this fixed now?

[mascguy (Christopher Nielsen)]

Replying to mascguy:

Ryan, is this fixed now?

Closing as fixed. Let me know if you're still seeing the issue.