mcpplibs:tinyhttps 0.3.0 fails to compile for any Windows target in an openkal graph: its socket
backend includes the Windows SDK's winsock2, which openkal does not supply.
mcpplibs-x-tinyhttps/0.3.0/tinyhttps-0.3.0/src/socket.cppm:4:10:
fatal error: 'winsock2.h' file not found
Reproduced on both paths CI takes: a native build on windows-2022, and a cross-build from Linux to
x86_64-windows-gnu. The Linux target builds fine and the library works well there.
Why it is absent rather than merely unfound. openkal-windows ships no headers at all --
neither does openkal-macos -- and every C header in the graph comes from openkal-musl. openkal's
shape is a POSIX C environment on every platform, with sockets available through its own API
(openkal.net in the consuming project, kal_* underneath). winsock2 is the host Windows SDK, so
a package that includes it directly is outside the closure on this target.
Worth noting because it hides on a developer machine: a Linux host that happens to have mingw
installed does have a winsock2.h, so the cross-build gets further there and then fails
differently -- on my machine it failed inside compat:zlib with musl/mingw header conflicts
instead. Whether the build fails, and how, depends on what is installed on the machine. I filed
that half as mcpp-community/mcpp#662, since the C compile is given --target and no
-nostdinc/--sysroot, letting clang's own sysroot search find the host's mingw.
What would fix it, in the order I would try them:
- A socket backend over openkal's own socket API for openkal targets, so the library is
platform-independent in the way the rest of the graph is.
- Or declare the package unsupported on openkal Windows targets, so resolution fails with a clear
reason instead of a missing header three minutes in.
Found while replacing a packaging tool's Python (urllib.request) with tinyhttps so the project
would stop needing an interpreter to download its payload inputs. The API fits well --
download_to_file with progress and redirects is exactly the shape needed; it is only the Windows
target that cannot build.
mcpplibs:tinyhttps0.3.0 fails to compile for any Windows target in an openkal graph: its socketbackend includes the Windows SDK's winsock2, which openkal does not supply.
Reproduced on both paths CI takes: a native build on
windows-2022, and a cross-build from Linux tox86_64-windows-gnu. The Linux target builds fine and the library works well there.Why it is absent rather than merely unfound.
openkal-windowsships no headers at all --neither does
openkal-macos-- and every C header in the graph comes fromopenkal-musl. openkal'sshape is a POSIX C environment on every platform, with sockets available through its own API
(
openkal.netin the consuming project,kal_*underneath). winsock2 is the host Windows SDK, soa package that includes it directly is outside the closure on this target.
Worth noting because it hides on a developer machine: a Linux host that happens to have mingw
installed does have a
winsock2.h, so the cross-build gets further there and then failsdifferently -- on my machine it failed inside
compat:zlibwith musl/mingw header conflictsinstead. Whether the build fails, and how, depends on what is installed on the machine. I filed
that half as mcpp-community/mcpp#662, since the C compile is given
--targetand no-nostdinc/--sysroot, letting clang's own sysroot search find the host's mingw.What would fix it, in the order I would try them:
platform-independent in the way the rest of the graph is.
reason instead of a missing header three minutes in.
Found while replacing a packaging tool's Python (
urllib.request) with tinyhttps so the projectwould stop needing an interpreter to download its payload inputs. The API fits well --
download_to_filewith progress and redirects is exactly the shape needed; it is only the Windowstarget that cannot build.