Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't link against iconv on apple targets when used by std #2944

Merged
merged 1 commit into from
Oct 9, 2022

Conversation

thomcc
Copy link
Member

@thomcc thomcc commented Oct 7, 2022

See #2870 (and specifically my, erm, rant in #2870 (comment)). I think we should probably remove it outright, but we definitely shouldn't have it in every Rust program by giving it to std.

FIxes #2870

@rust-highfive
Copy link

r? @Amanieu

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

@JohnTitor
Copy link
Member

Makes sensible to me, thanks!
@bors r+

@bors
Copy link
Contributor

bors commented Oct 9, 2022

📌 Commit 8a045af has been approved by JohnTitor

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Oct 9, 2022

⌛ Testing commit 8a045af with merge 8501d72...

@bors
Copy link
Contributor

bors commented Oct 9, 2022

☀️ Test successful - checks-actions, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14
Approved by: JohnTitor
Pushing 8501d72 to master...

@bors bors merged commit 8501d72 into rust-lang:master Oct 9, 2022
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Oct 22, 2022
…acrum

Don't link to `libresolv` in libstd on Darwin

Currently we link `libresolv` into every Rust program on apple targets despite never using it (as of rust-lang#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.
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Oct 24, 2022
…acrum

Don't link to `libresolv` in libstd on Darwin

Currently we link `libresolv` into every Rust program on apple targets despite never using it (as of rust-lang#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.
JohnTitor pushed a commit to JohnTitor/rust that referenced this pull request Oct 24, 2022
…acrum

Don't link to `libresolv` in libstd on Darwin

Currently we link `libresolv` into every Rust program on apple targets despite never using it (as of rust-lang#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.
JohnTitor pushed a commit to JohnTitor/rust that referenced this pull request Oct 24, 2022
…acrum

Update libstd's libc to 0.2.135 (to make `libstd` no longer pull in `libiconv.dylib` on Darwin)

This is to pull in rust-lang/libc#2944.

It's related to rust-lang#102766, in that they both remove unused dylibs from libstd on Darwin platforms. As a result, I'm marking this as relnotes since everybody agreed it was good to add it to the other as well. (The note should be about no longer linking against libiconv -- the libc update is irrelevant).

Might as well have the same reviewer too.

r? `@Mark-Simulacrum`
winterqt added a commit to winterqt/nixpkgs that referenced this pull request Jan 31, 2023
This reverts commit edfbbaf.

I mistakingly believed that once 1.66.0 was used to bootstrap, we'd be
able to remove libiconv from rustc's build-time dependency tree on Darwin.
Sadly, this isn't the case, because src/tools/bootstrap depends on libc.

Additionally, it seems that my assessment in b1834a4
was wrong -- *any* dependency on `libc` will cause a requirement on
libiconv, due to rustc unconditionally linking every library specified
in `link` directives, no matter if the function is actually used.

This was worked around somewhat in rust-lang/libc#2944
by not linking libiconv if libc is only a dependency of std, but this
doesn't apply when `libc` is a dependency of anything else.

Maybe one day we'll just rip out libiconv from `libc` entirely (or hide it
behind a feature flag), but for now, we can just keep it in `buildRustPackage`'s
`buildInputs` by default.
thomcc pushed a commit to tcdi/postgrestd that referenced this pull request Feb 10, 2023
Don't link to `libresolv` in libstd on Darwin

Currently we link `libresolv` into every Rust program on apple targets despite never using it (as of rust-lang/rust#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.
thomcc pushed a commit to tcdi/postgrestd that referenced this pull request Feb 10, 2023
Update libstd's libc to 0.2.135 (to make `libstd` no longer pull in `libiconv.dylib` on Darwin)

This is to pull in rust-lang/libc#2944.

It's related to rust-lang/rust#102766, in that they both remove unused dylibs from libstd on Darwin platforms. As a result, I'm marking this as relnotes since everybody agreed it was good to add it to the other as well. (The note should be about no longer linking against libiconv -- the libc update is irrelevant).

Might as well have the same reviewer too.

r? `@Mark-Simulacrum`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

libiconv is still unconditionally linked to all binaries on macOS
5 participants