let's say you want to build an application that uses Qt as a statically linked binary, and you want to avoid building two dozen dependencies yourself
is there any existing cross-platform solution which will do that for me and also isn't vcpkg?
it appears that my two options are "Nix, maybe" and "horrifying meta-CMake abomination"
i'm trembling in anticipation of writing the horrifying meta-CMake abomination
(in terror? in excitement? you decide)
i think pkgsrc and gentoo would probably solve my problem for Linux (and maybe macOS) but neither of them will produce Windows binaries with MSVC. the search continues
@whitequark I think conda-forge ships static builds of Qt
@MissingClara it does but i think i like conda even less than vcpkg >.>
@whitequark vcpkg sadly does not fix the 'avoid building' part. Our closest competitor is conan; I don't know if they have what you want though. (I'm trying to keep our ship afloat rather than admiring the other ship :) )
@malwareminigun I'm looking at vcpkg having claude commits, including some pretty questionable qt patches, not building properly with static libc, and just... ehhhh
@malwareminigun I think it would be good if Microsoft as a whole wasn't kind of a sinking ship, the overall design seems ok to me so far, it's not awful to use
@whitequark I'm working on this thing because when I was a standard library maintainer, I saw that Networking was never going to meet `std::`'s ABI requirements, and decided that getting people to real ASIO if they wanted networking was a problem that needed solved.
I care about this mission and hope to make it good regardless of ... my employer's reputation. But I understand for those philosophically opposed to touching LLM'd content that kind of categorically excludes us :(
I'm curious on those qt patches; qt is unfortunately one of the most ... problematic ports we have that takes a lot of whacking over the head to behave.
@malwareminigun it's not just philosophical opposition here; I'm pretty concerned about having something malicious slip by for a security-sensitive application, and auditing vcpkg upgrades is basically impossible (both in general and because of the amount of patches)
this is probably OK for the Windows build because if you run the Windows build you implicitly trust Microsoft anyways, but for the portable Linux build I'm really not sure that vcpkg is the right idea (macOS currently uses it too, no concrete thoughts on that yet)
@whitequark Do you mean upgrades of the vcpkg executable or upgrades of ports in the registry? If the former we do go out of our way to make it relatively easy to build because if we get run on a platform we don't know in advance we fall back to building ourselves from source.
If the latter, we have some diff tools but nothing really turnkey right now. If you don't trust Microsoft then you probably don't want to trust our registry either.
https://github.com/microsoft/vcpkg-tool/pull/1980 is very close (thanks autoantwort!)
@malwareminigun registry
@whitequark I mean, anything that touches the network is questionable with a static libc because DNS lives in libc and DNS has a lot of machine-dependent behavior.
We do have LLM contributions; can't really separate out who pays the bills :/
@malwareminigun not with musl! (I would not ship something with a static glibc, that sounds ... irresponsible)
@whitequark I thought our musl version was built with a static libc so I'm not sure what you mean... https://github.com/microsoft/vcpkg-tool/blob/d51657069fcf70c67fa6411a0c81ced30c087904/azure-pipelines/signing.yml#L266
Specifically -DCMAKE_CXX_FLAGS=\"-s -static-libgcc -static-libstdc++\"
@malwareminigun sorry, I mean "if you use musl then you don't have issues with DNS with static libc because musl does not have nsswitch"
@whitequark It's entirely possible I screwed up the muslc version. It's intended to be static but maybe I had glibc brain at the time? It's *intended* to work with a static muslc if you want.
Should I just build on Alpine and check with ldd or is there something else I should confirm?
@malwareminigun sorry I feel like we're talking past each other a bit. I was responding to
I mean, anything that touches the network is questionable with a static libc because DNS lives in libc and DNS has a lot of machine-dependent behavior.
by saying that I don't think it's questionable if I use musl
separately from that, I just discovered to my mild displeasure that vcpkg wouldn't build a musl sysroot for me (the -musl switch seems to do... nothing useful if you run it on Debian)
@whitequark If you mean the bootstrap script that just changes the copy of our binary that gets downloaded. `-musl` is intended as an escape hatch if we download the glibc copy on a musl system to whack the bootstrapper over the head and say "download the musl one damnit".
We are not trying to setup an entire "linux sysroot" or that sort of thing; in particular we think binary deployment is better done by existing tools like apt/dnf/pacman/zypper/etc. and explicitly aren't packaging *applications* because we think our UX is bad for what apt customers want.
EDIT: And sorry for potential talking past. I just want to make sure if there is stuff that you would want fixed that is within my power to fix that it is fixed.
@malwareminigun I don't think there's anything to fix! I just did not entirely understand the scope or design of vcpkg
well, there's a packaging bug where dbus can't be built with staticcrt (presumably because it builds both the daemon and the library in the same package, with no feature flags?) but it's not an issue with the core package manager
@whitequark If that changes just poke. For now I'll just keep thinking of this image.
dbus port has been no end of confusion for us because they do need that daemon but it really seems intended that "there can be only one" on a system and we REALLY don't want to step on systemwide package managers' toes
@malwareminigun I'm super confused re: dbus
most packages just need libdbus-1 which is normally built as a static library (unless I misremember)
the applications aren't expected to build the daemon. some of them will want to ship and run it, yeah, but only a small subset and only really on Windows?
@whitequark
NetBSD's pkgsrc might do the trick for you. Supports practically every relevant (and irrelevant) OS.
@be0ba thank you! sounds super promising
@be0ba I looked at it but I think it's not a very good fit for specifically this: it seems to build Qt with basically every feature, while I need as few as possible (no Quick, for example)
also no Windows, but that's more of a wish
@whitequark
Ah, but that's the glory of pkgsrc. You should be able to configure the build options. It's not as smooth as Gentoo's ports system, but they both have a common ancestor. I haven't looked at the options set up for Qt specifically though.
@be0ba I had assumed upon seeing only three options in the documents that this is all the system has to offer
Apr 21, 2026, 4:50 AM@whitequark I had success in the past cross-compiling for windows using mxe.cc. From recollection I was just using a pretty basic Makefile.
(this would have been ~15 years ago on Qt5)
@whitequark could BuildStream help? idk if any of the existing recipes build qt for windoze but if you make one it will do an okay job for caching it and downloading from a remote cache next time in CI etc.
@whitequark I'm genuinely not sure if its Windows support is up to the task, but it's potentially worth at least tinkering with meson before going down the abomination path. (I've successfully built things for Windows with meson, but they were just some simple Python C extensions, nothing actually complicated)
@whitequark maybe look at spack? I don't know if it quite meets your needs for static builds, but it is good at managing and auto building complex dependency trees.