Add an `llvm-tools` target artifact that downloads llvm-project source
matching the version of clang shipped by the active zig install,
builds llvm-objcopy, llvm-strip and llvm-profdata into
PKG_ROOT_PATH/llvm-tools/bin, and exposes them through the same
path/binary/isInstalled static surface as the other artifacts.
A new LlvmToolsCheck doctor item runs when the active toolchain is
ZigToolchain and reports whether the three tools are built, with a
fix that installs the package and runs the build.
PackageBuilder now picks the right tool when the active toolchain is
ZigToolchain:
- extractDebugInfo() honours OBJCOPY from the environment, then falls
back to llvm-tools' llvm-objcopy under Zig and plain objcopy
otherwise.
- stripBinary() uses llvm-strip under Zig and plain strip otherwise.
System strip/objcopy refuse zig-produced archives and bitcode
sections, so without this the strip stage breaks LTO builds. Other
toolchains keep using the system binaries.
ApplicationContext::tryGet() wraps the container's get() in a
try/catch and returns null on failure, so PackageBuilder can ask
"which toolchain is active right now" without PHP-DI throwing on
autowirable-but-unconstructable classes.
Depends on v3c/artifact-static-helpers (uses zig::isInstalled()
and zig::binary()).
Switch the rust and go_win downloaders from baking PKG_ROOT_PATH into
the extract path at download time to the {pkg_root_path} template,
which ArtifactExtractor resolves at extract time. This keeps the path
stable across runs where pkg_root_path differs between download and
extract (e.g. containerised vs host builds).
The shell invocation runs `$CXX -c` to compile watcher-c.cpp to a .o,
which never links. Passing linker flags to a compile-only step is
either ignored or, with some flags, an error. Drop them.
ax_gcc_archflag has no Zen cpuid pattern and falls back to
-mtune=amdfam10, which under LLVM+LTO emits SSE4a extrq and SIGILLs on
Intel hosts. Disable the implicit --with-gcc-arch so host CPU features
do not bleed into the built binaries.
ftp.gnu.org is unreliable and frequently times out during CI builds.
ftpmirror.gnu.org is GNU's own CDN that auto-redirects to the nearest
mirror. This is the recommended download method per
https://www.gnu.org/prep/ftp.en.html
Also normalizes /pub/gnu/ paths to /gnu/ since ftpmirror only serves
the latter.
Affects: libiconv, gettext, gmp, idn2, libunistring, ncurses, readline
-fno-plt is an ELF-only flag that has no effect on macOS Mach-O
targets — clang emits "argument unused" when it encounters it.
Libraries like xz that run -Werror sanity checks during configure
promote that warning to a fatal error, breaking the build.
vswhere.exe defaults to searching Community, Professional, and
Enterprise editions only. CI environments typically install the
lightweight Build Tools product which is a separate product type
(Microsoft.VisualStudio.Product.BuildTools). Without -products *
the tool returns no results and the build fails with "Visual Studio
with C++ tools not found".
See: https://github.com/microsoft/vswhere/wiki/Find-MSBuild
