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
