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

[Fred Wright]

On Fri, 30 May 2025, René J.V. Bertin wrote:

> Quick question to the legacysupport maintainers: is there a way to build 
> the library as if on an older OS (10.7 or even 10.6) than the host OS 
> (10.9.5 in my case)?
>
> I do mean "by hand" of course, or using build variants in a private 
> version of the port.

In theory, this would be fairly straightforward.  In practice, not so 
much.

There are essentially two ways of doing it:

1) Build for the desired target OS, while using the default SDK for the 
build OS.

2) Build for the desired target OS, using the SDK for the target OS.

Method #1 works in some cases, but not others.

Method #2 subdivides:

2a) Set SDKROOT to point to the target SDK.

2b) Provide the include and library paths for the appropriate directories 
in the target SDK.

Method #2a fails miserably in most cases, and typically in really bizarre 
ways.

Method #2b works fine for the includes, but is hit-or-miss for the 
libraries, often failing bizarrely.

Method #1 seems like the shortest path to the cheese, since it (probably) 
doesn't involve debugging weird toolchain issues.  I've already made some 
progress in that area (though not for the upcoming release).

The long-term plan is to provide versions of the library built for 
specific OS versions, which could be used straightforwardly as SDK-like 
build dependencies.  Note that this isn't needed for the headers, which 
are already designed to work across OS versions.

In the particular case of rust, there's an ugly kludge that relies on an 
undocumented linker feature to provide dummy symbols for certain functions 
*not* provided by that build of the library, so that the library for the 
current OS can be used to link the target for the older OS without running 
afoul of missing symbols.  It's based on the particular build OS and 
particular target OS that Marcus was using, and only for the particular 
functions that rust uses.  I.e., it's not very general, in addition to 
relying on an undocumented linker feature (which provokes warnings on 
10.6), not scaling well, and not being very maintainable.

To avoid polluting the normal library with the extra symbols, they're only 
added to the "system passthrough" version of the library, so using this 
feature requires linking against the "system" version, even though that's 
not otherwise needed in this context.

Fred Wright