#71943: Explain legacy-support issue with precompiled rustc
-----------------------------+---------------------------------
Reporter: fhgwright | Owner: MarcusCalhoun-Lopez
Type: request | Status: reopened
Priority: Low | Milestone:
Component: ports | Version:
Resolution: | Keywords:
Port: legacy-support |
-----------------------------+---------------------------------
Comment (by fhgwright):
Replying to [comment:5 kencu]:
> Hi Marcus! I hope you are well.
>
> I don't think there is any source for official documentation of the
magic linker symbols, but the 5 references above including the source code
reference in ld64 in particular are - as a whole - quite comprehensive
about how the symbol hiding/showing mechanism works I found.
If the best available documentation is a combination of inadequately
commented source code and discussions among people trying to figure this
out themselves, then that's pretty pathetic. :-) And if Apple decided they
no longer wanted to use this mechanism, they'd probably just delete
whatever documentation existed anyway.
I think I now understand the scenario for this issue. I'd previously
mistakenly assumed that this related to an upstream precompiled binary.
The fact that I was looking at this near the time of looking into another
issue involving (incorrectly) patching an upstream precompiled binary to
use `legacy-support` probably encouraged that misconception.
So (correct me if I'm wrong), the scenario is:
1. Building `rustc` locally on a 10.10 system.
2. Targeting 10.7, so that it can run on 10.7+.
3. Using the 10.7 Apple SDK, including a libSystem built for 10.7.
4. Linking against the system's `legacy-support` library, built for 10.10.
The issue arises from the inconsistency between 3 and 4, which results in
a "symbol gap".
There are a couple of possible ways to fix this:
1. Building with the 10.10 SDK instead of the 10.7 SDK. This might not
have worked with the `legacy-support` headers at the time of #59135, but
it would certainly work today. Building `legacy-support` clients with any
SDK no earlier than the target OS is now fully supported and regularly
tested. But `rustc` itself may or may not build correctly in this case.
2. Linking against a version of the `legacy-support` library built for an
OS no later than 10.7. That would almost certainly work, except that that
library isn't normally available on 10.10. A brute-force solution would
be for the `rustc` build to download the `legacy-support` sources and
build its own copy of the library, just for build-time linking. Given
that the build time for `legacy-support` is literally seconds, that would
be a drop in the bucket for build time, and the only real issue would be
how to pick the version of `legacy-support` to download.
The approach that's currently taken is to kludge some extra dummy symbols
into the library to make build-time linking happy, via the "magic symbol"
hack. I think I now know the answer to a couple of ancillary questions:
Q: Why just those specific calls, which is only a small subset of all of
them?
A: Because those are the specific calls referenced by `rustc`.
Q: Why only in the "system" version of the library?
A: To avoid polluting the "normal" version of the library with the extra
symbols. It just means that `rustc` needs to link against the "system"
library to see those symbols, even though that would otherwise be
unnecessary.
I think the best overall solution to this problem is to provide a "legacy-
support SDK", with a library built for a sufficiently old OS. This is
consistent with the normal build approach, where one links against a
library in the SDK for the target system, rather than a library in the
running system. Strictly speaking, such a library doesn't need any real
content at all, and only needs to provide symbols. In fact, Apple moved
to this approach in the 10.11+ SDKs, with the "libraries" being just text-
file façades listing what symbols are provided by the corresponding "real"
libraries. But I'm pretty sure that isn't supported by older linkers, so
it would be a terrible approach for `legacy-support`. It might in
principle be possible to come up with some means of creating a stripped-
down library with all the code removed, but the `legacy-support` library
is so small that it's not worth the trouble.
If all of the above is correct, this ticket can be closed, and I'll open
another with a more accurate description of the potential enhancement.
--
Ticket URL: <https://trac.macports.org/ticket/71943#comment:6>
MacPorts <https://www.macports.org/>
Ports system for macOS