@oskardrums In reference to MacOS: Installing Frameworks ; if the intended is to share the libraries in fat-darwin amongst other applications and prorams on a MacOS system, I’afraid it is a losing proposition to keep shared libraries on MacOS in the application bundle’s Framework directory.
The current thinking at Apple is clearly geared towards sandboxed applications meaning that applications are using their “own” resource and/or use external (w.r.t to the scope of their sandbox) resources only by special permission or intermediation by specific security-focus services of MacOS. So, any attempt to deviate too much from their intended “architecture” is likely to run in constraints imposed on the system to enhance its security.
I think, but that could mean a significant overhaul of your development setup, you should split up the application bundle into
-
Put the SWI-Prolog user facing applications in the SWI-Prolog.app bundle. That is, the ones based on Qt and X. The specific Qt and X libraries used for these applications are probably best left in the application bundle’s Frameworks directory,
-
make the rest a “global” framework bundle installed in
/Library/Frameworks. This is very similar to how the python distribution by python.org for MacOS is organised. MacPorts takes a similar approach. Applications with a graphical UIF are made application bundles and put in/Applications, other stuff is put under a common path/opt, and dylibs have absolute paths in their load commands.
Even though I suspect Apple from “nefarious” commercial reasons to put this kind of hurdles on dylib loading paths, there are genuine security reasons to do so. Having said that, when developing I too yearn for the past where MacOS was still more *nix like.
A bit of a warning: Much of Apple’s technical developer documentation relevant for this subject has now the status “archived”. I couldn’t find “current” documentation on frameworks and the current constraints applicable to frameworks.
/Twan