compat:libarchive 3.8.7 fails to compile for any macOS target in an openkal graph, because its
POSIX backend reaches for an Apple SDK header that openkal does not supply.
compat-x-libarchive/3.8.7/libarchive-3.8.7/libarchive/archive_write_disk_posix.c:125:10:
fatal error: 'TargetConditionals.h' file not found
Reproduced on both paths CI takes: a native build on macos-14, and a cross-build from Linux to
aarch64-macos. The Linux target builds fine.
Why the header is absent rather than merely unfound. openkal-macos ships no headers at all --
neither does openkal-windows -- and every C header in the graph comes from openkal-musl (210 of
them). So the intended shape is a POSIX C environment provided by openkal on every platform, and
TargetConditionals.h is an Apple SDK header that has no counterpart there. libarchive reaches for
it under #ifdef __APPLE__, which the macOS triple defines, so the branch is taken on a target that
cannot satisfy it.
What would fix it, in the order I would try them:
- Build libarchive's POSIX backend without
__APPLE__-conditional paths for openkal targets, so it
takes the generic POSIX branch it already has for other systems.
- Or have the recipe define the handful of
TARGET_OS_* macros the file needs, since under openkal
the answer is fixed at configure time.
- Or declare the package unsupported on openkal macOS targets, so the failure arrives at resolution
rather than three minutes into a compile.
Found while replacing a packaging tool's Python (tarfile + zipfile) with libarchive so the
project would stop needing an interpreter to package itself. libarchive is otherwise a good fit --
it reads both formats through one reader, and it builds and passes tests on Linux.
Related, same shape, different package: mcpplibs:tinyhttps fails on Windows targets for
winsock2.h. Both are packages assuming the host platform SDK where openkal is meant to be the
whole closure.
compat:libarchive3.8.7 fails to compile for any macOS target in an openkal graph, because itsPOSIX backend reaches for an Apple SDK header that openkal does not supply.
Reproduced on both paths CI takes: a native build on
macos-14, and a cross-build from Linux toaarch64-macos. The Linux target builds fine.Why the header is absent rather than merely unfound.
openkal-macosships no headers at all --neither does
openkal-windows-- and every C header in the graph comes fromopenkal-musl(210 ofthem). So the intended shape is a POSIX C environment provided by openkal on every platform, and
TargetConditionals.his an Apple SDK header that has no counterpart there. libarchive reaches forit under
#ifdef __APPLE__, which the macOS triple defines, so the branch is taken on a target thatcannot satisfy it.
What would fix it, in the order I would try them:
__APPLE__-conditional paths for openkal targets, so ittakes the generic POSIX branch it already has for other systems.
TARGET_OS_*macros the file needs, since under openkalthe answer is fixed at configure time.
rather than three minutes into a compile.
Found while replacing a packaging tool's Python (
tarfile+zipfile) with libarchive so theproject would stop needing an interpreter to package itself. libarchive is otherwise a good fit --
it reads both formats through one reader, and it builds and passes tests on Linux.
Related, same shape, different package:
mcpplibs:tinyhttpsfails on Windows targets forwinsock2.h. Both are packages assuming the host platform SDK where openkal is meant to be thewhole closure.