fix(liquid-dsp): guard -lc/-lm link flags against WIN32 platforms

[NF0T]

Problem

target_link_libraries(${target} c m) at line 468 of
third_party/liquid-dsp/CMakeLists.txt is a POSIX/Linux convention.
On Windows the C runtime is linked automatically by both MinGW-w64 and
MSVC — passing -lc/-lm explicitly causes MinGW ld to fail at
link time:

cannot find -lc: No such file or directory

This regression was introduced when liquid-dsp was vendored in #3046.

Fix

Wrap the target_link_libraries call in if(NOT WIN32) … endif().
WIN32 is true for both MinGW-w64 and MSVC on Windows (it is a
platform variable, not a compiler variable), so this correctly suppresses
the flag for all Windows toolchains while leaving Linux and macOS
behaviour unchanged.

This is a stopgap that restores a clean Windows build. The full
Windows/MSVC solution (ExternalProject with mingw-w64) is tracked
in #3049.

Testing

• Built cleanly on Windows 11 with MinGW GCC 13.1.0 / Qt 6.11.0 /
  Ninja — no linker errors.
• Linux and macOS paths are unchanged; the guard only fires on WIN32.

Related: #3049

🤖 Generated with Claude Code

[aethersdr-agent]

Thanks for the fix, @NF0T — clean, surgical, and the rationale in the inline comment + PR body is exactly what a future reader needs.

A couple of confirming notes:

• WIN32 is the right gate. It's set by CMake based on the target platform regardless of the toolchain, so both MinGW-w64 and MSVC are covered. No need to also test MSVC / MINGW.
• The line target_link_libraries(${target} c m) at third_party/liquid-dsp/CMakeLists.txt:468 is upstream liquid-dsp's POSIX assumption — leaving Linux/macOS untouched preserves upstream behavior, and the guard is the standard idiomatic fix used by other CMake-based ports of liquid-dsp.
• Scope is appropriately tight: a single vendored-CMakeLists patch. Cleanly labelled as a stopgap until the proper Windows path lands via #3049.

One minor optional suggestion (non-blocking — feel free to ignore): since the if (fftw3f_FOUND) target_link_libraries(${target} fftw3f) block immediately below is unaffected on Windows, the current placement is fine. If you ever wanted to fold the guard, target_link_libraries(${target} $<$<NOT:$<BOOL:${WIN32}>>:c> $<$<NOT:$<BOOL:${WIN32}>>:m>) would work but is strictly less readable than what you have. The explicit if(NOT WIN32) block is the better choice here.

LGTM.

---

_{🤖 aethersdr-agent · cost: $3.9241 · model: claude-opus-4-7}