On stable/14 at 1404501, I'm getting the following error during the build: Running `CARGO=/usr/local/bin/cargo CARGO_CRATE_NAME=arrayvec CARGO_MANIFEST_DIR=/wrkdirs/usr/ports/mail/thunderbird-esr/work/thunderbird-140.12.0/comm/third_party/rust/arrayvec CARGO_MANIFEST_PATH=/wrkdirs/usr/ports/mail/thunderbird-esr/work/thunderbird-140.12.0/comm/third_party/rust/arrayvec/Cargo.toml CARGO_PKG_AUTHORS=bluss CARGO_PKG_DESCRIPTION='A vector with fixed capacity, backed by an array (it can be stored on the stack too). Implements fixed capacity ArrayVec and ArrayString.' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='MIT OR Apache-2.0' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=arrayvec CARGO_PKG_README=README.md CARGO_PKG_REPOSITORY='https://github.com/bluss/arrayvec' CARGO_PKG_RUST_VERSION=1.51 CARGO_PKG_VERSION=0.7.6 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=7 CARGO_PKG_VERSION_PATCH=6 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH=/wrkdirs/usr/ports/mail/thunderbird-esr/work/.build/release/deps /usr/local/bin/rustc --crate-name arrayvec --edition=2018 /wrkdirs/usr/ports/mail/thunderbird-esr/work/thunderbird-140.12.0/comm/third_party/rust/arrayvec/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=2 -C embed-bitcode=no --cfg 'feature="default"' --cfg 'feature="serde"' --cfg 'feature="std"' --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values("borsh", "default", "serde", "std", "zeroize"))' -C metadata=add52402532b38f0 -C extra-filename=-d845b4f1b5a30a09 --out-dir /wrkdirs/usr/ports/mail/thunderbird-esr/work/.build/x86_64-unknown-freebsd/release/deps --target x86_64-unknown-freebsd -C linker=/wrkdirs/usr/ports/mail/thunderbird-esr/work/thunderbird-140.12.0/build/cargo-linker -C strip=debuginfo -L dependency=/wrkdirs/usr/ports/mail/thunderbird-esr/work/.build/x86_64-unknown-freebsd/release/deps -L dependency=/wrkdirs/usr/ports/mail/thunderbird-esr/work/.build/release/deps --extern serde=/wrkdirs/usr/ports/mail/thunderbird-esr/work/.build/x86_64-unknown-freebsd/release/deps/libserde-eba5f8996fb9e618.rmeta --cap-lints warn -C force-frame-pointers=yes --cap-lints warn -C -Cembed-bitcode=yes -C codegen-units=1` error[E0425]: cannot find type `_CharT` in this scope --> /wrkdirs/usr/ports/mail/thunderbird-esr/work/.build/x86_64-unknown-freebsd/release/build/gecko-profiler-5489ce8c21f2e7d4/out/gecko/bindings.rs:1821:83 | 1821 | pub type basic_string___self_view = root::std::__1::basic_string_view<_CharT>; | ^^^^^^ not found in this scope | help: you might be missing a type parameter | 1821 | pub type basic_string___self_view<_CharT> = root::std::__1::basic_string_view<_CharT>; | ++++++++ For more information about this error, try `rustc --explain E0425`. error: could not compile `gecko-profiler` (lib) due to 1 previous error
What version of the devel/rust-cbindgen do you have installed?
(In reply to Vladimir Druzenko from comment #1) From the build log: ===> Installing existing package /packages/All/rust-cbindgen-0.29.3_1,1.pkg
I also tried after the following commit: https://cgit.freebsd.org/ports/commit/?id=625b0ffb538d671ad8941210da2b9994c18580c0 but it seems that I'm getting the same error.
It looks the same as in https://pkg-status.freebsd.org/beefy24/data/main-amd64-default/pa0749cabd9a7_s69e20977a46/logs/thunderbird-esr-140.12.0.log
Both thunderbird-esr and firefox-esr build find on -RELEASE, but some recent change in libc++ seems to trip up some part when generating the bindings (the bindgen process having problems with libc++ happens from time to time). I can't pinpoint what change in 152 works around that issue (or which change is missing from 140 to make it work), and given that esr will switch to 153 in about four weeks, I'm not going to put much time into this issue (I'm always short on time, so there's that). Maybe just switch to 152 right now (I don't really see the appeal of a >6month old browser engine - especially on -STABLE or even -CURRENT - anyway).
(In reply to Christoph Moench-Tegeder from comment #5) Actually not (it does not build on release), at least in my case. I'm on 14.4p6, using 2026Q2 port tree, but it stopped building after the upgrade to 140.11. Full Poudriere log here: https://www.netfence.it/download/tb.log I understand the point of the comment above; still, if it would be possible to get an hint, I'd be grateful.
(In reply to ml from comment #6) Seems the reason is in: https://bugzilla.mozilla.org/show_bug.cgi?id=2006630 although that bug is deemed as closed.
Hm, that's funny, as the same -esr port is fine on main. But then, your rust is already two releases behind, who knows what's happening there.
ports b6c45399597e in 2026Q2 fixes the cargo-checksums issue. The original issue from this PR ("_CharT not found in this scope") remains elusive - I cannot reproduce that on 14.4-RELEASE neither in main nor 2026Q2. With the imminent EOL of 2026Q2 (less than two weeks from now), I'd recommend switching to main for the time being over hoping for a fix.
(In reply to Christoph Moench-Tegeder from comment #9) Thanks a lot. I can confirm it now compiles and works. (WRT to switching to main: unfortunately my hardware does not allow it; a single little change like the recent python minor update can trigger a 48h long poudriere run; using main I'd always have my building machine blocked).
First, stubbornly run the following command until it completely gets stuck. make -C /usr/ports/mail/thunderbird-esr/ build After that, prepare /usr/include for 14.4-RELEASE using the following steps. mdconfig -a -t vnode -o readonly -f /tmp/FreeBSD-14.4-RELEASE-amd64-disc1.iso -u 0 mount -t cd9660 /dev/md0 /mnt mount -t nullfs /mnt/usr/include /usr/include When the next command is run again, it escapes from the stack. make -C /usr/ports/mail/thunderbird-esr/ build In other words, there is something wrong with the header included in the updated llvm.
(In reply to Tatsuki Makino from comment #11) comment #11 means 14.4-STABLE is building thunderbird-esr using the /usr/include header set from 14.4-RELEASE. I also tried building using the 15.1-RELEASE header set. Building thunderbird-esr following this procedure was also successful and completed. mdconfig -a -t vnode -o readonly -f FreeBSD-15.1-RELEASE-amd64-disc1.iso -u 0 mount -t cd9660 /dev/md0 /mnt mount -t nullfs /mnt/usr/include /usr/include make -C /usr/ports/mail/thunderbird-esr/ I_DONT_CARE_IF_MY_BUILDS_TARGET_THE_WRONG_RELEASE=1 clean make -C /usr/ports/mail/thunderbird-esr/ I_DONT_CARE_IF_MY_BUILDS_TARGET_THE_WRONG_RELEASE=1 build This is a problem that can only be reproduced on 14.4-STABLE, specifically on 1404501. The 14.4-STABLE I used is stable/14-n274330-4df539cc3864-dirty. (In reply to Christoph Moench-Tegeder from comment #5) > (I don't really see the appeal of a >6month old browser engine - especially on -STABLE or even -CURRENT - anyway) Firefox, being just a web browser, can be released with bugs and we can easily discard our profiles, but Thunderbird is used for reading and writing emails. It is often very troublesome if a bug is discovered after the profile has been converted to a new version :)
Unfortunately just a 'fails here too' with root::std::__1::basic_string_view<_CharT>; | ^^^^^^ not found in this scope I'm on stable/15, so llvm21. When I defined the make(1) variable DEFAULT_VERSIONS+=llvm=21 (testing if I can avoid llvm19 dependency - reducing the five (5!) compilers dependency in my ports build chroot) I had some more ports failing due to explicit cast changes with C++23. I mechanically replaced assert(somevar) to assert(somevar != nullptr), which was already in the code base of all the failing ports, just not consistently used (botan3 was one of them I remember). My skills are way too lousy to debug the root cause myself (rust and C likewise), sorry. I wonder why pkg(1) registers a dependency on gcc14 for rust-cbindgen-0.29.4,1: rust-1.96.1 FreeBSD-clibs-15.1.501.4~*pre (libc.so.7) gcc14-14.2.0_6 (libgcc_s.so.1) FreeBSD-clibs-15.1.501.4~*pre (libgcc_s.so.1) FreeBSD-clibs-15.1.501.4~*pre (libthr.so.3) Probably totally unrelated - and simply because of the SO name collision... Maybe cmt@ finds time trying to reproduce on stable/15? Thanks for your highly appreciate maintainer commits!
I have only reached the stage of finding the word, but if it is used, would anything change? -D_LIBCPP_USE_FROZEN_CXX03_HEADERS
This is probably due to the behavior of rust-bindgen 0.69.4. It seems that it can be avoided by directly rewriting part like the following in /usr/include/c++/v1/string. - using __self_view _LIBCPP_NODEBUG = basic_string_view<_CharT, _Traits>; +typedef basic_string_view<_CharT, _Traits> __self_view; (In reply to Tatsuki Makino from comment #14) The use of _LIBCPP_USE_FROZEN_CXX03_HEADERS also requires that __cplusplus be less than 201103, so just defining this is not enough to use it. If it had been conditions like following, we could have forced it to be used :) #if defined(_LIBCPP_USE_FROZEN_CXX03_HEADERS) && (__cplusplus < 201103L || _LIBCPP_USE_FROZEN_CXX03_HEADERS) The method of using -isystem/usr/include/c++/v1/__cxx03 to make the __cxx03 headers be read first fails. In addition, when setting the cflags for bindgen, it seems that the port variable should be set as follows. CONFIGURE_ENV+= BINDGEN_CFLAGS=-isystem/usr/include/c++/v1/__cxx03 For now, within the range I have tried, it seems that there is no workaround available from the thunderbird-esr port side.
140-esr is now gone.
(In reply to Christoph Moench-Tegeder from comment #16) thunderbird-esr-153.0_1 build succeeds without any problems in the environment where this issue occurs. By migrating to esr-153, this issue can be considered resolved.
I can confirm successful build of thunderbird-esr-153.0_1[.pkg] on stable/15 (with DEFAULT_VERSIONS+=llvm=21) as well. Thank you very much for your hightly appreciated maintainer efforts!