Don't link to libresolv in libstd on Darwin

[thomcc]

Currently we link libresolv into every Rust program on apple targets despite never using it (as of #44965). I had thought we needed this for getaddrinfo or something, but we do not / cannot safely use it.

I'd like to fix this for libiconv too (the other library we pull in. that's harder since it's coming in through libc, which is rust-lang/libc#2944)).

---

This may warrant release notes. I'm not sure but I've added the flag regardless -- It's a change to the list of dylibs every Rust program pulls in, so it's worth mentioning.

It's pretty unlikely anybody was relying on this being pulled in, and std does not guarantee that it will link (and thus transitively provide access to) any particular system library -- anybody relying on that behavior would already be broken when dynamically linking std. That is, there's an outside chance something will fail to link on macOS and iOS because it was accidentally relying on our unnecessary dependency.

(If that does happen, that project could be easily fixed by linking libresolv explicitly on those platforms, probably via #[link(name = "resolv")] extern {}, -Crustc-link-lib=resolv, println!("cargo:rustc-link-lib=resolv"), or one of several places in .config/cargo.toml)

---

I'm also going to preemptively add the nomination for discussing this in the libs meeting. Basically: Do we care about programs that assume we will bring libraries in that we do not use. libresolv and libiconv on macOS/iOS are in this camp (libresolv because we used to use it, and libiconv because the libc crate was unintentionally(?) pulling it in to every Rust program).

I'd like to remove them both, but this may cause link issues programs that are relying on std to depend on them transitively. (Relying on std for this does not work in all build configurations, so this seems very fragile, and like a use case we should not support).

More generally, IMO we should not guarantee the specific set of system-provided libraries we use (beyond what is implied by an OS version requirement), which means we'd be free to remove this cruft.

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

+1 to relnotes; thanks for tagging.

No particular opinion on the change itself but it seems reasonable to me. The code change itself looks OK.

[joshtriplett]

👍 for making this change and documenting it in compatibility notes.

[joshtriplett]

We discussed this in today's @rust-lang/libs meeting, and agreed that we can make this change. We should document this in the release notes.

[Mark-Simulacrum]

r=me per discussion in meeting (as noted above), not sure if we were blocking on anything else

[thomcc]

We aren't, the discussion in the meeting was that we should just land it, and that it did not need FCP.

@bors r=Mark-Simulacrum

[bors]

📌 Commit 2618f7a has been approved by Mark-Simulacrum

It is now in the queue for this repository.