Closed daprice closed 2 years ago
I am afraid this goes exactly in the opposite direction of #11. I cannot merge this as it is, as it will cause back the issue reported there. I guess we have to figure out a way to patch this issue in a way that still does not break loading the libraries in hardened programs, perhaps try
with except OSError
?
Same observation here. My app using darkdetect 0.5.0 fails to codesign because of those paths. With v0.3.0 it works fine.
I pushed a tentative fix in the branch https://github.com/albertosottile/darkdetect/tree/patches. Does the code in there work for you in hardened programs?
I’m only able to test on Monterey 12.0.1 on Intel at the moment, but that branch works for me, both as a Blender add-on (tested across Blender 2.93.5, 2.91, and 2.83) and the command line. However, I’m now unable to reproduce the issue at all even with darkdetect 0.5.0, so I suspect this is the result of a change in Monterey and this test doesn’t prove anything conclusive. I don’t have a Big Sur installation to test on.
Yep, this version works for me. I just successfully signed and notarized my app with this patch version on macOS 11.6. Thanks for resolving this!
Thanks for your help. Fixed in cd720058ed981416b80060c9ec886db76ab9162f. Closing this now.
When using darkdetect 0.4.0-0.5.0 within an application on MacOS (in my case, in a Blender add-on), it would give the error
OSError: dlopen(AppKit.framework/AppKit, 6): no suitable image found. Did find: file system relative paths not allowed in hardened programs
from line 17 of_mac_detect.py
.I’m not sure if this is best practice, but I changed the paths in line 17-18
_mac_detect.py
to absolute paths, which seems to have fixed the error and allows darkdetect to be used both from the command line and within Blender. I have only tested this fix on Big Sur 11.6 on both Intel and M1, not on any other version.