Linking failure on MacOS (darwin) and gtk+3-3.24.10

[vbgl]

CoqIDE has been using lablgtk3 (3.0.beta6) since a few month. It used to build fine on MacOS with GTK 3 at version 3.24.9.

With version 3.24.10 of GTK3, there is the following linking error:

OCAMLOPT -o bin/coqide
Undefined symbols for architecture x86_64:
  "_GTK_SOCKET", referenced from:
      _ml_gtk_socket_add_id in liblablgtk3_stubs.a(ml_gtk.o)
      _ml_gtk_socket_get_id in liblablgtk3_stubs.a(ml_gtk.o)
      _ml_gtk_socket_get_plug_window in liblablgtk3_stubs.a(ml_gtk.o)
  "_gtk_plug_get_type", referenced from:
      _ml_gtkwindow_init in liblablgtk3_stubs.a(ml_gtk.o)
  "_gtk_plug_new", referenced from:
      _ml_gtk_plug_new in liblablgtk3_stubs.a(ml_gtk.o)
     (maybe you meant: _ml_gtk_plug_new)
  "_gtk_socket_add_id", referenced from:
      _ml_gtk_socket_add_id in liblablgtk3_stubs.a(ml_gtk.o)
     (maybe you meant: _ml_gtk_socket_add_id)
  "_gtk_socket_get_id", referenced from:
      _ml_gtk_socket_get_id in liblablgtk3_stubs.a(ml_gtk.o)
     (maybe you meant: _ml_gtk_socket_get_id)
  "_gtk_socket_get_plug_window", referenced from:
      _ml_gtk_socket_get_plug_window in liblablgtk3_stubs.a(ml_gtk.o)
     (maybe you meant: _ml_gtk_socket_get_plug_window)
  "_gtk_socket_get_type", referenced from:
      _ml_gtkwindow_init in liblablgtk3_stubs.a(ml_gtk.o)
ld: symbol(s) not found for architecture x86_64

These missing functions belong to the GtkPlug and GtkSocket APIs which are supposedly only available on X11 platforms (as described there: https://developer.gnome.org/gtk3/stable/GtkPlug.html). So the error is somehow expected. What is strange is that it did not show up before.

NB: I get the same error when trying to build the “example3” test program (from https://github.com/garrigue/lablgtk/blob/lablgtk3/examples/sourceview/example3.ml).

[garrigue]

How are you installing Gtk33 on MacOS? My understanding is that, contrary to Gtk2, until recently there was no native version of Gtk3 on MacOS, meaning that you would always be in an X11 setting. However, I now see that there is +quartz variant in macports, so we may need to detect this. In lablgtk2 this was properly detected, so there should be a way to do that.

[vbgl]

In Coq CI we use homebrew: https://github.com/coq/coq/blob/master/azure-pipelines.yml#L56 This had been working as long as GTK3 was at version 3.24.9. (This is why the brew repository is reset to a version that is known to work.)

[vbgl]

There is also a minimal example in which all dependencies are installed using nix (https://github.com/vbgl/lablgtk3):

• successful build with 3.24.8: https://travis-ci.org/vbgl/lablgtk3/builds/588484650
• failing build with 3.24.10: https://travis-ci.org/vbgl/lablgtk3/builds/586580947

[garrigue]

I'm not sure how to analyze that. In principle, lablgtk3 automatically detects that gtk+-quartz-3.0 is available (src/dune_config.ml) It then sets HAS_GTKQUARTZ. In turns, this makes it read Quartz related headers, which should define GDK_WINDOWING_QUARTZ. When this last constant is defined, the above functions should be left undefined, and not referred to (src/ml_gtk.c) So, one possibility is that either GDK_WINDOWING_QUARTZ is no longer defined, or that for some reason the file that defines it isn't loaded.

[vbgl]

Thanks for the explanations. So this might be a GTK issue that should be fixed there: https://gitlab.gnome.org/GNOME/gtk/merge_requests/1004/diffs?commit_id=ff21730d8e582ec7e60950771c4f8e4f9bbf82a1

Let me try with 3.24.11 then.

[garrigue]

I see. If they're slow to merge it, another solution would to force the definition on our side when HAS_GTKQUARTZ is defined, but this may end up being more fragile if our detection is wrong.

[vbgl]

The fix is included in 3.24.11. I’ve just confirmed that CoqIDE can be built on macOS using homebrew with that version of gtk3.

Thanks for your help.

[garrigue]

Thanks for the update.