QA notice: Can't migrate to llvm-r2.eclass as long as cargo.eclass still
references the incompatible llvm-r1.eclass.
Signed-off-by: Henrik Steffen Gaßmann <henrik@gassmann.onl>
QA notice: Can't migrate to llvm-r2.eclass as long as cargo.eclass still
references the incompatible llvm-r1.eclass.
Signed-off-by: Henrik Steffen Gaßmann <henrik@gassmann.onl>
Drop the mig-require-libz3 patch since upstream removed that test. Two new
tests need handling for our Z3-less external-llvm build: disable Z3
discovery with Z3_DISABLE so the z3 integration tests skip instead of
running against a circt that has no Z3 backend, and symlink circt's empty
llvm submodule at the real tree so the circt-tblgen tests find their mlir
tablegen includes.
Signed-off-by: Huang Rui <vowstar@gmail.com>
Upstream renamed the release tarball asset from yosys.tar.gz to
yosys-src.tar.gz, so point SRC_URI at the new name.
Signed-off-by: Huang Rui <vowstar@gmail.com>
This release moves KactusColors and LibraryModel into libKactusAPI, so
the executable now links symbols from it. Force the in-tree lib dir ahead
of /usr/lib64 in the link path, otherwise an already installed kactus2
shadows the fresh library and the build fails with undefined references.
Also drop py3.10/py3.11 and the stale 3.12/3.13 ebuilds.
Signed-off-by: Huang Rui <vowstar@gmail.com>
Build without the new default slang feature, which fetches and compiles
the slang SystemVerilog parser and its C++ dependencies from the network
at build time. Bump RUST_MIN_VER to 1.89 to match upstream.
Signed-off-by: Huang Rui <vowstar@gmail.com>
The circt-synth mig.mlir integration test was missing the libz3 and
circt-lec-jit REQUIRES guards that every sibling LEC test carries, so it
ran its circt-lec JIT commands and failed on unresolved Z3 symbols
instead of being skipped. Patch it to add the guards.
Closes: https://bugs.gentoo.org/977874
Signed-off-by: Huang Rui <vowstar@gmail.com>
While working on updates to resolve GCC 16 build issues, I backported an
upstream patch for removing a reference to `<linux/scc.h>` (80fbc4c2a);
simultaneously, a similar patch was added (731832ced) that introduced
the same fix. The conflict wasn't caught during the rebase.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
Updates LLVM_COMPAT to allow building Swift 6 with LLVM/Clang 22, and
reintroduces a `libcxx` USE flag to allow dropping a hard dependency on
GCC <16 on systems that don't want to use it.
Swift 5.10 does not build with Clang 22.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
Backports an upstream patch for building LLVM sanitizers on systems
where `<linux/scc.h>` is no longer present.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
Swift defaults to building against GCC's libstdc++ runtime, but GCC 16's
headers can only be parsed by Clang 22 and later. Swift's LLVM will pick
up on the newest headers available on disk, which means that even if GCC
16 is simply installed on the build machine, Swift will fail to build.
Depending on GCC <16 and explicitly setting `--gcc-install-dir` allows
the right headers to be picked up.
Closes: https://bugs.gentoo.org/974722
Signed-off-by: Itai Ferber <itai@itaiferber.net>
The custom Swift build system doesn't correctly pass
CFLAGS/CXXFLAGS/LDFLAGS to invocations of CMake, nor does the Swift
compiler pick up on those env vars automatically to pass to Clang. The
build system needs to be patched to pass these flags around explicitly,
and a few sites were missed during original patching.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
