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
