legacy-support: functions properly only if os.version = deployment target

[kencu (Ken)]

while debugging some unexpected behavior recently, I realized the build system was setting the mmacosx-version-min to a value of 10.7 on a host os of 10.11. What this did was enable a bunch of replacement definitions in the legacy support headers that collided with definitions in the SDK.

This can be fixed by making the legacy support definitions exactly match the newer SDK's definitions (eg getattrlistat)' or by removing the deployment target change...

But it brought forth the idea that the exact way the legacysupport library is built depends on both the host os version but also the setting of the deployment target.

It may or may not be possible to build legacy support for an older system - that idea would have to be explored and tested -- but for now, at least, making sure the host os version matches the deployment target (and the sdk version?) is the only reliable way of using the legacy support library and PG...

[jmroot (Joshua Root)]

Sounds like the legacysupport header definitions should change based on MAC_OS_X_VERSION_MAX_ALLOWED instead of MAC_OS_X_VERSION_MIN_REQUIRED.

[kencu (Ken)]

Yes, for the headers/SDK definitions.

But then the library function replacements should still hinge on MIN_REQUIRED as that is what’s in the system library...

I think the library may have to be unique to each os.version and so setting for a deployment target less than the os won’t reliably work,

Unless do something like static linking, etc.

Luckily it’s not a common use case on MacPorts...

[kencu (Ken)]

This comes up again now, trying to build clang-devel on 10.11 using legacy-support.

When 10.11 builds legacy-support, the defines are such that function wrapping is disabled.

However, when clang-devel builds compiler-rt on 10.11, it sets the deployment target to something lower, and then the defines are such that function wrapping is enabled. So legacy-support renames some functions, like sysconf, to macports_legacysupport_sysconf, but that function does not exist in the library, so there is a link error.

Fixing this properly is kind of tricky. For now, I will either force function wrapping off for the clang-devel build, or reset the deployment target for compiler-rt to the current system... (I'm just pondering what, if any, deleterious effect that might have on compiler-rt... ).

[kencu (Ken)]

I wonder what would happen if we built legacy-support with an older deployment target, say 10.6, on 10.11... then the legacysupport library would have all the needed older system symbols in it.

Then, when we build software with the legacy support headers, if have the deployment target set to the current system, the headers would ask for the current symbols from the library, but if we build software with the deployment target set older, like compiler-rt does, then the needed symbols would be found in the legacy-support library, and (I think) the software could actually be deployed on the older system and it would (hopefully) work. Especially as in this case, where it's linked statically...

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In terms of the symbols in the library, the following ​commit might be relevant.
It uses the __asm("$ld$add$os10.x$...") trick so that MACOSX_DEPLOYMENT_TARGET is respected.

[kencu (Ken)]

I suspect that kind of fix is the only kind of fix that might realistically work... well done, Marcus. Hope it pans out.