Cannot build on x86_64 (Arch Linux) when LTO is enabled #1444
Labels
Comments
|
I tried to reproduce this in a non-Arch environment to see if there's a fundamental limitation with ring. (Disclaimer: I'm not a :; mkdir /tmp/ring && cd /tmp/ring
:; cat - >>profile <<EOF
[profile.release-lto]
inherits = "release"
lto = true
EOFI then created a dockerfile based on the public rust (debian) image: :; cat dockerfile
FROM rust:1.57.0
RUN git clone https://github.com/EmbarkStudios/cargo-about
WORKDIR cargo-about
RUN cargo fetch --locked
COPY profile /
RUN cat /profile >>Cargo.toml
RUN cargo build --frozen --profile release-ltoRunning I think this indicates that there are issues with your Arch build environment? Specifically, your log output looks like the linker is having trouble resolving various functions (e.g. Are you able to build these packages without LTO? I suspect that normal release builds may also fail for you and that there are more basic issues with your build environment. Hope this helps :) |
|
I am experiencing the same when attempting to build maturin (as a package) on Arch Linux (it uses ring). |
archlinux-github
pushed a commit
to archlinux/svntogit-community
that referenced
this issue
Jan 1, 2022
Disable LTO until issues with building the ring dependency are resolved: briansmith/ring#1444 git-svn-id: file:///srv/repos/svn-community/svn@1092013 9fca08f4-af9d-4005-b8df-a31f2cc04f65
archlinux-github
pushed a commit
to archlinux/svntogit-community
that referenced
this issue
Jan 1, 2022
Disable LTO until issues with building the ring dependency are resolved: briansmith/ring#1444 git-svn-id: file:///srv/repos/svn-community/svn@1092013 9fca08f4-af9d-4005-b8df-a31f2cc04f65
Hey! Thanks for having a look at this.
I put together a Dockerfile for reproducing this issue: FROM archlinux:base-devel
WORKDIR cargo-about
RUN pacman --noconfirm -Syu rust
RUN curl https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=cargo-about > PKGBUILD
RUN sed -i "s|('!lto')|('lto')|" PKGBUILD
# this is really bad but it's the easiest way of running makepkg as root x_x
ENV EUID=1
RUN makepkg -si
That's a good point however it exists in the build environment :/
I can build these packages when LTO is disabled. |
|
Looks like I hit the same issue PyO3/maturin#1280 |
|
Any updates? |
jdx
added a commit
to jdx/mise
that referenced
this issue
Mar 24, 2023
Closed
archlinux-github
pushed a commit
to archlinux/svntogit-community
that referenced
this issue
Apr 18, 2023
Switch to github source tarball as pypi sdist tarball is just broken: briansmith/ring#1444 Build using PEP517 integration for maturin. git-svn-id: file:///srv/repos/svn-community/svn@1447298 9fca08f4-af9d-4005-b8df-a31f2cc04f65
archlinux-github
pushed a commit
to archlinux/svntogit-community
that referenced
this issue
Apr 18, 2023
Switch to github source tarball as pypi sdist tarball is just broken: briansmith/ring#1444 Build using PEP517 integration for maturin. git-svn-id: file:///srv/repos/svn-community/svn@1447298 9fca08f4-af9d-4005-b8df-a31f2cc04f65
|
@olix0r you can reproduce the build failure with Docker like this: FROM rust:1.70.0
RUN git clone https://github.com/EmbarkStudios/cargo-about
WORKDIR cargo-about
RUN CFLAGS='-flto=auto' cargo build --lockedOutput: |
|
I'm experiencing this problem too, running x86_64 Nixos |
archlinux-github
pushed a commit
to archlinux/aur
that referenced
this issue
Jul 20, 2023
Related: briansmith/ring#1444 Related: briansmith/ring#893
Closed
|
Hi, could you please try with version 0.17.3 and report back? |
|
I can still reproduce with the latest git main of ring: FROM rust:1.73.0
RUN git clone https://github.com/briansmith/ring
WORKDIR ring
RUN CFLAGS='-flto=auto' cargo test |
|
I reproduced this. It seems to be a problem specific to GCC's LTO. If I use clang's LTO then it works: export RUSTFLAGS="-Clinker=clang-16 -Clink-arg=-fuse-ld=lld -Clink-arg=-fuse-ld=lld-16 -Clinker-plugin-lto"
export RUSTDOCFLAGS=$RUSTFLAGS
CC=clang-16 AR=llvm-ar-16 CFLAGS=-flto=auto cargo test --release(If cross-compiling, use |
|
@kpcyrd what is |
|
Thanks for the workaround! rust:1.73.0Arch Linux |
|
If using GCC: My guess is that you need to pass |
|
Hi friends, does anybody have any suggestions as to what |
|
Just ran into this while trying to package |
|
I don't think there's any way to get this working. GCC LTO and LLVM LTO just don't work with each other at all, and |
archlinux-github
pushed a commit
to archlinux/aur
that referenced
this issue
Dec 9, 2023
In some machines, building the package fails due to ring crate and (gcc) compiler linking issue. Refer: briansmith/ring#1444
archlinux-github
pushed a commit
to archlinux/aur
that referenced
this issue
Dec 9, 2023
In some machines, building the package fails due to ring crate and (gcc) compiler linking issue. Refer: briansmith/ring#1444
archlinux-github
pushed a commit
to archlinux/aur
that referenced
this issue
Dec 9, 2023
In some machines, building the package fails due to ring crate and (gcc) compiler linking issue. Refer: briansmith/ring#1444
archlinux-github
pushed a commit
to archlinux/aur
that referenced
this issue
Dec 9, 2023
In some machines, building the package fails due to ring crate and (gcc) compiler linking issue. Refer: briansmith/ring#1444
ralphptorres
added a commit
to ralphptorres/tiny
that referenced
this issue
Dec 10, 2023
In some machines, building the package fails due to ring crate and (gcc) compiler linking issue. Refer: briansmith/ring#1444
archlinux-github
pushed a commit
to archlinux/aur
that referenced
this issue
Feb 14, 2024
Also disable LTO: briansmith/ring#1444
archlinux-github
pushed a commit
to archlinux/aur
that referenced
this issue
Feb 16, 2024
I guess that this problem related GCC's LTO and LLVM's one have not compatibility. See briansmith/ring#1444 Signed-off-by: Shohei Maruyama <cheat.sc.linux@outlook.com>
|
Hi all. Ran into this a few days ago. Following the suggestion in this issue, I found that passing Related issue I submitted to ArchLinux: link. |
archlinux-github
pushed a commit
to archlinux/aur
that referenced
this issue
May 25, 2024
yorickpeterse
added a commit
to inko-lang/aur
that referenced
this issue
May 29, 2024
Per briansmith/ring#1444 this breaks projects that use the "ring" crate.
|
Just FTR: tested 1.6.0 and looks like still LTO cannot be enabled. |
|
Running into this as well while trying to build pop-os/firmware-manager from the AUR. (Hey @orhun 👋) |
t-8ch
added a commit
to t-8ch/ring
that referenced
this issue
Jan 26, 2025
LTO between Rust and C is complicated. It requires clang and specific invocations configurations for both Rust and C compilations. If the CFLAGS from the environment enable LTO, for example from distribution build tools this can lead to errors. Instead always disable LTO for the C compilation. There is not much to optimize away anyways. Closes briansmith#1444
This was referenced Feb 6, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello. I'm maintaining binary packages for Arch Linux, including a variety of Rust projects that depend on
ringdirectly or indirectly. In the previous months, an RFC has been merged which enables LTO for packages by default by adding the-fltoflag toCFLAGSandCXXFLAGS. This is now implemented along with the new release of devtools. As a result, every binary package that is built now has LTO enabled as default and it can be disabled if desired.However, this caused me some issues while building Rust packages that depend on
ring. For some reason, when LTO is enabled, I can't build those packages, whereas I can successfully build them when LTO is disabled. Here is an example build output from the atuin package:Build log
Another example from cargo-about:
Build log
In this context, "building" means running the following commands in a clean chroot which is provided by
devtools. (wiki):cargo fetch --locked cargo build --release --frozen # this failsTo reproduce (on Arch Linux):
1- Get the latest
PKGBUILDfrom the package details page.2- Enable LTO if it is not already enabled. (
options=('lto'))3- Install the latest version of devtools and build the package by running
extra-x86_64-build.My other findings are:
cargo build --release)opt-level = 2instead ofopt-level = 3)I'm not sure if this is enough to debug this problem but I will be happy to provide more input/output if needed.
The text was updated successfully, but these errors were encountered: