#69867 closed defect (fixed)
legacy-support headers should work with later SDK versions
Reported by: | fhgwright (Fred Wright) | Owned by: | fhgwright (Fred Wright) |
---|---|---|---|
Priority: | Low | Milestone: | |
Component: | ports | Version: | 2.9.3 |
Keywords: | Cc: | ryandesign (Ryan Carsten Schmidt), mascguy (Christopher Nielsen), barracuda156 | |
Port: | legacy-support |
Description
It's ordinarily legal (with some limitations) to build for a given OS target while using an SDK for a later OS version. In some cases, the legacy-support
headers may not work properly in this situation. One known case is #69838.
It would be desirable (though not high priority) to fix this.
Change History (22)
comment:1 Changed 6 months ago by fhgwright (Fred Wright)
comment:2 Changed 6 months ago by Christopher Nielsen <mascguy@…>
comment:3 Changed 6 months ago by fhgwright (Fred Wright)
One thing that would help in testing this issue would be to teach the build procedure to honor SDKROOT
. Currently it doesn't.
comment:4 follow-up: 5 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
The build procedure of what? If you mean you are setting the SDKROOT
environment variable in your shell and MacPorts is not passing it through to the builds, that's intentional; most environment variables are deliberately not passed through. You can override configure.sdk_version
or configure.sdkroot
on the command line if you want to test a different SDK, e.g. sudo port configure configure.sdk_version=11
(this assumes you have the macOS 11 SDK in the standard location) or sudo port configure configure.sdkroot=/path/to/MacOSX11.sdk
(for an SDK located anywhre).
comment:5 Changed 6 months ago by fhgwright (Fred Wright)
Replying to ryandesign:
The build procedure of what? If you mean you are setting the
SDKROOT
environment variable in your shell and MacPorts is not passing it through to the builds, that's intentional; most environment variables are deliberately not passed through. You can overrideconfigure.sdk_version
orconfigure.sdkroot
on the command line if you want to test a different SDK, e.g.sudo port configure configure.sdk_version=11
(this assumes you have the macOS 11 SDK in the standard location) orsudo port configure configure.sdkroot=/path/to/MacOSX11.sdk
(for an SDK located anywhre).
No, I mean the project's build procedure. Testing it as a port would add unnecessary friction.
An example of why legacy-support
should have its own ticket component, since this isn't a ports
issue. :-)
comment:6 Changed 6 months ago by fhgwright (Fred Wright)
Another case where this would fail is building on 10.4 with a 10.5+ SDK. The headers provided by 10.4 legacy-support
to correct the omissions in the 10.4 SDK would override the non-omitted versions in the 10.5+ SDK, with a variety of potential problems. The decision to incorporate the "missing" headers needs to be made at the time the headers are used, not the time they're installed.
comment:7 Changed 5 months ago by fhgwright (Fred Wright)
comment:8 Changed 5 months ago by fhgwright (Fred Wright)
comment:9 Changed 5 months ago by fhgwright (Fred Wright)
comment:10 Changed 5 months ago by fhgwright (Fred Wright)
comment:11 Changed 5 months ago by fhgwright (Fred Wright)
comment:12 Changed 5 months ago by fhgwright (Fred Wright)
comment:13 Changed 5 months ago by fhgwright (Fred Wright)
comment:14 Changed 5 months ago by fhgwright (Fred Wright)
comment:15 Changed 4 months ago by fhgwright (Fred Wright)
comment:16 Changed 4 months ago by fhgwright (Fred Wright)
comment:17 Changed 4 months ago by fhgwright (Fred Wright)
comment:18 Changed 4 months ago by fhgwright (Fred Wright)
comment:19 Changed 4 months ago by fhgwright (Fred Wright)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
In df195e0aea5b49d03c149970ddb303bcada0f7d7/macports-legacy-support (master):