FreeBSD 15.0-STABLE, rust-1.93.1 Building www/deno fails at this stage: Compiling md4 v0.10.2 Running `CARGO=/usr/local/bin/cargo CARGO_CRATE_NAME=md4 CARGO_MANIFEST_DIR=/usr/ports/www/deno/work/deno-2.6.6/cargo-crates/md4-0.10.2 CARGO_MANIFEST_PATH=/usr/ports/www/deno/work/deno-2.6.6/cargo-crates/md4-0.10.2/Cargo.toml CARGO_PKG_AUTHORS='RustCrypto Developers' CARGO_PKG_DESCRIPTION='MD4 hash function' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='MIT OR Apache-2.0' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=md4 CARGO_PKG_README=README.md CARGO_PKG_REPOSITORY='https://github.com/RustCrypto/hashes' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.10.2 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=10 CARGO_PKG_VERSION_PATCH=2 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH=/usr/ports/www/deno/work/target/release/deps /usr/local/bin/rustc --crate-name md4 --edition=2018 /usr/ports/www/deno/work/deno-2.6.6/cargo-crates/md4-0.10.2/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=80 --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debug-assertions=off --cfg 'feature="default"' --cfg 'feature="std"' --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values("default", "oid", "std"))' -C metadata=9da96d3681a668a3 -C extra-filename=-7bf1cf2768e39b33 --out-dir /usr/ports/www/deno/work/target/release/deps -L dependency=/usr/ports/www/deno/work/target/release/deps --extern digest=/usr/ports/www/deno/work/target/release/deps/libdigest-a0047ddbd41724b6.rmeta --cap-lints warn -L/usr/local/lib -C linker=/usr/local/llvm21/bin/clang` error[E0609]: no field `spkac` on type `Netscape_spki_st` --> libs/crypto/spki.rs:48:40 | 48 | if self.0.is_null() || (*self.0).spkac.is_null() { | ^^^^^ unknown field | = note: available field is: `_address` error[E0609]: no field `spkac` on type `Netscape_spki_st` --> libs/crypto/spki.rs:51:22 | 51 | Ok(&*(*self.0).spkac) | ^^^^^ unknown field | = note: available field is: `_address` error[E0609]: no field `challenge` on type `&Netscape_spkac_st` --> libs/crypto/spki.rs:67:29 | 67 | let challenge = spkac.challenge; | ^^^^^^^^^ unknown field | = note: available field is: `_address` error[E0609]: no field `pubkey` on type `&Netscape_spkac_st` --> libs/crypto/spki.rs:139:24 | 139 | let pubkey = spkac.pubkey; | ^^^^^^ unknown field | = note: available field is: `_address` For more information about this error, try `rustc --explain E0609`. error: could not compile `deno_crypto_provider` (lib) due to 4 previous errors
I see the same error on FreeBSD 14.4-STABLE
Do you have anything unusual on your system? deno builds fine on the cluster. Do you build it with poudrière or on an unclean environment ?
(In reply to Mikael Urankar from comment #2) I do build from unclean environment, from ports' tree directly. Due to bugs description, there's OpenSSL interface incompatibility, isn't there? I use base OpenSS, which is 3.0.smth on 14.4-STABLE.
(In reply to Mikael Urankar from comment #2) i too am facing this exact issue, going back weeks or months, in both messy (host) environments and clean (fresh jail, explicit level-0:build,run & level-1+:run dependencies only) environments. my ports tree is about 36 hours old with all pkgs in line with it. i'm on 14.4-RELEASE however, the problematic environments are far from stock. i built rust using PORT_LLVM and llvm22, and have ssl=openssl36 llvm=22 among other fairly aggressive DEFAULT_VERSIONS im not entirely certain if this is a true bug or just llvm22 becoming more formal/strict while the pulled-in version of aws-lc-sys is attempting cowboy antics but i suspect its the latter i also had an issue that smells quite similar (bindgen going opaque, ie: `pub _address: u8`) with security/sequoia-sq and its (indirect?) use of the nettle-sys crate. i just backed it off of llvm22, pegging it to llvm21, allowing success with the rust-1.94.0 built using PORT_LLVM @ v22 *Key: also, this issue in www/deno went away when using llvm21 across the board. but i'm still looking to get it working with llvm22 selected. from what i (barely) understand, this usage of aws-lc-sys here for spkac is vestigial as stubbed out by spki.rs and could trivially just be stubbed even harder or cauterized with a minor patch i would love to see a deno 2.7.x port update (prayers) before we bang our heads against the wall on this one. might a hero arrive? (checks log) looks like that's pretty solidly been you, going back a while, Mikael (tyvm, btw). how challenging and/or tedious was the 2.4.5 -> 2.6.6 work? i'm only an armchair/barstool scientist. i got $50 toward a deno 2.7.9 update and $50 to close this bug resolved, combined if killed with one stone, but i myself prolly wont get on this soon or ever
Created attachment 269180 [details] v0 Can someone try this update?
(In reply to Mikael Urankar from comment #5) Well, I'm not that experienced and could not apply it correctly, but your supposed patch didn't apply cleanly for me (patch-tests_util_server_src_servers_mod.rs couldn't be applied, file not found), so I meved that patch file outside "files" directory. Then it stopped again, now complaining about "oniguruma" (some port, which is not in dependencies and marked as deprecated). [onig_sys 69.9.1] Unable to find oniguruma in pkg-config, and RUSTONIG_SYSTEM_LIBONIG is set: [onig_sys 69.9.1] pkg-config exited with status code 1 [onig_sys 69.9.1] > PKG_CONFIG_LIBDIR=/usr/ports/www/deno/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share/pkgconfig:/usr/libdata/pkgconfig PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 pkg-config --libs --cflags oniguruma oniguruma >= 6.9.3 [onig_sys 69.9.1] [onig_sys 69.9.1] The system library `oniguruma` required by crate `onig_sys` was not found. [onig_sys 69.9.1] The file `oniguruma.pc` needs to be installed and the PKG_CONFIG_PATH environment variable must contain its parent directory. [onig_sys 69.9.1] The PKG_CONFIG_PATH environment variable is not set. [onig_sys 69.9.1] [onig_sys 69.9.1] HINT: if you have installed the library, try setting PKG_CONFIG_PATH to the directory containing `oniguruma.pc`. [onig_sys 69.9.1] [onig_sys 69.9.1] stack backtrace: [onig_sys 69.9.1] 0: __rustc::rust_begin_unwind [onig_sys 69.9.1] 1: core::panicking::panic_fmt [onig_sys 69.9.1] 2: build_script_build::main [onig_sys 69.9.1] 3: core::ops::function::FnOnce::call_once [onig_sys 69.9.1] note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. ESC[1mESC[91merrorESC[0m: failed to run custom build command for `onig_sys v69.9.1` note: To improve backtraces for build dependencies, set the CARGO_PROFILE_RELEASE_BUILD_OVERRIDE_DEBUG=true environment variable to enable debug information generation. But when I installed oniguruma, compilation got further. Then it gave a couple errors more: error: errno_location not implemented for this platform — add the appropriate extern function (e.g. __error on BSDs) --> libs/core/uv_compat/tty.rs:399:5 | 399 | / compile_error!( 400 | | "errno_location not implemented for this platform — \ 401 | | add the appropriate extern function (e.g. __error on BSDs)" 402 | | ); | |_____^ and later one more error: error[E0308]: mismatched types --> libs/core/uv_compat/tty.rs:398:26 | 398 | fn errno_location() -> *mut c_int { | -------------- ^^^^^^^^^^ expected `*mut i32`, found `()` | | | implicitly returns `()` as its body has no tail or `return` expression | = note: expected raw pointer `*mut i32` found unit type `()`
(In reply to Mikael Urankar from comment #5) FreeBSD 15-STABLE, Rust updated to 1.94 since the initial bug report (it didn't make a difference with the stock port). Patch applied cleanly. Build initially failed with: [aws-lc-sys 0.39.0] thread 'main' (104236) panicked at /usr/ports/www/deno/work/ deno-2.7.9/cargo-crates/aws-lc-sys-0.39.0/builder/main.rs:906:5: [aws-lc-sys 0.39.0] aws-lc-sys build failed. Please enable the 'bindgen' feature on aws-lc-rs or aws-lc-sys.For more information, see the aws-lc-rs User Guide: https://aws.github.io/aws-lc-rs/index.html [aws-lc-sys 0.39.0] stack backtrace: [aws-lc-sys 0.39.0] 0: __rustc::rust_begin_unwind [aws-lc-sys 0.39.0] 1: core::panicking::panic_fmt [aws-lc-sys 0.39.0] 2: build_script_main::main [aws-lc-sys 0.39.0] 3: core::ops::function::FnOnce::call_once [aws-lc-sys 0.39.0] note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. There were earlier warnings: [aws-lc-sys 0.39.0] cargo:warning=###### [aws-lc-sys 0.39.0] Consider installing the bindgen-cli: `cargo install --force --locked bindgen-cli` [aws-lc-sys 0.39.0] See our User Guide for more information about bindgen:https: //aws.github.io/aws-lc-rs/index.html [aws-lc-sys 0.39.0] Failure invoking external bindgen! External bindgen command failed. so I installed the rust-bindgen-cli port that was not already present (should it be listed as a prerequisite ?). Build went a little further then failed with the errno_location issues mentionned in comment #6.
(In reply to Mikael Urankar from comment #5) praise Jesus woodja look at that; our hero has arrived and in a flash too. tytyty sir that patch applied smoothly for me. i added: BUILD_DEPENDS+= bindgen:devel/rust-bindgen-cli LIB_DEPENDS+= libonig.so:devel/oniguruma plus a files/patch-libs_core_uv__compat_tty.rs lookin like: +++ libs/core/uv_compat/tty.rs 2026-03-29 09:41:28.167477000 -0400 @@ -381 +381 @@ - #[cfg(target_os = "macos")] + #[cfg(any(target_os = "macos", target_os = "freebsd"))] @@ -397 +397 @@ - #[cfg(not(any(target_os = "macos", target_os = "linux")))] + #[cfg(not(any(target_os = "macos", target_os = "linux", target_os = "freebsd")))] but i get a whole lot of repeated errors from ld: relocation R_X86_64_32{,S} cannot be used against local symbol; recompile with -fPIC i'm cleaning up some of my dead ends to try some things over, but i'm afraid i need you obi wan; i dont know where i would insert that flag or if its a sensible idea
(In reply to Chad Jacob Milios from comment #8) same reloc problems here and I don't understand why it fails...
(In reply to Mikael Urankar from comment #9) i'm not sure if these had any bearing on the build. are you getting these? (seen just ~40% thru the build log): [smartstring 1.0.1] error[E0433]: failed to resolve: use of unresolved module or unlinked crate `alloc` [smartstring 1.0.1] --> <anon>:1:18 [smartstring 1.0.1] | [smartstring 1.0.1] 1 | pub trait Probe: alloc::alloc::Allocator + Sized {} [smartstring 1.0.1] | ^^^^^ use of unresolved module or unlinked crate `alloc` [smartstring 1.0.1] | [smartstring 1.0.1] = help: add `extern crate alloc` to use the `alloc` crate [smartstring 1.0.1] help: consider importing this module [smartstring 1.0.1] | [smartstring 1.0.1] 1 + use std::alloc; [smartstring 1.0.1] | [smartstring 1.0.1] help: if you import `alloc`, refer to it directly [smartstring 1.0.1] | [smartstring 1.0.1] 1 - pub trait Probe: alloc::alloc::Allocator + Sized {} [smartstring 1.0.1] 1 + pub trait Probe: alloc::Allocator + Sized {} [smartstring 1.0.1] | [smartstring 1.0.1] [smartstring 1.0.1] error: aborting due to 1 previous error this is me throwing spaghetti at the wall: (activate GPT slop mode) +++ cargo-crates/smartstring-1.0.1/build.rs 2026-03-29 11:49:28.301840000 -0400 @@ -10 +10 @@ - let has_api = ac.probe_trait("alloc::alloc::Allocator"); + let has_api = has_feature && ac.probe_trait("alloc::alloc::Allocator"); the above error disappears but the wrap up phase still says error: linking with `/usr/local/llvm21/bin/clang` failed: exit status: 1 (i'm working in the v21 environment v2.6.6 is successful in) unfortunately i have to take off for 2-3 days, ran out of time/steam and havent thoroughly explored that area or anywhere else much further
Ok, got it: /usr/ports/www/deno/work/stage/usr/local/bin/deno Deno 2.7.9 rm /usr/local/lib/libnghttp2.a /usr/local/lib/libdeflate.a either restart a clean build or : find work/target -name "*libdeflate*" -exec rm -rf {} \; find work/target -name "*nghttp*" -exec rm -rf {} \; I need to figure out why the build picks the system lib instead of the bundled one.
Created attachment 269287 [details] v1 Can someone try this patch?
Created attachment 269291 [details] v2 2.7.10
(In reply to Mikael Urankar from comment #13) Thank you, I can verify this works on my system (without requiring me to remove the static libraries for libdeflate and libnghttp2) when built outside of Poudriere. I'd been working on the port myself (updating it, cleaning up bits, maybe taking over maintainership) but had gotten stuck at that.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=b360299a17d32521c427d1a688628eb840c19deb commit b360299a17d32521c427d1a688628eb840c19deb Author: Mikael Urankar <mikael@FreeBSD.org> AuthorDate: 2026-04-01 09:13:36 +0000 Commit: Mikael Urankar <mikael@FreeBSD.org> CommitDate: 2026-04-03 11:46:24 +0000 www/deno: Update to 2.7.10 PR: 293587 Tested by: Juhani Krekelä www/deno/Makefile | 29 +- www/deno/Makefile.crates | 280 ++++++---- www/deno/distinfo | 566 ++++++++++++++------- www/deno/files/patch-build_config_BUILD.gn | 4 +- www/deno/files/patch-build_config_BUILDCONFIG.gn | 16 +- www/deno/files/patch-build_config_clang_BUILD.gn | 4 +- .../files/patch-build_config_compiler_BUILD.gn | 80 +-- www/deno/files/patch-build_config_linux_BUILD.gn | 4 +- .../files/patch-build_config_linux_pkg-config.py | 4 +- .../files/patch-build_config_v8__target__cpu.gni | 4 +- www/deno/files/patch-build_detect__host__arch.py | 4 +- www/deno/files/patch-build_gn__run__binary.py | 4 +- www/deno/files/patch-build_linux_chrome.map | 4 +- .../files/patch-build_linux_unbundle_libusb.gn | 4 +- .../files/patch-build_toolchain_freebsd_BUILD.gn | 4 +- .../patch-build_toolchain_gcc__solink__wrapper.py | 4 +- .../files/patch-build_toolchain_gcc__toolchain.gni | 17 +- www/deno/files/patch-build_toolchain_toolchain.gni | 4 +- www/deno/files/patch-cargo-crates_build.rs | 17 +- ...atch-cargo-crates_libffi-sys-build_not__msvc.rs | 4 +- ...ch-cargo-crates_v8_build_config_c++_modules_gni | 8 +- www/deno/files/patch-cargo-crates_v8_gn | 4 +- www/deno/files/patch-cli_Cargo.toml | 10 +- www/deno/files/patch-cli_task_runner.rs | 18 +- www/deno/files/patch-deno__panic_src_libunwind.rs | 24 +- .../files/patch-libs_core_uv__compat_tty.rs (new) | 20 + ...rvers_mod.rs => patch-tests_util_lib_consts.rs} | 4 +- .../patch-tests_util_server_src_lib.rs (gone) | 14 - www/deno/files/patch-v8_BUILD.gn | 20 +- .../files/patch-v8_build_config_sysroot.gni (gone) | 14 - www/deno/files/patch-v8_include_v8config.h | 4 +- www/deno/files/patch-v8_src_api_api.cc | 4 +- www/deno/files/patch-v8_src_base_cpu.cc | 4 +- .../patch-v8_src_base_platform_platform-freebsd.cc | 4 +- .../patch-v8_src_base_platform_platform-posix.cc | 4 +- .../files/patch-v8_src_diagnostics_perf-jit.cc | 4 +- www/deno/files/patch-v8_src_diagnostics_perf-jit.h | 4 +- ...h-v8_third__party_abseil-cpp_absl_base_config.h | 4 +- ..._party_abseil-cpp_absl_base_internal_sysinfo.cc | 14 +- 39 files changed, 748 insertions(+), 491 deletions(-)
(In reply to Mikael Urankar from comment #13) Again, may be I've applied this your patch wrongly (it still do not find a file to patch by patch-tests_util_server_src_servers_mod.rs, so I have to remove it by hand from the port's files directory), but I (FreeBSD 14.4-STABLE amd64) still have these errors: [smartstring 1.0.1] error[E0433]: failed to resolve: use of unresolved module or unlinked crate `alloc` [smartstring 1.0.1] --> <anon>:1:18 [smartstring 1.0.1] | [smartstring 1.0.1] 1 | pub trait Probe: alloc::alloc::Allocator + Sized {} [smartstring 1.0.1] | ^^^^^ use of unresolved module or unlinked crate `alloc` [smartstring 1.0.1] | [smartstring 1.0.1] = help: add `extern crate alloc` to use the `alloc` crate [smartstring 1.0.1] help: consider importing this module [smartstring 1.0.1] | [smartstring 1.0.1] 1 + use std::alloc; [smartstring 1.0.1] | [smartstring 1.0.1] help: if you import `alloc`, refer to it directly [smartstring 1.0.1] | [smartstring 1.0.1] 1 - pub trait Probe: alloc::alloc::Allocator + Sized {} [smartstring 1.0.1] 1 + pub trait Probe: alloc::Allocator + Sized {} [smartstring 1.0.1] | [smartstring 1.0.1] ... Running `CARGO=/usr/local/bin/cargo CARGO_CRATE_NAME=libuv_sys_lite CARGO_MANIFEST_DIR=/usr/ports/www/deno/work/deno-2.7.10/cargo-crates/libuv-sys-lite-1.48.3 CARGO_MANIFEST_PATH=/usr/ports/www/deno/work/deno-2.7.10/cargo-crates/libuv-sys-lite-1.48.3/Cargo.toml CARGO_PKG_AUTHORS='' CARGO_PKG_DESCRIPTION='Tiny, raw bindings to libuv without linking to it' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='' CARGO_PKG_LICENSE_FILE=LICENSE CARGO_PKG_NAME=libuv-sys-lite CARGO_PKG_README=README.md CARGO_PKG_REPOSITORY='https://github.com/nathanwhit/libuv-sys-lite' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=1.48.3 CARGO_PKG_VERSION_MAJOR=1 CARGO_PKG_VERSION_MINOR=48 CARGO_PKG_VERSION_PATCH=3 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH=/usr/ports/www/deno/work/target/release/deps OUT_DIR=/usr/ports/www/deno/work/target/release/build/libuv-sys-lite-7412d8f3d2f45c96/out /usr/local/bin/rustc --crate-name libuv_sys_lite --edition=2021 /usr/ports/www/deno/work/deno-2.7.10/cargo-crates/libuv-sys-lite-1.48.3/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=80 --crate-type lib --emit=dep-info,metadata,link -C opt-level=z -C embed-bitcode=no -C codegen-units=1 -C debuginfo=line-tables-only --cfg 'feature="default"' --cfg feature="dyn-symbols"' --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values("bindgen", "default", "dyn-symbols", "warn-missing"))' -C metadata=5e708db33936e12a -C extra-filename=-874b8971b16591cc --out-dir /usr/ports/www/deno/work/target/release/deps -L dependency=/usr/ports/www/deno/work/target/release/deps --extern libloading=/usr/ports/www/deno/work/target/release/deps/liblibloading-507c2614f15ea4e3.rmeta --cap-lints warn -C target-cpu=bdver2 -C linker=clang21 Building [====================> ] 1691/1795: v8(build), test_util, semve… error[E0425]: cannot find type `sockaddr_in` in this scope --> /usr/ports/www/deno/work/deno-2.7.10/cargo-crates/libuv-sys-lite-1.48.3/s rc/functions.rs:785:18 | 785 | addr: *mut sockaddr_in, | ^^^^^^^^^^^ | ::: /usr/ports/www/deno/work/target/release/build/libuv-sys-lite-7412d8f3d2f4 5c96/out/bindings.rs:327:1 | 327 | pub struct sockaddr { | ------------------- similarly named struct `sockaddr` defined here | help: a struct with a similar name exists | 785 - addr: *mut sockaddr_in, 785 + addr: *mut sockaddr, | ...simalarly... error[E0425]: cannot find type `sockaddr_in6` in this scope ... Building [====================> ] 1691/1795: v8(build), test_util, semve…^M error[E0080]: attempt to compute `1_usize - 16_usize`, which would overflow --> /usr/ports/www/deno/work/target/release/build/libuv-sys-lite-7412d8f3d2f45c96/out/bindings.rs:282:28 | 282 | ...d_once"][::std::mem::size_of::<pthread_once>() - 16usize]; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ evaluation of `types::_` failed here ...similarly... error[E0080]: attempt to compute `1_usize - 64_usize`, which would overflow Building [====================> ] 1691/1795: v8(build), test_util, semve…^M^Merror[E0080]: evaluation panicked: unsupported platform --> tests/util/lib/consts.rs:24:33 | 24 | pub const TSGO_PLATFORM: &str = tsgo_platform(); | ^^^^^^^^^^^^^^^ evaluation of `consts::TSGO_PLATFORM` failed inside this call | note: inside `tsgo_platform` --> tests/util/lib/consts.rs:37:7 | 37 | panic!("unsupported platform"); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the failure occurred here error[E0080]: attempt to compute `1_usize - 64_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 80_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 96_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 256_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 192_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 256_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 96_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 224_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 320_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 304_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 272_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 168_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 120_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 120_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 120_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 128_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 152_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 160_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 1320_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 136_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 128_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 56_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 80_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 40_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 24_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 1024_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 88_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 16_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 16_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 128_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 56_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 440_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 176_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 104_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 152_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 144_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 304_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 1320_usize`, which would overflow error[E0080]: attempt to compute `1_usize - 712_usize`, which would overflow error: could not compile `test_util` (lib) due to 1 previous error error: could not compile `libuv-sys-lite` (lib) due to 45 previous errors; 1 warning emitted
(In reply to Mikael Urankar from comment #13) (In reply to commit-hook from comment #15) LGTM (tried the commit) @ llvm21. Thanks for the timely work, Mikael! Please post/email a Bitcoin, Litecoin, Namecoin, CashApp or Zelle target Still no joy for me using an llvm22 environment though [but that was always a lot to hope for]. This is solid footing for us to keep looking into the initial problem report (which also arose merely in the presence of llvm22/llvm-devel, not only when chosen; maybe that's a clue?).
(In reply to gja822 from comment #16) have you been using `git apply file.diff` or `patch < file.diff`? you should use the former not the latter at any rate, i just pulled the commit since its in the tree now
(In reply to Chad Jacob Milios from comment #18) Thanks for the hint! now I know the right way. Still can't get it building. The errors are in #16 are all there.
(In reply to gja822 from comment #16) You should first rename (not delete) files/patch-tests_util_server_src_servers_mod.rs to files/patch-tests_util_lib_consts.rs, and then run git apply on the patch. But really, I'd suggest updating your ports tree, since the most recent main branch has the patch already applied.
(In reply to Juhani Krekelä from comment #20) Yes, thank you, I've figured it out, at first manually with renaming, then just updating ports tree. But the result is the same: errors as in #16 (I have llvm21 as default in make.conf, if it matters.)
(In reply to Chad Jacob Milios from comment #17) I have indeed this kind of configuration (llvm22 installed but not specifically used for deno). FWIW, I had a similar problem years ago with a different port (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247026). Its fix is probably not reusable as is since it was meson-related, but may give some ideas.
Created attachment 269416 [details] v3 Can someone try this patch?
(In reply to Mikael Urankar from comment #23) Ues, now it could be built for me! Thanks
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e330aefa238248ff5ab18671061c4f8221f9f188 commit e330aefa238248ff5ab18671061c4f8221f9f188 Author: Mikael Urankar <mikael@FreeBSD.org> AuthorDate: 2026-04-06 15:36:07 +0000 Commit: Mikael Urankar <mikael@FreeBSD.org> CommitDate: 2026-04-07 10:59:18 +0000 www/deno: Fix build when llvm22 is installed For whatever reason the build fails if llvm22 is installed / used, the generated bindings.rs file doesn't have all the needed definitions. Fix this by providing libuv bindgen likes it's done for others OS [3] (it was generated with llvm21). error be like: libuv-sys-lite-1.48.2/src/functions.rs | 785 | addr: *mut sockaddr_in, | ^^^^^^^^^^^ help: a struct with a similar name exists: `sockaddr` For reference: deno issue [1], libuv-sys-lite issue [2] and fix [3] [1] https://github.com/denoland/deno/issues/32351 [2] https://github.com/nathanwhit/libuv-sys-lite/issues/1 [3] https://github.com/nathanwhit/libuv-sys-lite/commit/37c1821e8e94f70dc0c768092d8a44920609d045 PR: 293587 Tested by: gja822@narod.ru .../files/patch-cargo-crates_libuv-sys-lite (new) | 7400 ++++++++++++++++++++ 1 file changed, 7400 insertions(+)
(In reply to commit-hook from comment #25) Wow, 😨 just installed, but not used or mentioned in make.conf llvm version could interfere??? Something deeply wrong in a building scripts, if this can happen, IMO. I do have llvm-devel installed for some experiments, although it is not used frequently. Thanks for the solution!
Created attachment 269490 [details] v4 clang-sys is responsible for finding llvm, I assume it picks the first one it finds https://github.com/KyleMayes/clang-sys/blob/master/build/common.rs#L160 Anyway, bumping bindgen to 0.72.1 in libuv-sys-lite fixes the problem without having to provide the pregenerated bindings.rs file If anyone can test this patch it'll be really appreciated.
(In reply to Mikael Urankar from comment #27) A build with this patch applied and llvm22 port present completed without issues.
(In reply to Mikael Urankar from comment #27) It builds for me both on the host system and in poudriere (STABLE-15 with defaul set to LLVM 22). Thanks!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=86aef581b030dd8330093557ff2c40474fc72f92 commit 86aef581b030dd8330093557ff2c40474fc72f92 Author: Mikael Urankar <mikael@FreeBSD.org> AuthorDate: 2026-04-08 09:11:45 +0000 Commit: Mikael Urankar <mikael@FreeBSD.org> CommitDate: 2026-04-09 07:48:29 +0000 www/deno: proper fix for llvm22 binding problem This was fixed with bindgen > 0.70.1 (I don't kwown the exact version) PR: 293587 Tested by: Philippe Michel, Oleg Sidorkin Fixes: e330aefa238248ff5ab18671061c4f8221f9f188 www/deno/files/patch-cargo-crates_libuv-sys-lite | 7433 +--------------------- 1 file changed, 34 insertions(+), 7399 deletions(-)
(In reply to gja822 from comment #26) yes it is extremely common that upstream build scripts and associated frameworks attempt to be far too clever for their (or our) own good. as mentioned in porter's handbook § 5.10.12 we make a valiant effort to uncover such toxic combinations of software and patch ports to obey only the knobs of our ports framework but this is admittedly an intractable problem which is why the first question to so many bugs is "are you building in poo-dree?" (or whatever its called; i cant speel french) in other words, in strict isolation (a fresh jail can also be used with a nullfs mount of /usr/ports/packages) (In reply to Mikael Urankar from comment #27) (In reply to commit-hook from comment #30) confirmed all this hard work as committed works famously amid even my most ambitious environment(s). THANK YOU; you're a gentleman and a scholar!