Rust building failed

ssbear

ssbear

Hi folks.
I use a Poudriere under FreeBSD 13.2-RELEASE-p3.

For some clients, I need to build security/py-certbot (with lang/python311), which needs security/py-cryptography. However, since last july, this port requires lang/rust.

And you know what...After 3,5 hours, and at 90%, the building of Rust failed...

Here the last entries (log size is 1,5 Mo).
Code: 
[ 90% 2838/3148] Linking CXX executable bin/llvm-dwarfutil
[ 90% 2839/3148] Linking CXX executable bin/llvm-dwp
[ 90% 2840/3148] Building CXX object tools/llvm-exegesis/CMakeFiles/llvm-exegesis.dir/llvm-exegesis.cpp.o
FAILED: tools/llvm-exegesis/CMakeFiles/llvm-exegesis.dir/llvm-exegesis.cpp.o
/usr/bin/c++ -DGTEST_HAS_RTTI=0 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/wrkdirs/usr/ports/lang/rust/work/_build/x86_64-unknown-freebsd/llvm/build/tools/llvm-exegesis -I/wrkdirs/usr/ports/lang/rust/work/rustc-1.71.0-src/src/llvm-project/llvm/tools/llvm-exegesis -I/wrkdirs/usr/ports/lang/rust/work/_build/x86_64-unknown-freebsd/llvm/build/include -I/wrkdirs/usr/ports/lang/rust/work/rustc-1.71.0-src/src/llvm-project/llvm/include -ffunction-sections -fdata-sections -fPIC -m64 -pipe -fstack-protector-strong -fno-strict-aliasing -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -w -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG -std=c++17  -fno-exceptions -fno-rtti -MD -MT tools/llvm-exegesis/CMakeFiles/llvm-exegesis.dir/llvm-exegesis.cpp.o -MF tools/llvm-exegesis/CMakeFiles/llvm-exegesis.dir/llvm-exegesis.cpp.o.d -o tools/llvm-exegesis/CMakeFiles/llvm-exegesis.dir/llvm-exegesis.cpp.o -c /wrkdirs/usr/ports/lang/rust/work/rustc-1.71.0-src/src/llvm-project/llvm/tools/llvm-exegesis/llvm-exegesis.cpp
ninja: build stopped: subcommand failed.
thread 'main' panicked at '
command did not execute successfully, got: exit status: 1

build script failed, must exit now', /wrkdirs/usr/ports/lang/rust/work/rustc-1.71.0-src/vendor/cmake/src/lib.rs:975:5
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: cmake::fail
   3: cmake::run
   4: cmake::Config::build
   5: <bootstrap::llvm::Llvm as bootstrap::builder::Step>::run
             at ./src/bootstrap/llvm.rs:489:9
   6: bootstrap::builder::Builder::ensure
             at ./src/bootstrap/builder.rs:2069:23
   7: bootstrap::compile::rustc_llvm_env
             at ./src/bootstrap/compile.rs:894:48
   8: bootstrap::compile::rustc_cargo_env
             at ./src/bootstrap/compile.rs:881:13
   9: bootstrap::compile::rustc_cargo
             at ./src/bootstrap/compile.rs:818:5
  10: <bootstrap::compile::Rustc as bootstrap::builder::Step>::run
             at ./src/bootstrap/compile.rs:703:9
  11: bootstrap::builder::Builder::ensure
             at ./src/bootstrap/builder.rs:2069:23
  12: <bootstrap::compile::Assemble as bootstrap::builder::Step>::run
             at ./src/bootstrap/compile.rs:1419:9
  13: bootstrap::builder::Builder::ensure
             at ./src/bootstrap/builder.rs:2069:23
  14: bootstrap::builder::Builder::compiler
             at ./src/bootstrap/builder.rs:967:9
  15: <bootstrap::compile::Assemble as bootstrap::builder::Step>::run
             at ./src/bootstrap/compile.rs:1403:30
  16: bootstrap::builder::Builder::ensure
             at ./src/bootstrap/builder.rs:2069:23
  17: bootstrap::builder::Builder::compiler
             at ./src/bootstrap/builder.rs:967:9
  18: <bootstrap::dist::Rustc as bootstrap::builder::Step>::make_run
             at ./src/bootstrap/dist.rs:364:39
  19: bootstrap::builder::StepDescription::maybe_run
             at ./src/bootstrap/builder.rs:302:13
  20: bootstrap::builder::StepDescription::run
             at ./src/bootstrap/builder.rs:339:21
  21: bootstrap::builder::Builder::run_step_descriptions
             at ./src/bootstrap/builder.rs:959:9
  22: bootstrap::builder::Builder::execute_cli
             at ./src/bootstrap/builder.rs:940:9
  23: bootstrap::Build::build
             at ./src/bootstrap/lib.rs:690:13
  24: bootstrap::main
             at ./src/bootstrap/bin/main.rs:60:5
  25: core::ops::function::FnOnce::call_once
             at /wrkdirs/usr/ports/lang/rust-bootstrap/work-amd64/rustc-1.70.0-src/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
    finished in 12785.043 seconds
Build completed unsuccessfully in 3:36:55
*** Error code 1

Stop.
make: stopped in /usr/ports/lang/rust
=>> Cleaning up wrkdir
===>  Cleaning for rust-1.71.0
build of lang/rust | rust-1.71.0 ended at Thu Sep  7 17:05:07 CEST 2023
build time: 03:39:15
!!! build failure encountered !!!

Any ideas? If I can't build lang/rust, I can't build security/py-certbot too, and I need it. For year, Certbot was a light tool to build, I don't understand this requirement (it's really huge to build...), and I don't understand the failed.

Thanks a lot.

Regards
 
I think you might want to fix your post's formatting :D

What kind resources does your poudriere build host have available (especially memory wise)?
I just built Rust 1.71 successfully. The panic might indicate an out-of-memory event (especially if you hit this wall repeatedly).

ssbear said:
For year, Certbot was a light tool to build
Click to expand...
It's currently quite the trend to re-write everything ever written in Rust. Similar debacles at FireFox, ClamAV, ... really everywhere you look.
 
With wider adoption, rust might some day have the same relevance as C or C++. Our C and C++ compiler (clang/llvm) isn't exactly lightweight to build either. It's just ... you don't notice it much because it's already included in base.

There's always the option to use binary packages. Even if you need some port customizations (custom options or similar), you can still use binary packages, have a look at the package pre-fetching option of ports-mgmt/poudriere-devel.

That said, for something that also has quite some dependencies, like rust, you might have to carefully check out exactly the commit hash from which the latest official package repository was built to make sure poudriere will be able to use this package (and not need to build it anyways because one of the dependencies already changed again).
 
Recently, I also had a problem with building of rust as a build dependency of graphics/pecl-imagick, actually of graphics/librsvg2. Here, the build ran clearly out of disk space. This was on an AWS/EC2 instance which had 3 GB left free. I choose not to pay more to AWS and book more disk space in order to being able to build rust. Instead, I cleaned-up the mess and before building graphics/pecl-imagick, I did:

# pkg install rust

While you experienced a different build issue, perhaps the same mitigation might work for you as well, though.
Here, rust was only a build dependency, I removed it afterwards.
 
cyclaero, when you build in poudriere, it's irrelevant which packages are installed on the host. But that's why I suggested using poudriere-devel's package pre-fetch feature instead, which will download and use official packages when they're suitable (same options, same dependencies etc).
 
I had the same problem, but most of all I don't want to build Rust on my servers so I added to Poudriere's make.conf the following default:

Code: 
DEFAULT_VERSIONS+=pycryptography=legacy

After that, Rust is no more a dependency, and it had no side effects (see /usr/ports/UPDATING, entry from 2023-07-23, for details on this option).
 
spectrum48 said:
and it had no side effects
Click to expand...
It has, you're using a "legacy version". Same goes for other things like e.g. librsvg still offering a non-rust alternative via DEFAULT_VERSIONS. I guess this will be kept for a while because of certain issues like you still can't build rust using qemu-user (to target a different architecture), but it definitely means you're using some old version.
 
spectrum48 said:
I had the same problem, but most of all I don't want to build Rust on my servers so I added to Poudriere's make.conf the following default:

Code: 
DEFAULT_VERSIONS+=pycryptography=legacy

After that, Rust is no more a dependency, and it had no side effects (see /usr/ports/UPDATING, entry from 2023-07-23, for details on this option).
Click to expand...
Thanks! I'll test it. Just for build my security/py-certbot. But, as said zirias@, it will probably create issues in the future, for other ports.
 
My problem with rust is that it take hours to compile. A couple of days ago there was a Django security fix I could apply in a couple of minutes without rust dependency or in many hours with rust dependency.
 
After increase hard disk, swap and RAM of my ec2 instance… building lang/rust has failed again. After 3 hours, I got a swap issue. Definitely a pain in the ass to build it, and a huge loss of time and ressources for nothing.

I will try ports-mgmt/poudriere-devel this Monday for the package pre-fetching option.

Adding
Code: 
DEFAULT_VERSIONS+=pycryptography=legacy
in /etc/make.conf works too. However, I don’t know if, in the future or the present, other ports need the un-legacy rust.

Thx a lot for your responses, advices and support!

Regards,
 
Some time ago I had some problems compiling Rust in my machine and I took note in my poudriere update script with that annotations:
# Compile lang/rust devel/llvm and lang/gcc using only 1 core because these ports frecuently crash with parallel compilation:
# man poudriere-bulk
poudriere bulk -r -t -J 1:8 -j freebsd_13-2x64 -p latest lang/rust lang/gcc10
Click to expand...
Maybe it is useful for you.

Best regards.
 
With 8 Go RAM, and 8 Go swap, still a fail. This time, no obvious error... After 4,5 hours. Probably, building ports now is reversed to NASA computers.
I give up.
 

Attachments

ssbear said:
With 8 Go RAM, and 8 Go swap, still a fail. This time, no obvious error... After 4,5 hours.
Click to expand...

My 16 GB physical server is not able to build Rust but I think kr0m is right. I'm trying to build it using a single core now, will report later.

By the way, even if this will work, I'm not happy that updates which used to take minutes will now require several hours because of a single dependency.
 
For what it's worth: I am compiling lang/rust on 20 and 32 cores parallel without any issues (and I'm doing that frequently, because that thing needs to be recompiled every few days due to the dependency on ftp/curl which frequently receives security patches.

spectrum48 said:
By the way, even if this will work, I'm not happy that updates which used to take minutes will now require several hours because of a single dependency.
Click to expand...
Every time a new language emerges people flock to re-write everything in that language (sometimes for the fame, sometimes because they don't know how to use C bindings) and that is fine in my opinion. It happened with Go, it happened with Javascript (NodeJS) and now it's happening with Rust.
Personally, I dislike that existing software that worked perfectly well in the language it was originally implemented in (often C or C++) starts to be "extended" with Rust.
But that is just my personal opinion largely based on old-man-yells-at-clouds.
 
poudriere.conf
Code: 
TMPFS_BLACKLIST="rust"


rust is a horribly bloated piece of software and takes up insane amounts of RAM during build. this has gotten worse and worse over time...

If you want to avoid it (and python) just for the simple task of renewing certificates: use security/acme.sh, which is purely written in shell and can be built with zero dependencies except for curl or wget (of which usually at least one is installed anyways...). Standalone-mode (enabled by default) only needs socat, but it can be built without this.
 
sko said:
If you want to avoid it (and python) just for the simple task of renewing certificates: use security/acme.sh, [...]
Click to expand...
Probably not an issue anymore (especially as the main issue was HiCA) but for historians:
forums.freebsd.org

acme.sh runs arbitrary commands from a remote server

Anybody using security/acme.sh might want to upgrade: security/acme.sh runs arbitrary commands from a remote server! If you're using HiCA, you surely want to revoke & renew your certs (with a more trustworthy CA). Instead, HiCA is stealthily crafting curl commands and piping the output to...
forums.freebsd.org forums.freebsd.org
 
My lowly i5-3470 (2 cores/4 threads) with 16GB memory (and 16GB swap) has no problems building it. It takes a little over 2 hours (for rust itself, not including its dependencies).
 
diizzy said:
8Gb of RAM will not go well in general and if you're using ZFS it's be even more painful. You _might_ get away with 1 job (-j1) and at least 8Gb of swap but it'll take a long time to build.
Not saying it's a solution but a workaround that works well is to use Lego unstead of Certbot to avoid pulling in Rust or use packages.
https://github.com/go-acme/lego --> https://www.freshports.org/security/lego
Click to expand...
And building go instead of rust and replacing one horribly bloated buildjob with another...
 
cracauer@ said:
Do you have hyperthreading? Then you would run with 4 processes by default.
Click to expand...
It's a t3 ec2 instance with 2 vCPU. With 8 Go RAM.
Before the devel/rust dependency, everything was perfect (with only 2 Go RAM ; I increase it just for rust building)... I don't have huge builds in this poudriere machine (Python, Samba, Nginx;;; mostly). That's why I'm really confused about this dependency.

Maybe I'll try with one job (and without TMPFS ?). I also set PARALLEL_JOBS to 1.
 
You must log in or register to reply here.
Back
Top