Library is built with PipeWire support when targeting Windows using MinGW-w64 on Linux

[williamjcm]

I am working on a game engine project, targeting both Linux and Windows. Since I use Linux as my daily driver, I have the Linux version of MinGW-w64 installed on my machine.

I vendored all of the dependencies I could, including OpenAL Soft, using CMake's FetchContent module to make it easier to manage them and build them as part of the engine's own build process.

CMake's output when generating the build files contains the following:

-- Checking for module 'libpipewire-0.3>=0.3.23'
--   Found libpipewire-0.3, version 1.2.7

...

-- Building OpenAL with support for the following backends:
--     PipeWire, WinMM, DirectSound, WASAPI, WaveFile, Null

Trying to build the project obviously leads to OpenAL Soft failing to compile because MinGW-w64 can't find the PipeWire header files.

From what I can see in the CMakeLists, the PipeWire backend isn't properly gated behind a if(NOT WIN32) or similar branch.

[kcat]

From what I can see in the CMakeLists, the PipeWire backend isn't properly gated behind a if(NOT WIN32) or similar branch.

Because audio backends are assumed OS-agnostic unless necessary. For instance, JACK is typically considered as being for Linux, but it's certainly possible to use it on Windows (and some people do). PulseAudio can also be used on Windows, so there's no real reason to restrict PipeWire from being used on Windows either. Except for those that rely on OS-specific APIs, or there's no reliable way to check for them, many backends are left cross-platform in case someone has a need for one (and since most backends are loaded dynamically, having them enabled won't create a dependency issue should such builds be distributed).

The issue here is more general, that pkg-config finds native packages instead of the package files installed for the cross-compiler, so cmake thinks any native package searched for using pkg-config exists for the cross-compiler. It's more than just PipeWire that would be affected by this, some other cmake scripts may use pkg-config to find other packages and would erroneously succeed.

How do you cross-compile? The provided XCompile.txt includes the lines:

# set env vars so that pkg-config will look in the appropriate directory for
# .pc files (as there seems to be no way to force using ${HOST}-pkg-config)
set(ENV{PKG_CONFIG_LIBDIR} "${CMAKE_INSTALL_PREFIX}/lib/pkgconfig")
set(ENV{PKG_CONFIG_PATH} "")

This works for me to suppress pkg-config from finding native packages/libraries and finds only those installed for the cross-compiler. If you're using your own cross-compile toolchain file, it may be helpful to add lines like that to it.

[williamjcm]

Because audio backends are assumed OS-agnostic unless necessary. For instance, JACK is typically considered as being for Linux, but it's certainly possible to use it on Windows (and some people do). PulseAudio can also be used on Windows, so there's no real reason to restrict PipeWire from being used on Windows either.

Makes sense. Pulse and JACK even have Windows-native packages in MSYS2's repos. Though PW doesn't have one (yet?).

The issue here is more general, that pkg-config finds native packages instead of the package files installed for the cross-compiler, so cmake thinks any native package searched for using pkg-config exists for the cross-compiler. It's more than just PipeWire that would be affected by this, some other cmake scripts may use pkg-config to find other packages and would erroneously succeed.

How do you cross-compile?

I set CMAKE_TOOLCHAIN_FILE with a slightly modified version of this file (I use a different MinGW-w64 build installed in my home directory, because Arch's one targets MSVCRT instead of UCRT): https://github.com/mosra/toolchains/blob/master/archlinux/basic-mingw-w64-64.cmake

I would hope CMake does the right thing and feeds pkg-config the correct paths, but I guess that might not be the case.