Package portability on macOS: what system-installed libraries is it safe to rely on?

Python Help
1

I’m trying to produce wheels for packages, which happen to be hosted on PyPI but for which there might not always be a pre-built wheel for the exact OS + python version combination or in some cases where I need to build from source for other reasons.

The goal is to make these wheels self-contained (using as generic a mechanism as possible) such that they should work fine on any Mac OS 10.14+ system.

I’m using delocate to try to achieve that. However, by default, linked libraries under /usr/lib are not included in the repackaged wheel. I know how to modify that behavior (so that’s not the question I’m trying to ask).

What I’m looking for is general advice on how much I can rely on those libraries that are presumably shipped with every Mac OS installation and what to look out for. There seems to be no official documentation from Apple regarding what libraries and which versions are shipped with each version of Mac OS and information on this topic is generally scarce, so any pointers on this topic would be welcome.

2

When you build for macOS you can set an env var that sets the earliest version of macOS that the code must work on. xcode will then sort of the compile and link against that SDK. You may have problems if you need a newer version of the library then apple shipped on your base macOS version.

I doubt that its a good idea to take a library (.so or .dylib) from a newer macOS and try to use on an older macOS. Better to build your own version and bundle it.

I often use a build of a library I need from homebrew and include that in my macOS kits/Apps.