I googled the "file system relative paths not allowed in hardened programs” and 
the results made me remember a similar issue I have seen recently.

I was loading a dylib through ctypes, and suddenly this stopped working. The 
problem eventually turned out to be that another dylib (a dependency of the 
dylib I was loading) had its quarantine flag set. That was never a problem 
before, but suddenly (last summer?) it has started to be a problem.

The solution turned out to be to run `xattr -d com.apple.quarantine 
blablabla.dylib` on the problem library.

Not sure whether this is your problem or not, but it’s worth a shot. If (big 
if) this is a dynamic loader problem you’re in for a hard time: it used to be 
possible to debug these by setting the various DYLD_ environment variables to 
“look over the shoulder” of the dynamic loader to see what it is doing, but 
nowadays these environment variables are always cleared automatically (unless 
you have the com.apple.security.cs.allow-dyld-environment-variables 
entitlement, so if there’s a third party app somewhere in the chain that’s a 
no-no).
--
Jack Jansen, <jack.jan...@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



> On 6 Jan 2022, at 19:57, Chris Barker via Pythonmac-SIG 
> <pythonmac-sig@python.org> wrote:
> 
> OK,
> 
> I've gotten a bit farther into debugging this.
> 
> Turns out it's not about that particular error, it's probably about the fact 
> that modules couldn't be loaded at start up due to security checks in the new 
> OS.
> 
> We've signed the app but that's not fixing it :-( 
> 
> Starting the app at the command line at least gets me output, and I see a lot 
> of errors like this:
> 
>   File "PyInstaller-3.4-py3.6.egg/PyInstaller/loader/pyiboot01_bootstrap.py", 
> line 149, in __init__
>   File "ctypes/__init__.py", line 348, in __init__
> OSError: dlopen(OpenGL, 10): no suitable image found.  Did find:
>     file system relative paths not allowed in hardened programs
> 
> I am really confused as to how they could disallow relative paths -- how else 
> could you bundle a library?
> 
> though maybe it's a lib outside the bundle that's using relative paths ?
> 
> More digging needed, but if anyone has any ideas, I'm all ears.
> 
> Also:
> 
> - Has anyone gotten a PyInstaller App to work on OS-X 11 ?
> 
> - Even better, one that uses OpenGL?
> 
> Thanks,
> 
> -CHB
> 
> 
> 
> On Thu, Dec 16, 2021 at 11:21 AM Chris Barker <chris.bar...@noaa.gov> wrote:
> I've just got a new mac with OS-X 11.6 (still Intel).
> 
> But when I try to run a PyInstaller built application, I get this error:
> 
> No document available for {'mime': 'application/x-maproom-project-zip', 
> 'loader': <maproom.loaders.project.ZipProjectLoader object at 
> 0x7f9669ce6e10>, 'uri': 'template://default_project.maproom'}
> 
> And the app won't start.
> 
> This has worked just fine on numerous previous OS-X versions.
> 
> I have the source code, but the developer that built it is no longer with us, 
> so it'll take b e a bit to get up to speed, and I don't even know where to 
> start! Is this a PyInstaller issue? or a code issue, or ???
> 
> Hints:
> 
> The application is called MapRoom (maproom) it works with "projects" that are 
> essentially a zip file with all the info required in it.
> 
> I think, on startup, it loads a empty default project, presumably 
> "default_project.maproom"
> 
> So I think that's where the app startup code is barfing, not having the mime 
> type registered properly. But where / how am I supposed to do that?
> 
> or maybe it's not a mime type registration issue, but simply that the 
> template can't be found -- so a path issue in the App bundle??
> 
> Anyway, I'll be digging into this deeper in the source code, but if anyone 
> has seen anything like this, any hints would be appreciated!
> 
> Thanks,
> 
> -CHB
> 
> 
> 
> 
> 
> 
> 
>  
> 
> -- 
> 
> Christopher Barker, Ph.D.
> Oceanographer
> 
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
> 
> chris.bar...@noaa.gov
> 
> 
> -- 
> 
> Christopher Barker, Ph.D.
> Oceanographer
> 
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
> 
> chris.bar...@noaa.gov
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Reply via email to