gnucash @3.5 +quartz fails to build

[jjstickel (Jonathan Stickel)]

I'm trying to install gnucash with +quartz for the backend dependencies. I wasn't able to install yelp +quartz (see #55345), and so I removed the yelp runtime dependency from gnucash-docs. This allows gnucash to start building, but I get this error:

:info:build [  6%] Building C object libgnucash/gnc-module/test/mod-foo/CMakeFiles/foo.dir/foo.c.o
:info:build cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gnucash/gnucash/work/build/libgnucash/gnc-module/test/mod-foo && /usr/bin/clang -DHAVE_CONFIG_H -DHAVE_GUILE22 -D_GNU_SOURCE -Dfoo_EXPORTS -I/opt/local/include  -Wno-error=deprecated-declarations -std=gnu11 -Wno-error=parentheses -Werror -Wdeclaration-after-statement -Wno-pointer-sign -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-unused -pipe -Os -DNDEBUG -isystem/opt/local/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gnucash/gnucash/work/gnucash-3.5 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -mmacosx-version-min=10.14 -fPIC   -o CMakeFiles/foo.dir/foo.c.o   -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gnucash/gnucash/work/gnucash-3.5/libgnucash/gnc-module/test/mod-foo/foo.c
:info:build ld: framework not found -lCocoa
:info:build clang: error: linker command failed with exit code 1 (use -v to see i

I'll attach the full build log.

[ryandesign (Ryan Carsten Schmidt)]

The build seems to be using the flags -framework -lCocoa, which is incorrect; it should be using -framework Cocoa.

This seems to be a common problem with developers misunderstanding how to specify this in cmake. ​This mailing list post claims to describe the correct way to do it.

[jjstickel (Jonathan Stickel)]

Replying to ryandesign:

The build seems to be using the flags -framework -lCocoa, which is incorrect; it should be using -framework Cocoa.

This seems to be a common problem with developers misunderstanding how to specify this in cmake. ​This mailing list post claims to describe the correct way to do it.

Thanks for this! I'll try to patch the source and see if it works.

[jjstickel (Jonathan Stickel)]

I missed the offending line from the build:

:info:build /usr/bin/clang -Wno-error=deprecated-declarations -std=gnu11 -Wno-error=parentheses -Werror -Wdeclaration-after-statement -Wno-pointer-sign -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-unused -pipe -Os -DNDEBUG -isystem/opt/local/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gnucash/gnucash/work/gnucash-3.5 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -mmacosx-version-min=10.14 -dynamiclib -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -o ../../lib/gnucash/libgwengui-gtk3.dylib -install_name /opt/local/lib/libgwengui-gtk3.dylib CMakeFiles/gwengui-gtk3.dir/gtk3_gui_dialog.c.o CMakeFiles/gwengui-gtk3.dir/gtk3_gui.c.o -Wl,-rpath,/opt/local/lib:/opt/local/lib/gnucash -L/opt/local/lib -lgwenhywfar -L/opt/local/lib -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gnucash/gnucash/work -lgtk-3 -lgdk-3 -framework -lCocoa -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl -Wl,-framework -Wl,CoreFoundation 

So, -framework -lCocoa is being used. But I can't find how it is being populated. Using grep -Ri cocoa on the sources doesn't show much other than an old changelog that refers to the build process before cmake: ​https://lists.gnucash.org/pipermail/gnucash-changes/2013-May/012039.html . Where is -framework -lCocoa being pulled in from?

[kencu (Ken)]

maybe it's being pulled in by pkg-config from one of the deps, like gtk3 or perhaps webkitgtk-3.0.pc

[jjstickel (Jonathan Stickel)]

It is gtk3. Updating gtk3 to 3.24.10 seems to fix the problem. Still testing.

[drkp (Dan Ports)]

I was wondering about this because I hit the same problem while trying to update gnucash to 3.6, and yet clearly +quartz build for 3.5 used to work because I have it installed now. A dependency problem makes sense...

[jjstickel (Jonathan Stickel)]

The "framework cocoa" issue was supposedly resolved upstream in gtk-3.24:

​https://gitlab.gnome.org/GNOME/gtk/commit/0d8dcccad2844cd35d0d61e32878ca19fdfabe9b

I was able to build and install gnucash with gtk3 @3.24.10_0+quartz, but then I get a segfault when running gnucash. gtk3-demo and some other gtk3 apps seem to be working ok.

[jjstickel (Jonathan Stickel)]

I somehow had glibmm +x11. Reinstalling glibmm +quartz resolved the segfault, and gnucash seems to be working. glibmm should probably have an "active_variants" check for glib2.

I'll try to make a pull request in the next couple of days. I need to stop for tonight.

[kencu (Ken)]

base should resolve the x11 vs quartz variants, I think. We're having a "same but different" variant resolving issue with +universal variant resolving in another active ticket right now.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jjstickel:

I'll try to make a pull request in the next couple of days. I need to stop for tonight.

Any progress on submitting an update of gtk3 to 3.24.10?

Replying to kencu:

base should resolve the x11 vs quartz variants, I think.

I don't think base knows anything about x11 or quartz variants (or any other variant, other than the universal variant for which it does have special handling), and will not do anything to ensure you don't shoot yourself in the foot by installing one port with one variant and another port with the other variant. So don't do that, and don't change your mind about which (x11 or quartz) variant you're going to use for your entire MacPorts installation, unless you uninstall all ports and then make the change.

[jjstickel (Jonathan Stickel)]

Replying to ryandesign:

Replying to jjstickel:

I'll try to make a pull request in the next couple of days. I need to stop for tonight.

Any progress on submitting an update of gtk3 to 3.24.10?

Yes: ​https://github.com/macports/macports-ports/pull/4848 . It has stalled because the maintainer requested time to evaluate and hasn't reported back in some time.

[jjstickel (Jonathan Stickel)]

Huh, I just looked, and glibmm does use active_variants for quartz/x11. I guess what happened is that, at one point, I installed glib2+x11 and glibmm+x11. When I reinstalled glib2+quartz, glibmm+x11 remained (I guess rev-upgrade does not do variants checks). Ryan is right: extra care and consistency is often needed for x11/quartz. A few ports allow both (e.g., pango), but many do not.

[jjstickel (Jonathan Stickel)]

In da363456bfba3d06627d9f7d94a8790d426d2c7b/macports-ports (master):

gtk3: update to version 3.24.10

• update to version 3.24.10
• remove a patch that is no longer needed

Closes: #58730