Opened 3 years ago

Last modified 2 months ago

#59135 assigned defect

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

Reported by: kencu (Ken) Owned by: cjones051073 (Chris Jones)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: fhgwright (Fred Wright), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), mascguy (Christopher Nielsen)
Port: legacy-support, legacy-support-devel

Description (last modified by 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...

Change History (12)

comment:1 Changed 3 years ago by kencu (Ken)

Description: modified (diff)

comment:2 Changed 3 years ago by kencu (Ken)

Description: modified (diff)

comment:3 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by 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...

comment:5 Changed 20 months ago by 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... ).

comment:6 Changed 20 months ago by 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...

comment:7 Changed 14 months ago by kencu (Ken)

Cc: cjones051073 removed
Owner: changed from kencu to cjones051073

comment:8 Changed 11 months ago by fhgwright (Fred Wright)

Cc: fhgwright added

comment:9 Changed 7 months ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: MarcusCalhoun-Lopez added

comment:10 Changed 7 months ago by 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.

comment:11 Changed 7 months ago by 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.

comment:12 Changed 2 months ago by mascguy (Christopher Nielsen)

Cc: mascguy added
Note: See TracTickets for help on using tickets.