build legacy-support for an older OS than the host OS?

[René J.V. Bertin]

On Wednesday June 04 2025 12:13:28 Fred Wright wrote:

>__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ all over the place.  Your 
>setting two lines above should have done this, anyway, if it works as 
>expected.  

I'll try to remember to test that.

>larger as the version mismatch grows).  This is why static linking should 
>be avoided like the plague.  As long as you use dynamic linking, then at 
>runtime it will use the normal installed legacy-support library, which is 
>presumably matched to the OS where it's running.  It's perfectly OK that 
>this isn't the one it linked with.

You did say earlier that this means you'd have to link with the library that re-exports libSystem, otherwise it's probably not going to be perfectly OK if a symbol is provided by a different library.

There's another reason for static linking in my particular test case. OpenWV is a browser plugin (alternative to libwidevine) that runs in a very strict sandbox. It cannot have dependencies in non-sanctioned places.
For now it's in a testing phase anyway, and there's of course no need to make any big changes to legacy-support that would only benefit this particular project.

>work for what should be a rare use case (and you may recall my earlier 
>post about how using static linking in the clang case is motivated solely 
>by a deficiency in the depndency mechanism).

I probably read that too diagonally, I didn't catch that it was about the static library.

R.