-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
rustc is now dynamically linked to zlib #74420
Comments
I certainly expect libz to be available on Linux and BSDs, so I don't think it's a problem there. What happens on Windows/MacOS? |
On the latest |
This would be fine on NixOS but the Python wrapper around EDIT: opened #74441 for the NixOS fix. |
On |
This comment has been minimized.
This comment has been minimized.
@mati865 what are you claiming exactly? I feel like more discussion is needed to decide what to do. |
I believe I know how to link zlib statically. From discussion in #74395 this seem like correct approach. |
I'll be away for few hours so I decided to post my findings in case somebody else wants to work on it. MSVC builds probably don't have zlib linked at all since LLVM will ignore Linux builds of Rust have ThinLTO enabled and that makes them link to LLVM dynamically: Lines 595 to 597 in c2dbebd
To avoid zlib dependency here we have to patch LLVM's CMake files. Do we want to do it? |
In working on cross-compiling I think that enabling a static build of zlib would help with this, and I'd be happy to help test any proposed solutions. |
@shepmaster your issue is a bit different. See here and the discussion in PR from the comment: Lines 180 to 186 in e2e29de
While it cannot be called proper fix for your issue linking zlib statically will make work without passing |
I've patched LLVM to link with static zlib but it fails on Ubuntu 20.04 VM with:
AFAICT the error is legit. @rustbot release-assignment |
bootstrap.py: patch RPATH on NixOS to handle the new zlib dependency. This is a stop-gap until rust-lang#74420 is resolved (assuming we'll patch beta to statically link zlib). However, I've been meaning to rewrite the NixOS support we have in `bootstrap.py` for a while now, and had to in order to cleanly add zlib as a dependency (the second commit is a relatively small delta in functionality, compared to the first). Previously, we would extract the `ld-linux.so` path from the output of `ldd /run/current-system/sw/bin/sh`, which assumes a lot. On top of that we didn't use any symlinks, which meant if the user ran GC (`nix-collect-garbage`), e.g. after updating their system, their `stage0` binaries would suddenly be broken (i.e. referring to files that no longer exist). We were also using `patchelf` directly, assuming it can be found in `$PATH` (which is not necessarily true). My new approach relies on using `nix-build` to get the following "derivations" (packages, more or less): * `stdenv.cc.bintools`, which has a `nix-support/dynamic-linker` file containing the path to `ld-linux.so` * reading this file is [the canonical way to run `patchelf --set-interpreter`](https://github.com/NixOS/nixpkgs/search?l=Nix&q=%22--set-interpreter+%24%28cat+%24NIX_CC%2Fnix-support%2Fdynamic-linker%29%22) * `patchelf` (so that the user doesn't need to have it installed) * `zlib`, for the `libz.so` dependency of `libLLVM-*.so` (until rust-lang#74420 is resolved, presumably) This is closer to how software is built on Nix, but I've tried to keep it as simple as possible (and not add e.g. a `stage0.nix` file). Symlinks to each of those dependencies are kept in `stage0/.nix-deps`, which prevents GC from invalidating `stage0` binaries. r? @nagisa cc @Mark-Simulacrum @oli-obk @davidtwco
bootstrap.py: patch RPATH on NixOS to handle the new zlib dependency. This is a stop-gap until rust-lang#74420 is resolved (assuming we'll patch beta to statically link zlib). However, I've been meaning to rewrite the NixOS support we have in `bootstrap.py` for a while now, and had to in order to cleanly add zlib as a dependency (the second commit is a relatively small delta in functionality, compared to the first). Previously, we would extract the `ld-linux.so` path from the output of `ldd /run/current-system/sw/bin/sh`, which assumes a lot. On top of that we didn't use any symlinks, which meant if the user ran GC (`nix-collect-garbage`), e.g. after updating their system, their `stage0` binaries would suddenly be broken (i.e. referring to files that no longer exist). We were also using `patchelf` directly, assuming it can be found in `$PATH` (which is not necessarily true). My new approach relies on using `nix-build` to get the following "derivations" (packages, more or less): * `stdenv.cc.bintools`, which has a `nix-support/dynamic-linker` file containing the path to `ld-linux.so` * reading this file is [the canonical way to run `patchelf --set-interpreter`](https://github.com/NixOS/nixpkgs/search?l=Nix&q=%22--set-interpreter+%24%28cat+%24NIX_CC%2Fnix-support%2Fdynamic-linker%29%22) * `patchelf` (so that the user doesn't need to have it installed) * `zlib`, for the `libz.so` dependency of `libLLVM-*.so` (until rust-lang#74420 is resolved, presumably) This is closer to how software is built on Nix, but I've tried to keep it as simple as possible (and not add e.g. a `stage0.nix` file). Symlinks to each of those dependencies are kept in `stage0/.nix-deps`, which prevents GC from invalidating `stage0` binaries. r? @nagisa cc @Mark-Simulacrum @oli-obk @davidtwco
bootstrap.py: patch RPATH on NixOS to handle the new zlib dependency. This is a stop-gap until rust-lang#74420 is resolved (assuming we'll patch beta to statically link zlib). However, I've been meaning to rewrite the NixOS support we have in `bootstrap.py` for a while now, and had to in order to cleanly add zlib as a dependency (the second commit is a relatively small delta in functionality, compared to the first). Previously, we would extract the `ld-linux.so` path from the output of `ldd /run/current-system/sw/bin/sh`, which assumes a lot. On top of that we didn't use any symlinks, which meant if the user ran GC (`nix-collect-garbage`), e.g. after updating their system, their `stage0` binaries would suddenly be broken (i.e. referring to files that no longer exist). We were also using `patchelf` directly, assuming it can be found in `$PATH` (which is not necessarily true). My new approach relies on using `nix-build` to get the following "derivations" (packages, more or less): * `stdenv.cc.bintools`, which has a `nix-support/dynamic-linker` file containing the path to `ld-linux.so` * reading this file is [the canonical way to run `patchelf --set-interpreter`](https://github.com/NixOS/nixpkgs/search?l=Nix&q=%22--set-interpreter+%24%28cat+%24NIX_CC%2Fnix-support%2Fdynamic-linker%29%22) * `patchelf` (so that the user doesn't need to have it installed) * `zlib`, for the `libz.so` dependency of `libLLVM-*.so` (until rust-lang#74420 is resolved, presumably) This is closer to how software is built on Nix, but I've tried to keep it as simple as possible (and not add e.g. a `stage0.nix` file). Symlinks to each of those dependencies are kept in `stage0/.nix-deps`, which prevents GC from invalidating `stage0` binaries. r? @nagisa cc @Mark-Simulacrum @oli-obk @davidtwco
Why does rustc link to I suspect that rustc opted for |
It's an LLVM dependency, not |
according to various people on tech-pkg@, there are no problems with the Firefox build Version 1.46.0 (2020-08-27) ========================== Language -------- - [`if`, `match`, and `loop` expressions can now be used in const functions.][72437] - [Additionally you are now also able to coerce and cast to slices (`&[T]`) in const functions.][73862] - [The `#[track_caller]` attribute can now be added to functions to use the function's caller's location information for panic messages.][72445] - [Recursively indexing into tuples no longer needs parentheses.][71322] E.g. `x.0.0` over `(x.0).0`. - [`mem::transmute` can now be used in static and constants.][72920] **Note** You currently can't use `mem::transmute` in constant functions. Compiler -------- - [You can now use the `cdylib` target on Apple iOS and tvOS platforms.][73516] - [Enabled static "Position Independent Executables" by default for `x86_64-unknown-linux-musl`.][70740] Libraries --------- - [`mem::forget` is now a `const fn`.][73887] - [`String` now implements `From<char>`.][73466] - [The `leading_ones`, and `trailing_ones` methods have been stabilised for all integer types.][73032] - [`vec::IntoIter<T>` now implements `AsRef<[T]>`.][72583] - [All non-zero integer types (`NonZeroU8`) now implement `TryFrom` for their zero-able equivalent (e.g. `TryFrom<u8>`).][72717] - [`&[T]` and `&mut [T]` now implement `PartialEq<Vec<T>>`.][71660] - [`(String, u16)` now implements `ToSocketAddrs`.][73007] - [`vec::Drain<'_, T>` now implements `AsRef<[T]>`.][72584] Stabilized APIs --------------- - [`Option::zip`] - [`vec::Drain::as_slice`] Cargo ----- Added a number of new environment variables that are now available when compiling your crate. - [`CARGO_BIN_NAME` and `CARGO_CRATE_NAME`][cargo/8270] Providing the name of the specific binary being compiled and the name of the crate. - [`CARGO_PKG_LICENSE`][cargo/8325] The license from the manifest of the package. - [`CARGO_PKG_LICENSE_FILE`][cargo/8387] The path to the license file. Compatibility Notes ------------------- - [The target configuration option `abi_blacklist` has been renamed to `unsupported_abis`.][74150] The old name will still continue to work. - [Rustc will now warn if you cast a C-like enum that implements `Drop`.][72331] This was previously accepted but will become a hard error in a future release. - [Rustc will fail to compile if you have a struct with `#[repr(i128)]` or `#[repr(u128)]`.][74109] This representation is currently only allowed on `enum`s. - [Tokens passed to `macro_rules!` are now always captured.][73293] This helps ensure that spans have the correct information, and may cause breakage if you were relying on receiving spans with dummy information. - [The InnoSetup installer for Windows is no longer available.][72569] This was a legacy installer that was replaced by a MSI installer a few years ago but was still being built. - [`{f32, f64}::asinh` now returns the correct values for negative numbers.][72486] - [Rustc will no longer accept overlapping trait implementations that only differ in how the lifetime was bound.][72493] - [Rustc now correctly relates the lifetime of an existential associated type.][71896] This fixes some edge cases where `rustc` would erroneously allow you to pass a shorter lifetime than expected. - [Rustc now dynamically links to `libz` (also called `zlib`) on Linux.][74420] The library will need to be installed for `rustc` to work, even though we expect it to be already available on most systems. - [Tests annotated with `#[should_panic]` are broken on ARMv7 while running under QEMU.][74820] - [Pretty printing of some tokens in procedural macros changed.][75453] The exact output returned by rustc's pretty printing is an unstable implementation detail: we recommend any macro relying on it to switch to a more robust parsing system. [75453]: rust-lang/rust#75453 [74820]: rust-lang/rust#74820 [74420]: rust-lang/rust#74420 [74109]: rust-lang/rust#74109 [74150]: rust-lang/rust#74150 [73862]: rust-lang/rust#73862 [73887]: rust-lang/rust#73887 [73466]: rust-lang/rust#73466 [73516]: rust-lang/rust#73516 [73293]: rust-lang/rust#73293 [73007]: rust-lang/rust#73007 [73032]: rust-lang/rust#73032 [72920]: rust-lang/rust#72920 [72569]: rust-lang/rust#72569 [72583]: rust-lang/rust#72583 [72584]: rust-lang/rust#72584 [72717]: rust-lang/rust#72717 [72437]: rust-lang/rust#72437 [72445]: rust-lang/rust#72445 [72486]: rust-lang/rust#72486 [72493]: rust-lang/rust#72493 [72331]: rust-lang/rust#72331 [71896]: rust-lang/rust#71896 [71660]: rust-lang/rust#71660 [71322]: rust-lang/rust#71322 [70740]: rust-lang/rust#70740 [cargo/8270]: rust-lang/cargo#8270 [cargo/8325]: rust-lang/cargo#8325 [cargo/8387]: rust-lang/cargo#8387 [`Option::zip`]: https://doc.rust-lang.org/stable/std/option/enum.Option.html#method.zip [`vec::Drain::as_slice`]: https://doc.rust-lang.org/stable/std/vec/struct.Drain.html#method.as_slice
Pkgsrc changes: * Portability patches for Illumos have been intregrated upstream, so are no longer needed in pkgsrc. * Adjust one other patch, and update vendor/libc cargo checksum. Upstream changes: Version 1.46.0 (2020-08-27) ========================== Language -------- - [`if`, `match`, and `loop` expressions can now be used in const functions.] [72437] - [Additionally you are now also able to coerce and cast to slices (`&[T]`) in const functions.][73862] - [The `#[track_caller]` attribute can now be added to functions to use the function's caller's location information for panic messages.][72445] - [Recursively indexing into tuples no longer needs parentheses.][71322] E.g. `x.0.0` over `(x.0).0`. - [`mem::transmute` can now be used in static and constants.][72920] **Note** You currently can't use `mem::transmute` in constant functions. Compiler -------- - [You can now use the `cdylib` target on Apple iOS and tvOS platforms.][73516] - [Enabled static "Position Independent Executables" by default for `x86_64-unknown-linux-musl`.][70740] Libraries --------- - [`mem::forget` is now a `const fn`.][73887] - [`String` now implements `From<char>`.][73466] - [The `leading_ones`, and `trailing_ones` methods have been stabilised for all integer types.][73032] - [`vec::IntoIter<T>` now implements `AsRef<[T]>`.][72583] - [All non-zero integer types (`NonZeroU8`) now implement `TryFrom` for their zero-able equivalent (e.g. `TryFrom<u8>`).][72717] - [`&[T]` and `&mut [T]` now implement `PartialEq<Vec<T>>`.][71660] - [`(String, u16)` now implements `ToSocketAddrs`.][73007] - [`vec::Drain<'_, T>` now implements `AsRef<[T]>`.][72584] Stabilized APIs --------------- - [`Option::zip`] - [`vec::Drain::as_slice`] Cargo ----- Added a number of new environment variables that are now available when compiling your crate. - [`CARGO_BIN_NAME` and `CARGO_CRATE_NAME`][cargo/8270] Providing the name of the specific binary being compiled and the name of the crate. - [`CARGO_PKG_LICENSE`][cargo/8325] The license from the manifest of the package. - [`CARGO_PKG_LICENSE_FILE`][cargo/8387] The path to the license file. Compatibility Notes ------------------- - [The target configuration option `abi_blacklist` has been renamed to `unsupported_abis`.][74150] The old name will still continue to work. - [Rustc will now warn if you have a C-like enum that implements `Drop`.][72331] This was previously accepted but will become a hard error in a future release. - [Rustc will fail to compile if you have a struct with `#[repr(i128)]` or `#[repr(u128)]`.][74109] This representation is currently only allowed on `enum`s. - [Tokens passed to `macro_rules!` are now always captured.][73293] This helps ensure that spans have the correct information, and may cause breakage if you were relying on receiving spans with dummy information. - [The InnoSetup installer for Windows is no longer available.][72569] This was a legacy installer that was replaced by a MSI installer a few years ago but was still being built. - [`{f32, f64}::asinh` now returns the correct values for negative numbers.] [72486] - [Rustc will no longer accept overlapping trait implementations that only differ in how the lifetime was bound.][72493] - [Rustc now correctly relates the lifetime of an existential associated type.][71896] This fixes some edge cases where `rustc` would erroneously allow you to pass a shorter lifetime than expected. - [Rustc now dynamically links to `libz` (also called `zlib`) on Linux.][74420] The library will need to be installed for `rustc` to work, even though we expect it to be already available on most systems. - [Tests annotated with `#[should_panic]` are broken on ARMv7 while running under QEMU.][74820] - [Pretty printing of some tokens in procedural macros changed.][75453] The exact output returned by rustc's pretty printing is an unstable implementation detail: we recommend any macro relying on it to switch to a more robust parsing system. [75453]: rust-lang/rust#75453 [74820]: rust-lang/rust#74820 [74420]: rust-lang/rust#74420 [74109]: rust-lang/rust#74109 [74150]: rust-lang/rust#74150 [73862]: rust-lang/rust#73862 [73887]: rust-lang/rust#73887 [73466]: rust-lang/rust#73466 [73516]: rust-lang/rust#73516 [73293]: rust-lang/rust#73293 [73007]: rust-lang/rust#73007 [73032]: rust-lang/rust#73032 [72920]: rust-lang/rust#72920 [72569]: rust-lang/rust#72569 [72583]: rust-lang/rust#72583 [72584]: rust-lang/rust#72584 [72717]: rust-lang/rust#72717 [72437]: rust-lang/rust#72437 [72445]: rust-lang/rust#72445 [72486]: rust-lang/rust#72486 [72493]: rust-lang/rust#72493 [72331]: rust-lang/rust#72331 [71896]: rust-lang/rust#71896 [71660]: rust-lang/rust#71660 [71322]: rust-lang/rust#71322 [70740]: rust-lang/rust#70740 [cargo/8270]: rust-lang/cargo#8270 [cargo/8325]: rust-lang/cargo#8325 [cargo/8387]: rust-lang/cargo#8387 [`Option::zip`]: https://doc.rust-lang.org/stable/std/option/enum.Option.html#method.zip [`vec::Drain::as_slice`]: https://doc.rust-lang.org/stable/std/vec/struct.Drain.html#method.as_slice
Discovered in #74395, the current beta links to libz dynamically (through LLVM).
This is new, and is perhaps something we don't want. On the other hand, zlib is pretty ubiquitous so it may be fine to leave it as is. I would like to see us add tests that the set of dynamically linked libraries is stable so we're at least aware of this happening (it slipped into rustc this time in #72696 without that being noticed by the primary reviewer of that PR).
Separately, we should decide if zlib is sufficiently common that it's fine to dynamically link to it.
The text was updated successfully, but these errors were encountered: