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

[Fred Wright]

On Wed, 4 Jun 2025, René J.V. Bertin wrote:
> On Tuesday June 03 2025 21:26:18 Fred Wright wrote:
>
> Thanks!
>
>> 2a) Set SDKROOT to point to the target SDK.
>
> I of course ended up trying my hand at this, and actually succeeding for 10.7. I used this addition in the legacy-support port:
>
> # set host_os_version ${macosx_deployment_target}
> # variant sdk10.7 description {build as if on OS X 10.7} {}
> # if {[variant_isset sdk10.7]} {
> #     set macosx_deployment_target    10.7
> #     configure.sdk_version           ${macosx_deployment_target}
> #     set extraflags          -D__MPLS_TARGET_OSVER=1070

This variable isn't intended to be set directly; it's just a convenience 
macro to avoid defined+value tests on 
__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.  If that *isn't* the case, then something needs to be fixed; I'm 
not sure what the ramifications are of telling the build about the 
alternate target without telling the compiler.

[...]
> then manually installed the static archive with a version suffix to its 
> name. I wasn't really motivated to risk breaking my entire install by 
> installing the corresponding shared libraries though they'd probably 
> work and just make me use the "backported" versions of a handful of 
> functions that my host 10.9.5 has over 10.7 .

There are all kinds of potential problems with using a legacy-support 
library built for a different OS than the one where it's running (becoming 
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.

> Then, in the port this all started for, I added
>
> # platform darwin {
> #     set host_os_version ${macosx_deployment_target}
> #     variant sdk10.7 description {build as if on OS X 10.7} {}
> #     if {[variant_isset sdk10.7]} {
> #         set macosx_deployment_target    10.7
> #         configure.sdk_version           ${macosx_deployment_target}
> #         legacysupport.use_mp_libcxx     yes
> #         # very important: tell the legacysupport headers which OS version we're targetting!
> #         set extraflags                  -D__MPLS_TARGET_OSVER=1070

See above.

> and got a proper 10.7 binary. (Full disclosure: I use a hotpatched 
> official rust toolchain, which always sets the min os version to 10.12 
> so I need vtool to fix that - and had to enable building vtool in 
> port:cctools first).
>
> That binary works ... on 10.9 . I don't think I have yet heard back if 
> it also does on 10.7 but in theory it should esp. since I haven't found 
> any indication that it actually calls any of those functions 10.7 
> doesn't have.
>
> If ever I were to pursue this more seriously I'd probably add 
> legacy-support supports for a select number of older SDKs, which install 
> just that versioned static archive, and maybe add a convenience 
> procedure to the legacy-support PG to add the appropriate TARGET_OSVER 
> macro definition to CPPFLAGS.

Indeed.  The first part is what I mentioned in my earlier post, except 
that, as I said above, you *really* shouldn't be using the static version. 
I filed a ticket to make this actually work properly, but it's a lot of 
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).

Enhancing the PG is something I'd already thought about, but hadn't 
mentioned.  This would only be for adding the dependency and adjusting the 
linker options; your TARGET_OSVER stuff is inappropriate as long as 
macosx_deployment_target works as it should.

> Re 10.6 : I tried that first. Turns out that this would add a backported 
> function that calls a function (chk_fail or something like that) which 
> is itself unavailable on 10.9 .

Yes, I also ran across that.  They changed how that mechanism works in 
10.7, so __chk_fail() went away.  I already have a fix for that locally.

Fred Wright