-
Notifications
You must be signed in to change notification settings - Fork 303
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OSX: Fails to load when not in "/Application" #6580
Comments
Possible duplicate of #6045 |
10.10 is highly ancient, and the installation procedures used there are no longer relevant to modern RawTherapee. You are experiencing expected behavior. |
"/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? |
@the-real-tokai There are no such thing as random hardcoded system paths in RawTherapee for macOS. @Thanatomanic Duplicate of #6045. |
the paths looks pretty much hard-coded to me in your launch script (
|
@the-real-tokai did you have a question about the current dev branch? |
@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. 😎 |
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. |
@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. |
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:
|
Also, it's worth noting that 5.9 will not have fixed that issue... it's actually doubled-down into |
@Benitoite Is there a way to add a message to the "installer" or the application launcher to warn the user that RawTherapee must be installed in /Applications without a name change? That would cut down the number of people who are unaware of the requirements. I also noticed that the main rawtherapee.com page does not give installation instructions. It would be nice if the page redirected to some instructions upon clicking one of the downloads or something like that... |
@Lawrence37 Yes, I can add a message to the fancy dmg background to that effect. "To install RawTherapee, drag the RawTherapee icon into the Applications folder." And "To run RawTherapee, open /Applications and double click on the RawTherapee icon." |
#6923 generated adds instructions in the fancy dmg background png and the text install readme file at the zip level. The general instructions for macOS are:
|
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
andFails 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 toService 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:
Steps to reproduce
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
Other useful information:
n/a
The text was updated successfully, but these errors were encountered: