Tests
- Win32Link linked under the Flatpak only with a C file defining
__libc_single_threaded. crafter-build gave clang the host's /usr as
the MinGW sysroot, which put glibc's headers on the include path, and
libstdc++'s shared_ptr, inlined from nlohmann/json in Crafter.Asset's
GLB loader, then read the symbol. crafter-build 5.0.0 shows clang only
the mingw-w64 parts of /usr (Catcrafts/Crafter.Build#43), so nothing
references it any more. Under 5.0.0 Win32Link links without it, and so
does examples/HelloUI, which no stand-in covered. The native
crafter-build on the host, which never had the problem, still builds
PointerWin32, TextWin32 and Win32Link and runs them under Wine.
Docs
- AGENTS.template.md and AGENTS.consumer.md: linking for Win32 under the
Flatpak needs crafter-build 5.0.0, and the workaround is gone.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Build
- The MinGW toolchains ship no import library for vulkan-1.dll, so
without a Vulkan SDK's every Win32 executable stopped at "unable to
find library -lvulkan-1". project.cpp now makes one with the
llvm-dlltool beside the toolchain's llvm-ar, from Vulkan-Loader's
loader/vulkan-1.def. That is the loader's own list of what
vulkan-1.dll exports, fetched with GitFetch, unpinned like
Vulkan-Headers, so the API the library compiles against and the
exports it links against move together. The import library the Wine
runs used, made from the calls the library happened to make, went
stale with the next new call (234fcce added
vkEnumerateInstanceExtensionProperties). The loader's list does not,
and a call it does not export fails at link time instead of when the
exe starts.
- It is made into build/vulkan-1-<target>/ when a stamp beside it,
holding the command and the .def it was made from, no longer matches;
a fetch or a copy says nothing through the .def's mtime. It goes into
the link by its absolute path rather than through -L, so it shadows
no consumer's Vulkan SDK library. A failed fetch or llvm-dlltool run
is a Progress::Diagnostic warning, and the link falls back to the
library a previous load made, or to -lvulkan-1.
- -luuid joins the Win32 link flags: the gamepad code compares against
IID_IUnknown and IID_IAgileObject, and StartSync's Gamepad::Tick pulls
it into every executable (#184).
- project.cpp uses ShellQuote, exported from crafter-build 3.0.0, which
is now the minimum.
Tests
- Win32Link: an executable that uses the library as an application does
(Device::Initialize, a Window, StartSync) links. Without Wine it runs
as --runner=cmd:true, which builds it and runs nothing; under Wine it
also opens a window and closes it. It fails to link without -luuid
(IID_IUnknown, IID_IAgileObject) and without the import library
("unable to find library -lvulkan-1"). Under the Flatpak it needs
tests/Win32Link/libc-single-threaded.c, which stands in for
Catcrafts/Crafter.Build#43 and goes with it.
- With the native crafter-build on the host, which has Wine and finds
the host's mingw-w64 itself, PointerWin32, TextWin32 and Win32Link now
build and pass under Wine with nothing added.
Docs
- AGENTS.md: the minimum crafter-build, the Vulkan-Loader fetch and what
project.cpp runs, the Win32Link check in the commands and the
done-list, and a one-line Wine recipe in place of the hand-built
import library, shim and project.cpp edit. AGENTS.consumer.md: the
minimum, how the import library is made, and the
__libc_single_threaded workaround under the Flatpak. README: the
minimum, the Win32 build command, and that it needs no Vulkan SDK.
Closes#184.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
