[upstream] Build failures on aarch64 Linux with glibc 2.26.1 on latest Rust compiler #20131
Comments
|
The source is here https://github.com/denoland/deno_cache/tree/main/rs_lib |
|
Hey Luke, cool to see you around. |
|
I wonder what caused that. The upgrade seems very tame for the dependencies that were bumped https://github.com/denoland/deno/pull/20092/files#diff-13ee4b2252c9e516a0547f2891aa2105c3ca71c6d7a1e682c69be97998dfc87e (I didn't dig into it in that much detail though) |
dsherret
added
the
needs investigation
|
Not sure what is causing it, but this looks like rust-lang/rust#113104 |
|
@LukeChannings A comment related Rust bug report suggests that using |
|
I compile with the default Looks like it wants glibc >= 2.27, but Xenial has 2.26.1. There are also no APT packages for clang+llvm-9 for aarch64 + xenial, so I can't rule out a misconfiguration of the release bundle ( clang+llvm 9 is the earliest I tested, as well as Xenial's APT |
|
@LukeChannings As an alternative, can you see if |
|
How exactly are people compiling I tried to reproduce these errors on Arch with |
Compiling with My project is at LukeChannings/deno-arm64. You can reproduce it by reverting I'm compiling on an M1 MBP. |
|
I can repro using that repo: |
|
This linker error arises due to using I can reproduce this on x86_64 Linux in an Ubuntu 16.04 container without I'll try to minimize this a bit more then open a fresh issue on rust-lang/rust. I don't think we have seen this bug before. |
|
@dsherret Something interesting to note above -- do we have a reason to use |
|
@mmastrac it's used for the wasm build. It could maybe be separated out to a separate crate in the repo. |
|
@LukeChannings Why did you say that there is a dependency on a newer glibc, as opposed to some other factor in the build? |
|
I don't have solid reasons, it's just what the problem was the last time my builds failed because of a linker issue. Not specifically glibc, but the toolchain associated with a particular version of it I suppose. That assumption was further reinforced by it being resolved when I upgraded to a later version. glibc 2.26 is pretty old :D |
|
This appears to be fixed by rust-lang/rust#115114 @LukeChannings as a temporarily workaround, |
|
Hmm, I'm actually still getting the same error, using: |
|
Are you sure the Docker cache isn't holding onto an old nightly? I wiped mine and it now builds successfully on nightly. |
|
I made double sure, using Note: I deleted Full Dockerfile: FROM ubuntu:16.04
SHELL ["/bin/bash", "-c"]
RUN apt-get update -y
RUN DEBIAN_FRONTEND="noninteractive" TZ="Europe/London" apt-get install -y python curl build-essential unzip git libtool autoconf cmake
ENV PATH="/root/.cargo/bin:${PATH}"
RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- --default-toolchain none -y
RUN rustup toolchain install nightly --allow-downgrade --profile minimal --component clippy
ARG DENO_VERSION
RUN git config --global core.symlinks true
RUN git clone --recurse-submodules https://github.com/denoland/deno.git /deno
WORKDIR /deno
RUN if [ "${DENO_VERSION:0:6}" == "canary" ]; then \
git checkout "${DENO_VERSION:7}" ; \
else \
git checkout "${DENO_VERSION}" ; \
fi
ADD deno_upgrade_release_url.patch /deno/
RUN patch -p1 < deno_upgrade_release_url.patch
RUN rustup target add wasm32-unknown-unknown
RUN rustup target add wasm32-wasi
RUN rm /deno/rust-toolchain.toml
RUN rustup toolchain list
RUN rustup default nightly-aarch64-unknown-linux-gnu
RUN RUST_BACKTRACE=full cargo +nightly build --release --locked --bin deno |
|
Using nightly, I can only reproduce this linker error on my M1, not my Linux desktop. Which is incredibly strange to me. What's your host? I'll try to re-minimize this on my M1 this weekend. |
mmastrac
changed the title
deno_cache_dir@v0.5.0 depends on newer glibc - causes build failures on glibc 2.26.1
|
My host is also an M1 Mac. The original error was reproduced in CI, I can try to find some time next week to reproduce it with the latest nightly in that environment - I've just been using Docker on my M1 Mac. Something strange must be afoot though, since as we know the containers are running in a virtualised Linux guest. I'm not adding any weirdness with QEMU either. |
|
Ok I'm just daft; the reason the full reproducer only doesn't link on M1 is because the offending static is aarch64-only. I've also fixed my reproducer and updated the Rust issue with it. |
|
Thanks for investigating this. I filed a ring issue to fix this: briansmith/ring#1808. Plan to fix it soon. |
|
I believe this was closed upstream by @briansmith so I'll close this for now. |
I have been compiling Deno against glibc 2.26.1 (ubuntu 16.04) for increased compatibility, most notably AWS Lambda.
The release of
deno_cache_dirv0.5.0 depends on a later version which has forced an upgrade to Ubuntu 18.04 (glibc 2.30)It fails with the following error:
This is certainly a low priority, but I can't actually find the source for
deno_cache_diroutside of crates.io - is it hosted in this repo?The text was updated successfully, but these errors were encountered: