From 874ac309ecbadf311ed812867dd4bc589a91b00f Mon Sep 17 00:00:00 2001 From: Sunrisepeak Date: Wed, 12 Aug 2026 09:24:35 +0800 Subject: [PATCH] fix: stop compat.freetype and compat.zlib leaking GCC-only cflags to MSVC Both declared compiler flags that only GCC and Clang understand in their COMMON cflags, so MSVC received them verbatim. Found while building XRGUI (Sunrisepeak/xrgui#3) with mcpp on windows-latest with MSVC 14.5x: cl : Command line error D8021 : invalid numeric argument '/Wno-implicit-function-declaration' That is compat.freetype, and it is fatal -- the package cannot build on Windows at all. Every consumer goes down with it: harfbuzz's FreeType bridge, msdfgen's ext/import-font, and anything drawing text. compat.zlib's is the quieter and worse-behaved half: cl : Command line warning D9002 : ignoring unknown option '-include' cl : Command line warning D9024 : unrecognized source file type 'mcpp_zlib_config.h', object file assumed cl does not reject `-include`; it warns, drops the flag, and builds. So mcpp_zlib_config.h was never included and the package compiled with a silently different configuration than the recipe describes. On Windows that header is empty by construction (everything in it is behind `#if !defined(_WIN32)`), so nothing was actually miscompiled this time -- but the mechanism would not have told us if it had been. THE FIX Both descriptors already had per-OS sections; the platform-specific flags now live in them. compat.freetype common cflags keep only the FT_* defines. cl accepts -D, so those reach MSVC unchanged. -Wno-implicit-function-declaration -> linux + macosx -D_DARWIN_C_SOURCE -> macosx. It was on every platform, which was wrong on Linux too, just harmlessly so. compat.zlib -D_GNU_SOURCE -> linux; -include mcpp_zlib_config.h -> linux + macosx. Windows needs neither. Also switched to the two-element {"-include", "file"} form the rest of the index uses, rather than one string with an embedded space. VERIFIED Linux: tests/examples/freetype, msdfgen and harfbuzz all still pass (1 passed, 0 failed each) -- msdfgen and harfbuzz because they are freetype's consumers and a fix that only satisfies Windows would be no fix at all. Windows: the point of the change; this repo's windows workspace leg builds tests/examples/freetype, and it only rebuilds members a PR touches -- which is why the defect survived until a project outside this repo pulled freetype on MSVC. THE SAME DEFECT, NOT TOUCHED HERE Sweeping every descriptor for platform-specific flags in common cflags turns up four more, all with a windows xpm section, so all reachable on MSVC today: compat.lua -include mcpp_lua_platform_config.h compat.godot-cpp -include cstdlib compat.redis-plus-plus -include cstdint compat.eui-neo -include mcpp_eui_backends.h, -fno-char8_t Left alone deliberately: each needs its own judgement about what the MSVC equivalent should be (/FI, /Zc:char8_t-) or whether the flag is needed there at all, and I have no evidence about those packages on Windows the way I do for these two. Flagging rather than blind-editing. (The X11 packages also carry -D_GNU_SOURCE in common cflags. cl accepts -D and those packages are Linux-only, so it is untidy rather than broken.) --- pkgs/c/compat.freetype.lua | 14 +++++++++++--- pkgs/c/compat.zlib.lua | 12 +++++++++++- 2 files changed, 22 insertions(+), 4 deletions(-) diff --git a/pkgs/c/compat.freetype.lua b/pkgs/c/compat.freetype.lua index 5fc06cf7..a9063062 100644 --- a/pkgs/c/compat.freetype.lua +++ b/pkgs/c/compat.freetype.lua @@ -76,16 +76,24 @@ package = { }, targets = { ["freetype"] = { kind = "lib" } }, deps = { ["compat.libpng"] = "1.6.43" }, - cflags = { "-DFT2_BUILD_LIBRARY", "-DFT_DISABLE_ZLIB", "-DFT_DISABLE_BZIP2", "-DFT_DISABLE_HARFBUZZ", "-DFT_DISABLE_BROTLI", "-Wno-implicit-function-declaration", "-D_DARWIN_C_SOURCE" }, + -- Only the FT_* configuration defines are portable. `cl` accepts -D, so + -- these reach MSVC unchanged; a -W switch does not -- see below. + cflags = { "-DFT2_BUILD_LIBRARY", "-DFT_DISABLE_ZLIB", "-DFT_DISABLE_BZIP2", "-DFT_DISABLE_HARFBUZZ", "-DFT_DISABLE_BROTLI" }, linux = { ldflags = { "-lm" }, sources = { "*/builds/unix/ftsystem.c", "*/src/base/ftdebug.c" }, - cflags = { "-include", "fcntl.h" }, + -- -Wno-implicit-function-declaration is a GCC/Clang switch. It used + -- to sit in the common cflags, where MSVC rejected it outright with + -- `D8021: invalid numeric argument`, so the package could not build + -- on Windows at all. + cflags = { "-include", "fcntl.h", "-Wno-implicit-function-declaration" }, }, macosx = { ldflags = { "-lm" }, sources = { "*/builds/unix/ftsystem.c", "*/src/base/ftdebug.c" }, - cflags = { "-include", "fcntl.h" }, + -- _DARWIN_C_SOURCE belongs here and nowhere else; it was in the + -- common cflags, which put an Apple feature macro on every platform. + cflags = { "-include", "fcntl.h", "-Wno-implicit-function-declaration", "-D_DARWIN_C_SOURCE" }, }, windows = { sources = { diff --git a/pkgs/c/compat.zlib.lua b/pkgs/c/compat.zlib.lua index 548d2a20..6392b061 100644 --- a/pkgs/c/compat.zlib.lua +++ b/pkgs/c/compat.zlib.lua @@ -42,7 +42,17 @@ package = { import_std = false, c_standard = "c11", include_dirs = {"*", "mcpp_generated/include"}, - cflags = { "-D_GNU_SOURCE", "-include mcpp_zlib_config.h" }, + -- Both of these are GCC/Clang-only and used to be unconditional. + -- `-include` is the worse of the two on MSVC: cl does not reject it, it + -- warns (`D9002 ignoring unknown option`) and carries on, so the config + -- header was silently never included. The header only defines anything + -- when _WIN32 is absent, so Windows needs neither. + linux = { + cflags = { "-D_GNU_SOURCE", "-include", "mcpp_zlib_config.h" }, + }, + macosx = { + cflags = { "-include", "mcpp_zlib_config.h" }, + }, generated_files = { ["mcpp_generated/include/mcpp_zlib_config.h"] = "#ifndef MCPP_ZLIB_CONFIG_H\n#define MCPP_ZLIB_CONFIG_H\n#if !defined(_WIN32)\n#define Z_HAVE_UNISTD_H 1\n#endif\n#endif\n", },