Project

General

Profile

Actions

Bug #20506

closed

YJIT build error on aarch64 with Rust 1.78.0

Added by schneems (Richard Schneeman) 5 months ago. Updated about 12 hours ago.

Status:
Third Party's Issue
Assignee:
Target version:
-
[ruby-core:118003]

Description

I was unable to compile Ruby 3.4.0-preview1 on Ubuntu 24.04 via Github Actions. As the logs are not retained indefinitely here's a link to the compilation failure: https://gist.github.com/schneems/bc6bdd6fba08ff6bfdd1bce8d76c457d

The relevant errors seem to be in linking yjit:

touch yjit/target/release/libyjit.a
partial linking yjit/target/release/libyjit.a into yjit/target/release/libyjit.o
linking miniruby
/usr/bin/ld: yjit/target/release/libyjit.o: in function `__multc3':
/cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:33:(.text.__multc3+0x30c): undefined reference to `__builtin_copysignq'
/usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:34:(.text.__multc3+0x394): undefined reference to `__builtin_copysignq'
/usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:42:(.text.__multc3+0x7f4): undefined reference to `__builtin_copysignq'
/usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:43:(.text.__multc3+0x864): undefined reference to `__builtin_copysignq'
/usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:47:(.text.__multc3+0x8c4): undefined reference to `__builtin_copysignq'
/usr/bin/ld: yjit/target/release/libyjit.o:/cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:38: more undefined references to `__builtin_copysignq' follow
collect2: error: ld returned 1 exit status
make: *** [Makefile:298: miniruby] Error 1
/tmp/lib/build_script.rb:118:in `pipe': Command failed debugflags="-g" ./configure --disable-install-doc --prefix /tmp/d20240524-1-bdq0bj/prefix --enable-load-relative --enable-shared --enable-yjit && make -j16 && make install (RuntimeError)
	from /tmp/lib/build_script.rb:158:in `block in build'
	from /tmp/lib/build_script.rb:152:in `chdir'
	from /tmp/lib/build_script.rb:152:in `build'
	from /tmp/lib/build_script.rb:65:in `block in run_build_script'
	from /usr/lib/ruby/3.2.0/tmpdir.rb:94:in `mktmpdir'
	from /tmp/lib/build_script.rb:61:in `run_build_script'
	from /tmp/build.rb:8:in `<main>'

Here's the GHA link: https://github.com/heroku/docker-heroku-ruby-builder/actions/runs/9225538149/job/25383247191. This is the Dockerfile for Ubuntu 24.04 https://github.com/heroku/docker-heroku-ruby-builder/blob/73bdda974811717baccc05ea3e23f607817fbc8a/dockerfiles/Dockerfile.heroku-24.

I'm able to reproduce the failure locally:

$ git clone https://github.com/heroku/docker-heroku-ruby-builder
$ cd docker-heroku-ruby-builder
$ export DOCKER_DEFAULT_PLATFORM=linux/arm64
$ bin/activate_docker heroku-24
$ bin/build_ruby heroku-24 3.4.0-preview1
# Fails

Full output https://gist.github.com/schneems/cfa21847228d48e6bbe27463deae6745.

I'm also seeing failures when using ruby-install on my mac (ARM), the error message is different so I'm not sure if it's the same problem or unrelated: https://gist.github.com/schneems/12af87e967126c7bfa319645b00015b3

Updated by k0kubun (Takashi Kokubun) 5 months ago

  • Status changed from Open to Assigned
  • Assignee set to yjit

Updated by eileencodes (Eileen Uchitelle) 5 months ago

The macos one is https://bugs.ruby-lang.org/issues/20495. Until https://github.com/ruby/ruby/pull/10699 is merged, you can run git checkout coroutine/arm64/Context.S and then make again. I added the git checkout to my build script in the mean time.

Updated by alanwu (Alan Wu) 5 months ago

This seems to happen with Rust 1.78.0, so as a temporary solution please try any other >=1.58.0 versions.
__builtin_copysignq seems to be an x86 specific intrinsic but rust 1.78.0 is putting it in the ARM archive for some reason.

Updated by schneems (Richard Schneeman) 5 months ago

Thanks for the fast responses. I was able to get it working on Ubuntu by downgrading rust in my dockerfile (nothing special about 1.75, I randomly picked a version):

RUN rustup install 1.75 && rustup default 1.75

It also looks like other Ruby versions fail to compile with the latest Rust version: It fails with Ruby 3.3.1 on Ubuntu 24.04 with the latest rust (1.78) in addition to Ruby 3.4.0-preview1.

Updated by alanwu (Alan Wu) 5 months ago

  • Subject changed from Failure compiling Ruby 3.4.0-preview1 on aarch64 on a mac and linux (Ubuntu 24.04) to YJIT build error on aarch64 with Rust 1.78.0
  • Status changed from Assigned to Third Party's Issue

This is a Rust regression and I've filed an issue upstream.
I've worked with upstream to hopefully have a fix ship with 1.81.0,
but that will still leave a couple versions unusable.

If you install using rustup, avoid these versions by using e.g.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | \
    sh -s -- --default-toolchain=1.77.0 --profile=minimal -y --no-modify-path

in your Dockerfile. Another option is to install rustc through
your Linux distribution's package manager, e.g. apt-get install rustc.
That should also avoid this issue.

Updated by Earlopain (A S) 1 day ago

Small update, I believe https://github.com/rust-lang/rust/pull/131221 will fix this, which is slated for Rust 1.83. Not so sure about that since the actual fix seems to have been applied in llvm https://github.com/llvm/llvm-project/pull/93890 but I can confirm that this still happens with Rust 1.82

Updated by alanwu (Alan Wu) 1 day ago

@Earlopain (A S) Are you using musl through e.g. Alpine Linux? The workaround rust PR is https://github.com/rust-lang/rust/pull/125999, it shipped in 1.81.0 and we've seen it work.

Updated by Earlopain (A S) 1 day ago · Edited

Yes, guilty as charged. I apologize, I only saw the failure for one variant and assumed the same for others.

Can you say if what I wrote above is correct for musl? I guess I'll see when the next version releases regardless.

Edit: Hm, I tested with nightly and the behaviour is still the same.

Updated by alanwu (Alan Wu) 1 day ago · Edited

I tested 1.82.0 from rustup and rust-lang/rust#125619
does reproduce when targeting aarch64-unknown-linux-musl. I was under the
impression that we've worked around the issue for all targets -- thanks for
the report.

I've started the process to get the compiler-rt fix backported to the LLVM
shipped with rustup. That should fix it for aarch64-unknown-linux-musl, but
there's no telling whether the fix will make it in time for the next release.

For others building with musl, please refer to [ruby-core:118276]
for workarounds.

Updated by Earlopain (A S) about 12 hours ago · Edited

Thanks for the reply, I appreciate that! It's not urgent or anything, I was just a bit uncertain if musl may be some other issue entirely. I'll follow https://github.com/llvm/llvm-project/issues/114720 and be on the lookout for something on the rust side of things after that.

Actions

Also available in: Atom PDF

Like0
Like0Like2Like1Like0Like0Like0Like0Like0Like0Like0