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>
Odin explicitly builds using `clang++` regardless of toolchain. Older
Odin ebuilds explicitly cleared `CPPFLAGS` and `CXXFLAGS` with the
comment "build_odin.sh sets its own flags. Some gcc flags cause build
failures"; this stripping was later migrated to `strip-flags`.
Full stripping isn't necessary, though: the Odin build script _appends_
its own flags instead of replacing them, and GCC-specific flags can be
stripped using `strip-unsupported-flags` instead.
Closes: https://bugs.gentoo.org/974732
Signed-off-by: Itai Ferber <itai@itaiferber.net>
d201619d3 introduced a check for a Swift compiler to use for
bootstrapping Swift 6, but typo'd the variable name used in one case.
This only affected in-place upgrades with no other Swift version
installed, so wasn't caught in testing.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
Hardens the src_install phase by validating that the expected image
exists in the downloaded package, and dies if copying those files to
"$ED" fails.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
The `swift-bin-6.3*-r1` gpkgs were incorrectly manually packaged using
the wrong top-level dirname (`swift-6.3*` instead of `swift-6.3*-r1`),
causing the distfile to download and install successfully, but leaving
an empty tree. The distfiles have been fixed.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
Swift 5.10 dynamically links against ICU using versioned libs (e.g.,
libicuuc.so.<vers> instead of libicuuc.so); this leads to unresolved
SONAME dependencies on systems with differing ICU versions. The built
binaries have been updated to link against unversioned dynamic libs
instead.
Closes: https://bugs.gentoo.org/974734
Signed-off-by: Itai Ferber <itai@itaiferber.net>
When `PYTHON_COMPAT` was updated to support `python3_14`,
`python_gen_cond_dep` wasn't also updated; since we're not trying to
filter Python versions beyond `PYTHON_COMPAT`, we don't actually need to
pass anything in.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
swift-6* ebuilds checked for the latest installed version of
`dev-lang/swift` to build against, but we want to enable bootstrapping
from `dev-lang/swift-bin`. Instead of checking for the latest Swift
using `best_version`, we can check `eselect swift` directly.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
Introduces the `binary` USE flag (on by default) which allows
bootstrapping from `dev-lang/swift-bin` instead of building from source
using `dev-lang/swift`.
Swift 5.10 is becoming increassingly less desirable as a standalone
Swift version, and more difficult to build over time with newer
toolchain versions. For bootstrapping specifically, using a pre-built
binary is likely an acceptable default.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
swift-bin-6.3* ebuilds were accidentally introduced with a SLOT of "6/2"
when they should have been using "6/3".
Signed-off-by: Itai Ferber <itai@itaiferber.net>
The postrm() phase attempts to remove symlinks to installed Swift
versions; the `rm` invocation was missing `|| die` or `-f` to clearly
indicate what should happen on failure. (In this case, it's okay to
ignore the error and move on.)
Signed-off-by: Itai Ferber <itai@itaiferber.net>
Swift currently fails to build if `dev-libs/libdispatch` is installed
because it globally installs private `libdispatch` headers which get
unexpectedly picked up during the Swift build. Since the headers are not
expected to be present when building Swift on non-Darwin platforms, the
check for the header can be patched out.
Signed-off-by: Itai Ferber <itai@itaiferber.net>
