ART 1.20 for macOS notarized build

Daniel_Catalina · December 9, 2023, 9:40am

OK, good to know. I will have a go than at trying to fix some of the more offending errors (I get some errors/warnings that some files are not found).

Where I have troubles is at signing the package. I assume I need to use an apple developer account with a valid key in my keychain so this works? Or is it another more ‘general’ user that the build system is using?

Daniel_Catalina · December 9, 2023, 9:53am

At least on my system, the packaging script seems to have a problem copying the files linked by homebrew in ‘/opt/homebrew/lib’. I get a lot of errors like:

Copying Resources directory.
ditto: Cannot get the real path for source '/opt/homebrew/lib/liblensfun.2.dylib'
ditto: Cannot get the real path for source '/opt/homebrew/lib/libomp.dylib'

If i modify their path in the packaging script to the real files (in /opt/homebrew/opt/lib/lib/…) than the errors disappear.

@HIRAM any clue why would this behaviour appears?

charlie84 · December 9, 2023, 1:46pm

Thanks, I corrected it. It no longer crashes but this empty window opens

HIRAM · December 9, 2023, 2:28pm

@Daniel_Catalina
Codesign can be done “ad hoc” with no identity needed. To do this, sign it with a minus: -DCODESIGNID="-" On most systems now ad hoc signatures only run on a single machine, and bundling homebrew libraries requires --force --deep due to existing code signature pages.

There are myriad warnings generated by the packaging script, which is iterative is some places. Most of the ignorable warning messages are being redirected to /dev/null. Over time different classes of warning messages develop and appear in the output. Other commands in the script which for example generate helper files are not redirected.

There are also times when libraries move or have more than one standard location, like /opt/homebrew/lib/mylib.dylib vs /usr/local/opt/mylib/lib/mylib.dylib etc, which cause errors, and in most cases handling must be individuated in the script. Those libraries may be missed by the iterative handler, but copied in later by another command.

Daniel_Catalina · December 11, 2023, 10:04am

So I managed to build it and even if the bundle script had all kinds of errors and warnings I ended up with an APP, DMG and other fancy things in the ‘build’ folder.
Currently I have the following situation:

running directly from ‘./build/release/Macos/ART’ works fine
running the APP installed in /Applications using the generated DMG works fine
running in the terminal from /Applications/ART/Contents/MacOS/ART shows some errors and warnings in the console and crashes

% /Applications/ART.app/Contents/MacOS/ART

(ART:3747): Gtk-CRITICAL **: 10:58:18.346: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed
objc[3747]: Class GNotificationCenterDelegate is implemented in both /Applications/ART.app/Contents/Frameworks/libgio-2.0.0.dylib (0x1053e86b0) and /opt/homebrew/Cellar/glib/2.78.3/lib/libgio-2.0.0.dylib (0x111a106b0). One of the two will be used. Which one is undefined.

(ART:3747): GdkPixbuf-CRITICAL **: 10:58:18.788: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(ART:3747): GdkPixbuf-CRITICAL **: 10:58:18.788: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(ART:3747): GdkPixbuf-CRITICAL **: 10:58:18.788: gdk_pixbuf_set_option: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(ART:3747): GdkPixbuf-CRITICAL **: 10:58:18.788: gdk_pixbuf_set_option: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(ART:3747): GdkPixbuf-CRITICAL **: 10:58:18.788: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(ART:3747): GdkPixbuf-CRITICAL **: 10:58:18.788: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(ART:3747): GdkPixbuf-CRITICAL **: 10:58:18.788: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(ART:3747): GdkPixbuf-CRITICAL **: 10:58:18.788: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(ART:3747): GdkPixbuf-CRITICAL **: 10:58:18.788: gdk_pixbuf_scale_simple: assertion 'GDK_IS_PIXBUF (src)' failed

(ART:3747): Gtk-WARNING **: 10:58:18.788: Could not load a pixbuf from /org/gtk/libgtk/theme/Adwaita/assets/bullet-symbolic.svg.
This may indicate that pixbuf loaders or the mime database could not be found.

(ART:3747): GLib-CRITICAL **: 10:58:18.788: g_propagate_error: assertion 'src != NULL' failed
zsh: segmentation fault  /Applications/ART.app/Contents/MacOS/ART

I do not know how to test if my build has the same resources problem as @HIRAM’s has.

HIRAM · December 11, 2023, 10:11am

@Daniel_Catalina If you rename your build directory, does running from /Applications show resources?

Daniel_Catalina · December 11, 2023, 10:17am

i renamed ‘build’ into ‘build.old’ and it works. But in a funny way, it has a different theme
This is how it looks with the build folder in place:

and this is with it renamed:

So some ressources are missing, but I can see the pictures.

HIRAM · December 11, 2023, 10:21am

@Daniel_Catalina Ok, you are replicating my issue exactly.

Daniel_Catalina · December 11, 2023, 10:23am

I’ll have a look further to see how we can hopefully fix it

HIRAM · December 11, 2023, 11:17am

To launch the main executable via command line, some environmental variables must be passed. The Info.plist has a list of these. In command form, it would look like this:

XDG_CONFIG_DIRS=/Applications/ART.app/Contents/Resources/share/gtk-3.0 XDG_CONFIG_HOME=/Applications/ART.app/Contents/Resources/share XDG_DATA_DIRS=/Applications/ART.app/Contents/Resources/share/gtk-3.0 GTK_PATH=/Applications/ART.app/Contents/Resources/etc/gtk-3.0 GTK_IM_MODULE_FILE=/Applications/ART.app/Contents/Resources/etc/gtk-3.0/gtk.immodules XDG_DATA_HOME=/Applications/ART.app/Contents/Resources/share GSETTINGS_SCHEMA_DIR=/Applications/ART.app/Contents/Resources/share/glib-2.0/schemas GDK_PIXBUF_MODULE_FILE=/Applications/ART.app/Contents/Resources/etc/gtk-3.0/gdk-pixbuf.loaders GDK_PIXBUF_MODULEDIR=/Applications/ART.app/Contents/Frameworks LIBDIR=/Applications/ART.app/Contents/Frameworks DATADIR=/Applications/ART.app/Contents/Resources GDK_RENDERING=similar GTK_OVERLAY_SCROLLING=0 /Applications/ART.app/Contents/MacOS/ART

Daniel_Catalina · December 11, 2023, 9:41pm

Thanks for the tip!
What confuses me a bit is that after installing the APP downloaded from you, I was able to run it from command line without doing anything.
The one I compiled crashes. Have you done anything special for this not to happen with the APP you shared?

HIRAM · December 12, 2023, 12:55am

Depends on the crash… it might be quarantined…

Daniel_Catalina · December 12, 2023, 9:43am

@HIRAM Back to the packaging script. I found a problem that is probably not related to what we try to fix, but it is a problem and since we are looking there anyway it might worth fixing.

in the “Registering @rpath in Frameworks folder” it calls for

for dylib in ./${PROJECT_NAME}.app/Contents/Frameworks/*.dylib ; do if [[ $dylib ]]; then sudo install_name_tool -change $(otool -L ${PROJECT_NAME}.app/Contents/MacOS/${PROJECT_NAME} | grep $(basename $dylib) | cut -f2  | cut -d ' ' -f1 ) /Applications/${PROJECT_NAME}.app/Contents/Frameworks/$(basename $dylib) /Applications/${PROJECT_NAME}.app/Contents/MacOS/${PROJECT_NAME} ; fi; done

There are 2 issues here:

it is calling it with sudo, which is not needed as the whole script is called with sudo, this is easy to fix and has no influence on anything else
install_name_tool is throwing an error because if called with -change it expects 3 arguments and receives just 2. I am not sure which path with each path it is trying to replace at this step, if you can help here I can try to fix it and see if it improves anything.

HIRAM · December 12, 2023, 4:20pm

There are actually three arguments, the first is:

$(otool -L ${PROJECT_NAME}.app/Contents/MacOS/${PROJECT_NAME} | grep $(basename $dylib) | cut -f2  | cut -d ' ' -f1 )

The second is

/Applications/${PROJECT_NAME}.app/Contents/Frameworks/$(basename $dylib)

The third is

/Applications/${PROJECT_NAME}.app/Contents/MacOS/${PROJECT_NAME}

This command updates the main executable’s dynamic links from the libraries’ original homes to their new home in the bundle.

To fix the issue with the -cli, I have duplicated this command as:
for dylib in ./${PROJECT_NAME}.app/Contents/Frameworks/*.dylib ; do if [[ $dylib ]]; then sudo install_name_tool -change $(otool -L ${PROJECT_NAME}.app/Contents/Frameworks/${PROJECT_NAME}-cli | grep $(basename $dylib) | cut -f2 | cut -d ' ' -f1 ) /Applications/${PROJECT_NAME}.app/Contents/Frameworks/$(basename $dylib) ${PROJECT_NAME}.app/Contents/Frameworks/${PROJECT_NAME}-cli ; fi ; done

HIRAM · December 12, 2023, 4:29pm

This fixes the above from what I wrote for RT after the fork. Puts cache and options/config dirs in ~/Library/Containers/ART instead of internal to the bundle, for permissions and persistence:

diff --git a/tools/osx/Info.plist.in b/tools/osx/Info.plist.in
index 4b26ba2c7..697baefbe 100644
--- a/tools/osx/Info.plist.in
+++ b/tools/osx/Info.plist.in
@@ -6,11 +6,11 @@
             <key>XDG_CONFIG_DIRS</key>
             <string>/Applications/ART.app/Contents/Resources/share/gtk-3.0</string>
             <key>XDG_CONFIG_HOME</key>
-            <string>/Applications/ART.app/Contents/Resources/share</string>
+            <string>~/Library/Application Support</string>
             <key>XDG_DATA_DIRS</key>
             <string>/Applications/ART.app/Contents/Resources/share/gtk-3.0</string>
             <key>GTK_PATH</key>

HIRAM · December 12, 2023, 5:08pm

Here are my significant launch error messages, when launched from command line.

Error: the user's processing profile path doesn't point to a directory or doesn't exist!

Error: Can't load css file "/Users/rb/art/build/Release/Resources/share/themes/_ART.css"

Message: <data>:4:70Failed to import: Error opening file /Users/rb/art/build/Release/Resources/share/themes/_ART.css: No such file or directory

ERROR: Failed to open file “/Users/rb/art/build/Release/Resources/share/images/wb-camera-small.svg”: No such file or directory

What is the “processing profile path” and how do I set that… ~~is it RT_PATH?~~

options.cc is generating this error.

I’ve renamed the build directory, but it shows it is baked in somewhere. Which file has the original build directory baked in?

The offending file is rtgui/config.h generated by rtgui/CMakeLists.txt using rtgui/config.h.in

This fix results in a launchable bundle:

diff --git a/rtgui/config.h.in b/rtgui/config.h.in
index 2d1f41dbc..ba8f8976c 100644
--- a/rtgui/config.h.in
+++ b/rtgui/config.h.in
@@ -22,6 +22,16 @@
 
 #cmakedefine BUILD_BUNDLE
 #cmakedefine HAVE_UNALIGNED_MALLOC
+#cmakedefine OSX_DEV_BUILD
+
+#if defined(__APPLE__) && !defined(OSX_DEV_BUILD)
+#define DATA_SEARCH_PATH "/Applications/ART.app/Contents/Resources/share"
+#define DOC_SEARCH_PATH "/Applications/ART.app/Contents/Resources"
+#define CREDITS_SEARCH_PATH "/Applications/ART.app/Contents/Resources"
+#define LICENCE_SEARCH_PATH "/Applications/ART.app/Contents/Resources"
+#define LENSFUN_DB_PATH "${LENSFUNDBDIR}"
+#else
+
 #define DATA_SEARCH_PATH "${DATADIR}"
 #define DOC_SEARCH_PATH "${DOCDIR}"
 #define CREDITS_SEARCH_PATH "${CREDITSDIR}"
@@ -29,3 +39,5 @@
 #define LENSFUN_DB_PATH "${LENSFUNDBDIR}"
 
 #endif
+
+#endif

Build updated and PR#16 generated.

Daniel_Catalina · December 13, 2023, 8:19pm

I can confirm, the build linked in this post works on a MacBook Air M2 with MacOS 14.2.

HIRAM · December 14, 2023, 12:17am

Converting the above fix to the CMakeLists.txt instead does work, but the bundle script now misses LICENSE.txt causing the dmg generation to fail.

agriggio · December 14, 2023, 6:19am

Hi,
What are the requirements for dmg exactly? I can take a look at this if you want

HIRAM · December 14, 2023, 7:30am

@agriggio PR#16 is again producing a working dmg! It was only the tip of the iceberg… The changes to options.cc and config.h.in were of course a logical shortcut compared with using cmake. Unfortunately for the installation phase of the cmake build the bundle was relying on the old-fashioned folder structure and not using the paths which are now hardcoded to produce a sandboxed, hardened, entitled app which passes notary. For RT I probably opted for the options.cc and config.h.in change because they were far less complex than repurposing the cmake variables.