How to build with GTK on macOS in a way the app actually works?

[barracuda156]

Could you say how to build with GTK GUI? I can build the app with minimal tweaks, but it does not work, crashing on launch.

% /Applications/MacPorts/eiskaltdcpp/eiskaltdcpp.app/Contents/MacOS/eiskaltdcpp
Loading: Hash database
Loading: Shared Files
Loading: Download Queue
Loading: Users
Installing handler for: Segmentation fault
Installing handler for: Abort trap
Installing handler for: Bus error
Installing handler for: Terminated
Signal handlers installed.
eiskaltdcpp.app/Contents/Resources/gtk is inaccessible, falling back to current directory instead.
GTKBUILDER ERROR file => ./ui/mainwindow.ui ,
 => Failed to open file “./ui/mainwindow.ui”: No such file or directory
(eiskaltdcpp:32261): Gtk-CRITICAL **: 08:53:41.502: gtk_main_quit: assertion 'main_loops != NULL' failed

(eiskaltdcpp:32261): Gtk-CRITICAL **: 08:53:41.502: gtk_window_set_role: assertion 'GTK_IS_WINDOW (window)' failed
Catching signal : Segmentation fault

Linking to libraries looks fine, bundle structure looks sane too, but the thing is still broken.

[tehnick]

Hi,

Our GTK+ UI was not develped for usage on systems different from GNU/Linux and *BSD. This UI is abandoned during years and will be completely removed from sources tree soon.

Please do not waste your time trying to package it for macOS.

[barracuda156]

@tehnick Thank you for responding.

As long as Qt4 is supported, we are good. My concern was that if Qt4 is dropped, then the only workable option for a subset of platforms which we support in MacPorts will be GTK, since Qt5 is broken on those.

[tehnick]

since Qt5 is broken on those.

How about Qt6 on those platforms? Is it broken too?

(I am going to port program to Qt6 since 3.x release series.)

[barracuda156]

@tehnick The only realistic way, in principle, to build Qt5+ on older macOS (and unsupported archs) is to switch the build to X11 backend for GUI, completely avoiding Cocoa. It is non-trivial, since, unfortunately, Qt upstream not only failed to provide a configure option, but designed sources in a way to make it painful and time-consuming to try fixing that mess. I suspect that problems would not end just on this, but it is the biggest problem. But also, since they never test the code with GCC on macOS (it is written in parts in a way which leaves it broken for GCC), quite possible things are also broken elsewhere. Given the size of Qt codebase, it is pretty much the lost case.

Besides, Qt-related breakages are not limited to older macOS. On the current OpenBSD, for example, both webkit and qtwebengine are broken on powerpc. Qt itself works, but BSD uses X11.

With GTK it is somewhat better: as long as Gnome folks refrain from forcing rust onto GTK users, it will probably work on every platform. GTK4 has issues, but given that GTK3 works robustly, those should be relatively easily fixable.