gtkmm4: Undefined symbols for architecture arm64 when building a demo program using gcc as the compiler (clang works fine)

[chaochinyang (Chao-Chin Yang)]

I can successfully install gtkmm4 on my M1 MacBook Pro or M2 Mac Pro by

sudo port install gtkmm4

However, when I simply try the example code from ​https://gnome.pages.gitlab.gnome.org/gtkmm-documentation/chapter-basics.html:

#include <gtkmm.h>

class MyWindow : public Gtk::Window
{
public:
  MyWindow();
};

MyWindow::MyWindow()
{
  set_title("Basic application");
  set_default_size(200, 200);
}

int main(int argc, char* argv[])
{
  auto app = Gtk::Application::create("org.gtkmm.examples.base");

  return app->make_window_and_run<MyWindow>(argc, argv);
}

and compile it with

g++ simple.cc -o simple `pkg-config --cflags --libs gtkmm-4.0` -std=c++17

the compiler gives me the linking error:

Undefined symbols for architecture arm64:
  "__ZN3Gtk15ShortcutManager20add_controller_vfuncERKSt10shared_ptrINS_18ShortcutControllerEE", referenced from:
      __ZTV8MyWindow in ccihtuA7.o
      __ZTC8MyWindow0_N3Gtk6WindowE in ccihtuA7.o
      __ZTC8MyWindow48_N3Gtk15ShortcutManagerE in ccihtuA7.o
  "__ZN3Gtk15ShortcutManager23remove_controller_vfuncERKSt10shared_ptrINS_18ShortcutControllerEE", referenced from:
      __ZTV8MyWindow in ccihtuA7.o
      __ZTC8MyWindow0_N3Gtk6WindowE in ccihtuA7.o
      __ZTC8MyWindow48_N3Gtk15ShortcutManagerE in ccihtuA7.o
  "__ZN3Gtk6Widget14snapshot_vfuncERKSt10shared_ptrINS_8SnapshotEE", referenced from:
      __ZTV8MyWindow in ccihtuA7.o
      __ZTC8MyWindow0_N3Gtk6WindowE in ccihtuA7.o
      __ZTC8MyWindow0_N3Gtk6WidgetE in ccihtuA7.o
  "__ZN3Gtk6Widget16on_query_tooltipEiibRKSt10shared_ptrINS_7TooltipEE", referenced from:
      __ZTV8MyWindow in ccihtuA7.o
      __ZTC8MyWindow0_N3Gtk6WindowE in ccihtuA7.o
      __ZTC8MyWindow0_N3Gtk6WidgetE in ccihtuA7.o
ld: symbol(s) not found for architecture arm64
collect2: error: ld returned 1 exit status

All the flags and libraries from pkg-config look ok to me

% pkg-config --cflags --libs gtkmm-4.0 | tr ' ' '\n'
-I/opt/local/include/gtkmm-4.0
-I/opt/local/lib/gtkmm-4.0/include
-I/opt/local/include/pangomm-2.48
-I/opt/local/lib/pangomm-2.48/include
-I/opt/local/include/giomm-2.68
-I/opt/local/lib/giomm-2.68/include
-I/opt/local/include/glibmm-2.68
-I/opt/local/lib/glibmm-2.68/include
-I/opt/local/include/cairomm-1.16
-I/opt/local/lib/cairomm-1.16/include
-I/opt/local/include/sigc++-3.0
-I/opt/local/lib/sigc++-3.0/include
-I/opt/local/include/gtk-4.0/unix-print
-I/opt/local/include/gtk-4.0
-I/opt/local/include/pango-1.0
-I/opt/local/include/harfbuzz
-I/opt/local/include/pango-1.0
-I/opt/local/include/fribidi
-I/opt/local/include
-I/opt/local/include/harfbuzz
-I/opt/local/include
-I/opt/local/include/gdk-pixbuf-2.0
-I/opt/local/include
-I/opt/local/include/cairo
-I/opt/local/include/pixman-1
-I/opt/local/include
-I/opt/local/include/freetype2
-I/opt/local/include
-I/opt/local/include/libpng16
-I/opt/local/include
-I/opt/local/include/graphene-1.0
-I/opt/local/lib/graphene-1.0/include
-I/opt/local/include
-I/opt/local/include/glib-2.0
-I/opt/local/lib/glib-2.0/include
-I/opt/local/include
-L/opt/local/lib
-lgtkmm-4.0
-lpangomm-2.48
-lgiomm-2.68
-lglibmm-2.68
-lcairomm-1.16
-lsigc-3.0
-lgtk-4
-lpangocairo-1.0
-lpango-1.0
-lharfbuzz
-lgdk_pixbuf-2.0
-lcairo-gobject
-lcairo
-lgraphene-1.0
-lgio-2.0
-lgobject-2.0
-lglib-2.0
-lintl

Maybe libgtkmm-4.0 is not configured or compiled correctly by the port?

[kencu (Ken)]

I just tried it, and it works fine for me on Sonoma 14.5 arm64.

The +x11 version builds but won't run due to OpenGL issues that have been discussed in another ticket.

The +quartz version is fine, though, builds with no errors and runs as it should, opens the window.

[chaochinyang (Chao-Chin Yang)]

Strange. I also have the latest Sonoma. Not sure how to debug on my end. What is your gcc version? Mine is

g++ (MacPorts gcc13 13.2.0_4+stdlib_flag) 13.2.0

[kencu (Ken)]

use clang++ instead

[chaochinyang (Chao-Chin Yang)]

I also just found out that clang++ works. Still, why would g++ fail in this case?

[kencu (Ken)]

to answer that question, add some verbosity flags to the build, and compare them.

These should do it:

-v  -Wl,-v

it could be that specifying -stdlib=libc++ makes a difference. clang++ does that by default. g++ needs to have that manually added, as it defaults to it's own stdlib.

[chaochinyang (Chao-Chin Yang)]

The two builds look quite different. I have tried swapping quite a few options between the two but no luck to track the gcc problem down. Nevertheless, I am almost sure the problem was not the linker, but the compilation, even though the latter did not give any errors. The reason was I used exactly the clang way of linking on the gcc-built object and the undefined symbols persist. Also, -std=libc++ does not change the result. It is out of my ability to move forward. I will attach the verbose logs for the two builds.

[kencu (Ken)]

OK. It can be tricky to fully sort things out, certainly.

macports is not likely to spend resources sorting out how to make the gtkmm4 demo program build with g++ on Intel or arm64.

Someone interested in PPC might be, if the error happens there, as gcc is the only usable compiler for darwin ppc.