It looks like the LLVM bug that made Rust fail to build is gone (or Rust just doesn't trigger it anymore). I tested that Rust itself and Firefox build.
Bump PORTREVISION because of dependency change.
PR: 247388
Approved by: tobik (maintainer)
- Remove devel/cargo-tree since it is now integrated into cargo
- Add patch to fix build with LibreSSL 3.1.x and 3.2.0 [1]
- Force rebuild all consumers to catch regressions early
Changes: https://blog.rust-lang.org/2020/06/04/Rust-1.44.0.html
PR: 246332 [1]
Tested by: mikael, tobik
With hat: rust
Differential Revision: https://reviews.freebsd.org/D25099
It is possible for lang/python37 to be built in such a way that it
installs an unloadable lzma module which then causes Rust to fallback
to trying to fetch/extract the tar.gz bootstraps instead.
As a workaround and since it also simplifies some things, let the
ports framework extract the bootstraps and "install" them under
WRKDIR. We point the build to them in config.toml. This is similar
to how things are hooked up in lang/rust-bootstrap and Rust will
then not try to fetch and extract the bootstraps on its own.
PR: 243766
Reviewed by: mikael
Differential Revision: https://reviews.freebsd.org/D24582
- Add workaround to fix build when CC/CXX have "clang" in them [1]
- Respect AR to fix build with external toolchains [2]
- Force rebuild all consumers to catch regressions early
Changes: https://blog.rust-lang.org/2020/04/23/Rust-1.43.0.html
PR: 238556 [1], 245583 [2]
Reported by: Matthias Apitz <guru@unixarea.de> [1], Greg V <greg@unrelenting.technology> [2]
Tested by: mikael, pkubaj, tobik
With hat: rust
Differential Revision: https://reviews.freebsd.org/D24521
error: could not find native static library `stdc++`, perhaps an -L flag is missing?
error: aborting due to previous error
error: could not compile `rustc_llvm`.
PR: 244813
After upgrade to LLVM 10, core in stage 1 fails to compile (no clear reason, rustc crashes):
pid 26828 (rustc), jid 0, uid 0: exited on signal 11 (core dumped)
Compilation with GCC works fine, so switch to GCC for the time being.
PR: 244813
Approved by: mikael
libgit2-sys is now based on libgit2 0.99.0. While 0.99.0 is supposed
to be API compatible with 0.28, it has not yet been updated in the
ports tree and the git2 crate now make use of some of the new
function return values. Stop relying on system libgit2 and use the
bundled one. Upstream does not make any guarantees about system
libgit2 support in the first place.
Changes: 6d69caba11...96bb8b31c8
It sometimes fails [0,1] and sometimes succeeds [2,3]. When it
fails it fails with
running: "cmake" "/wrkdirs/usr/ports/lang/rust/work/rustc-1.41.1-src/src/llvm-project/lld" "-DCMAKE_INSTALL_MESSAGE=LAZY" "-DCMAKE_C_COMPILER=cc" "-DCMAKE_CXX_COMPILER=c++" "-DCMAKE_C_FLAGS=-ffunction-sections -fdata-sections -fPIC -m64 -pipe -fstack-protector-strong -fno-strict-aliasing" "-DCMAKE_CXX_FLAGS=-ffunction-sections -fdata-sections -fPIC -m64 -pipe -fstack-protector-strong -fno-strict-aliasing" "-DLLVM_CONFIG_PATH=/wrkdirs/usr/ports/lang/rust/work/rustc-1.41.1-src/build/bootstrap/debug/deps/llvm-config-wrapper" "-DLLVM_INCLUDE_TESTS=OFF" "-DCMAKE_INSTALL_PREFIX=/wrkdirs/usr/ports/lang/rust/work/rustc-1.41.1-src/build/x86_64-unknown-freebsd/lld" "-DCMAKE_BUILD_TYPE=Release"
-- The C compiler identification is Clang 9.0.1
-- The CXX compiler identification is Clang 9.0.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:23 (message):
llvm-config failed with status No such file or directory
-- Configuring incomplete, errors occurred!
There seems to be some kind of race when using llvm-config-wrapper,
but at the point where LLD is built, both llvm-config and
llvm-config-wrapper should definitely be available. Both are built
successfully much earlier in the build. Attempt to improve reliability
by not using the wrapper. It is a hack in the first place that is
only really needed on Windows.
This is a shot in the dark. I am unable to reproduce this myself.
[0] http://beefy18.nyi.freebsd.org/data/head-amd64-default/p527397_s358451/logs/errors/rust-1.41.1.log
[1] http://gohan03.nyi.freebsd.org/data/head-amd64-default-baseline/p527486_s358478/logs/errors/rust-1.41.1.log
[2] http://beefy18.nyi.freebsd.org/data/head-amd64-default/p527397_s358451/logs/rust-nightly-1.43.0.20200228.log
[3] http://gohan03.nyi.freebsd.org/data/head-amd64-default-baseline/p527313_s358414/logs/rust-1.41.1.log
- Force rebuild all consumers to fix potential miscompilations with
1.41.0
- Enable SOURCES by default. The sources are indexed by RLS and
required for it to function properly, so they should be available
by default. This also makes sure we test the option properly.
- Remove implied --config=config.toml from x.py args
- Switch to the upstreamed backtrace crate patches like rust-nightly
- Enable WASM by default [0]
- Strip libraries (D23650) [1]
- Simplify plist generation (D23735) [2]
Changes: https://blog.rust-lang.org/2020/02/27/Rust-1.41.1.html
Submitted by: mikael [0,1,2]
With hat: rust
Differential Revision: https://reviews.freebsd.org/D23835
Add the WASM (WebAssembly) option to build the wasm32-unknown-unknown target, off by default.
Reviewed by: tobik
Approved by: tobik, manu (mentor)
Differential Revision: https://reviews.freebsd.org/D23653
- Force rebuild all consumers to catch regressions early
- Switch to cross-compiled (from amd64) bootstraps for all
architectures generated with the incoming lang/rust-bootstrap
- Update cargo-c to 0.5.2 to unbreak librav1e build
- Make use of regular MAKE_ENV/TEST_ENV in lang/rust
- Turn on RUST_BACKTRACE in lang/rust and USES=cargo to hopefully
produce more useful failure logs when something panics during
builds
Changes: https://blog.rust-lang.org/2020/01/30/Rust-1.41.0.html
Tested by: mikael, tobik
With hat: rust
Differential Revision: https://reviews.freebsd.org/D23385
= note: ld: error: relocation R_386_PC32 cannot be used against symbol __rust_probestack; recompile with -fPIC
>>> defined in /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libcompiler_builtins-6570a75fe85f0e1a.rlib(compiler_builtins-6570a75fe85f0e1a.compiler_builtins.2i519eqi-cgu.15.rcgu.o)
>>> referenced by std.4xivr03c-cgu.14
>>> std-9bd70afd58e204b7.std.4xivr03c-cgu.14.rcgu.o:(_$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h1c78ed6e734a2bfc (.llvm.10122419023709863394)) in archive /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libstd-9bd70afd58e204b7.rlib
ld: error: relocation R_386_PC32 cannot be used against symbol __rust_probestack; recompile with -fPIC
>>> defined in /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libcompiler_builtins-6570a75fe85f0e1a.rlib(compiler_builtins-6570a75fe85f0e1a.compiler_builtins.2i519eqi-cgu.15.rcgu.o)
>>> referenced by std.4xivr03c-cgu.14
>>> std-9bd70afd58e204b7.std.4xivr03c-cgu.14.rcgu.o:(std::io::util::copy::h9115f048f2203467) in archive /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libstd-9bd70afd58e204b7.rlib
clang-cpp: error: linker command failed with exit code 1 (use -v to see invocation)
error: aborting due to previous error
http://beefy17.nyi.freebsd.org/data/head-i386-default/p523508_s356869/logs/rust-nightly-1.42.0.20200118.log
This attempts to provide a nicer error message for the subset of
users who build their own kernels without COMPAT_FREEBSD11 and then
attempt to build lang/rust. The Rust ecosystem currently uses
pre-ino64 syscalls, so building lang/rust without COMPAT_FREEBSD11
is not going to work.
The error message for this is non-obvious and there is a new bug
for this at least every 1-2 months. Hopefully this will improve
the situation a little.
Cargo and Gecko ports are similarly affected, so add the pre-build
check to them too.
Reviewed by: jbeich, mikael.urankar@gmail.com
Tested by: madpilot (negative case)
Approved by: gecko (jbeich)
Differential Revision: https://reviews.freebsd.org/D23100
Apparently there were some issues with the previous one.
PR: 243253
Submitted by: mikael.urankar@gmail.com
Reported by: jhibbits, pkubaj
Tested by: pkubaj
lang/rust-nightly does not have powerpc64 in it and unconditionally
running makesum for the powerpc64 ELFv2 bootstraps breaks there.
PR: 242342
Reported by: jbeich
The backtrace-sys crate no longer needs gmake since 0.1.20.
sysutils/flowgger still uses backtrace-sys-0.1.14. Since it is the
only USES=cargo port left that needs it, move the gmake dependency
directly to it instead.
lang/rust currently has backtrace-sys-0.1.30. It also vendors
jemalloc-sys (which also needs gmake to build) but it is hidden
behind rustc's jemalloc feature which we do not currently activate.
It should be safe to remove gmake in lang/rust too.
PR: 242267
Reported by: mikael.urankar@gmail.com
- Spell LICENSE_FILE_APACHE20 correctly
- Move gmake to BUILD_DEPENDS directly. gmake is called during the
build by some crates but is not the primary build tool.
- Move variables around to be more in line with the recommendations
in the Porter's Handbook
- Mark port local non-overridable variables as "private"
- Reduce noise of RUST_ARCH_*: only keep the overrides when they
differ from ${ARCH}
- Drop unused RUST_TARGET plist sub
- Move post-configure-DOCS-* into do-configure
error: couldn't load codegen backend "/usr/ports/lang/rust/work/rustc-1.37.0-src/build/armv6-unknown-freebsd/stage1/lib/rustlib/armv6-unknown-freebsd/codegen-backends/librustc_codegen_llvm-llvm.so": "/usr/ports/lang/rust/work/rustc-1.37.0-src/build/armv6-unknown-freebsd/stage1/lib/rustlib/armv6-unknown-freebsd/codegen-backends/librustc_codegen_llvm-llvm.so: Undefined symbol \"__clear_cache\""
__clear_cache is implemented in compiler-rt and was dropped upstream with [1]:
aa41e0d25f
For some unknown reason this is a problem on armv6. Bring back the
compiler-rt submodule for now to workaround this.
Submitted by: mikael.urankar_gmail.com
Differential Revision: https://reviews.freebsd.org/D21415
as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3
to GCC 9.1 under most circumstances now after revision 507371.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, everything INDEX-11 shows with a dependency on lang/gcc9 now.
PR: 238330
