OSX: Fails to load when not in "/Application"

[TurtleWilly]

Short description

RawTherapee.app fails to load when it is not installed directly in the system directory "/Applications", e.g. if user has it installed in "~/Applications" or on a separate partition.

On initial installation and the subsequent launch OS X's CoreServiceUIAgent reports File /Volumes/Storage/Applications/RawTherapee.app/Contents/MacOS/bin/rawtherapee-bin failed on rPathCmd /Applications/RawTherapee.app/Contents/Frameworks/libomp.dylib and Fails dylib check, afterwards RawTherapee.app via com.apple.xpc.launchd: Service exited with abnormal code: 126.

Moving the application bundle to /Applications fixes things. But moving it out again and it will continue to Service exited with abnormal code: 126, albeit the inital report by CoreServiceUIAgent no longer seems to happen.

Setting up an ugly softlink fixes the issue too:

$ cd "/Applications"
$ ln -s /Volumes/Storage/Applications/RawTherapee.app RawTherapee.app

Steps to reproduce

• Install the application in a path that is NOT "/Applications".
• Launch it.

Expected behavior
Installing the application in any user controlled path should not block it from launching, e.g. the user may not have write permissions in the system "/Applications" directory.

Additional information

• Version of RawTherapee: 5.8.0
• Version of your operating system: latest OS X 10.10.5 (14F2511)

Other useful information:
n/a

[Thanatomanic]

Possible duplicate of #6045

[Benitoite]

10.10 is highly ancient, and the installation procedures used there are no longer relevant to modern RawTherapee. You are experiencing expected behavior. ~/ is a relative path and not allowable in hardened runtime, which is used in RawTherapee.

[the-real-tokai]

"/Users//Application" or short "~/Applications" is nothing ancient and is not no longer relevant. RawTherapee feels broken. I can't install it for that reason either. I don't seem to have problems like that with any of my other apps. RawTherapee probably simply should use the proper bundle paths, not some random hardcoded system paths to lookup its dylibs, then it probably would just work?

[Benitoite]

@the-real-tokai There are no such thing as random hardcoded system paths in RawTherapee for macOS.

@Thanatomanic Duplicate of #6045.

[the-real-tokai]

@Benitoite:

the paths looks pretty much hard-coded to me in your launch script (RawTherapee.app/Contents/MacOS/rawtherapee).

…
app="/Applications/RawTherapee.app"
lib="${app}/Contents/Frameworks"
resources="${app}/Contents/Resources"
etc="${resources}/etc"
…

[Benitoite]

@the-real-tokai did you have a question about the current dev branch?

[the-real-tokai]

@Benitoite I did not ask a question (no question marks). I was only commenting on the situation in the latest public binary release that is currently available to us as macOS users. I have no idea how I could make use of your "dev branch": I just want to click an icon. 😎

[Benitoite]

Ok. Post a feature request if you wish that someone would write an installer for your purposes. Comments about releases are good for the discuss forum, whereas the GitHub crowd here usually focuses work on the dev branch.

[the-real-tokai]

@Benitoite Sorry, I'm not sure what you're on about. 😎

I'm merely commenting about the bug @TurtleWilly has reported here. The public version of RawTherapee.app for macOS seems to use an odd setup with a shell script as its main executable. That shell script has absolute paths referenced. Which is probably what breaks things on typical "we don't have admin rights, so we can write to '/Applications'" setups.

[Benitoite]

Again, you are commenting on a years-old code structure that has nothing to do with current code... please, take a look at dev branch! It's /completely/ different!

Please check the following before you report:

1. Search through the open and closed issues on GitHub for keywords related to your issue. Avoid creating duplicates. Many issues from the latest release version will already have been fixed.
2. Read http://rawpedia.rawtherapee.com/How_to_write_useful_bug_reports to ensure you provide as much information as possible.

[Benitoite]

Also, it's worth noting that 5.9 will not have fixed that issue... it's actually doubled-down into /Applications with the addition of app notarization, of which the hardened runtime is a pre-requisite. The notarization of the package is done when the build has completed using an Apple team credential. Lesser packaging methods require a non-default methodology of launch in more recent macOS, and now in which gatekeeper polls the ticket at each launch, no longer offering a quarantined area for apps that have either had their tickets previously checked or that you have allowed into quarantine via clicking OK on an explicit malware warning. Also, macOS 14 is probably about go alpha, meaning potentially even greater access to system integrity features in the next few Ventura dot releases. I have always the goal in mind to maintain the app package a just click an icon type of app on modern macOS.