The downstream libmikmod is now failing to install due to the following issue:
libmikmod:x64-windows-static
libmikmod:x64-windows-static-md

OpenAL32.lib(wasapi.cpp.obj) : error LNK2019: unresolved external symbol __imp_AvSetMmThreadCharacteristicsW referenced in function "public: int __cdecl `anonymous namespace'::WasapiPlayback::mixerProc(void)" (?mixerProc@WasapiPlayback@?A0x0844112c@@QEAAHXZ)
OpenAL32.lib(wasapi.cpp.obj) : error LNK2019: unresolved external symbol __imp_AvRevertMmThreadCharacteristics referenced in function "public: void __cdecl `anonymous namespace'::AvrtHandleCloser::operator()(void *)" (??RAvrtHandleCloser@?A0x0844112c@@QEAAXPEAX@Z)
mikmod.dll : fatal error LNK1120: 2 unresolved externals

The downstream sfml is now failing to install due to the following issue:
sfml:x64-osx
sfml:arm64-osx

/Users/vcpkg/Data/installed/x64-osx/include/AL/al.h:478:53: error: expected function body after function declarator
AL_API void AL_APIENTRY alEnable(ALenum capability) AL_API_NOEXCEPT;

More logs you could get from https://dev.azure.com/vcpkg/public/_build/results?buildId=109407&view=artifacts&pathAsName=false&type=publishedArtifacts

Thanks Cheney!

The windows-static ones seem to be due to openal-soft's WASAPI backend now requiring linking against avrt, and that dependency doesn't get communicated properly in static builds. Patching libmikmod would probably fix it, but that doesn't seem like the ideal approach.

I'm not sure what's causing the issues on macOS, since sfml also has code that uses noexcept and that's not causing issues 😕

The windows-static ones seem to be due to openal-soft's WASAPI backend now requiring linking against avrt, and that dependency doesn't get communicated properly in static builds. Patching libmikmod would probably fix it, but that doesn't seem like the ideal approach.

Add the missing link libs to the installed pc files (openal.pc). Ask if you need more information.

I'm not sure what's causing the issues on macOS, since sfml also has code that uses noexcept and that's not causing issues 😕

That's why I usually add the command line when reporting errors. Look:

/Library/Developer/CommandLineTools/usr/bin/c   -DAL_LIBTYPE_STATIC -DFLAC__NO_DLL -DOV_EXCLUDE_STATIC_CALLBACKS -DSFML_STATIC -I/Users/vcpkg/Data/b/sfml/src/2.6.2-8c34997038.clean/include -I/Users/vcpkg/Data/b/sfml/src/2.6.2-8c34997038.clean/src -isystem /Users/vcpkg/Data/b/sfml/src/2.6.2-8c34997038.clean/extlibs/headers/minimp3 -isystem /Users/vcpkg/Data/installed/x64-osx/include -isystem /Users/vcpkg/Data/installed/x64-osx/include/AL -fPIC -g -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk -mmacosx-version-min=13.0 -fvisibility=hidden  -Wall -Wextra -Wshadow -Wnon-virtual-dtor -Wcast-align -Wunused -Woverloaded-virtual -Wconversion -Wsign-conversion -Wdouble-promotion -Wformat=2 -Wnull-dereference -Wold-style-cast -Wpedantic -Wno-unknown-warning-option -MD -MT src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundBuffer.cpp.o -MF src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundBuffer.cpp.o.d -o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundBuffer.cpp.o -c /Users/vcpkg/Data/b/sfml/src/2.6.2-8c34997038.clean/src/SFML/Audio/SoundBuffer.cpp

The line lacks the desired C standard option. And so you don't even get C 11. And so you don't get noexcept.

The noexcept C 11 issue has been fixed (and merged upstream), but I'm a bit stuck on the Windows static build issue with avrt.lib.

The openal.pc pkg-config file seems to be correct and includes -lavrt.
The OpenAL-Target.cmake file also seems to be correct and includes \$<LINK_ONLY:avrt>.

However, I'm not convinced that the CMake build for libmikmod is actually reading those CMake target files in the share/openal-soft directory. I tried making changes there (including introducing invalid names for testing) and there was never any change in behaviour to libmikmod.

It feels to me like CMake's built-in FindOpenAL is being used and it's finding the lib path but not picking up any of the additional target configuration that the OpenAL-Soft CMake target files are providing.

It feels to me like CMake's built-in FindOpenAL is being used and it's finding the lib path but not picking up any of the additional target configuration that the OpenAL-Soft CMake target files are providing.

libmikmod does use CMake's built-in FindOpenAL, and in a bad way: It uses include(FindOpenAL).

• The Find module doesn't get the full set of input variables which CMake's find_package would provide.
• The call isn't routed through vcpkg's overload of find_package which would enable loading of a wrapper to hide find module quirks.

This module is a bad example. It only uses ${OPENAL_LIBRARY}, i.e. the singular word which is usually meant to be used as an input variable, but not to handle transitive usage requirements.

So IMO there are two task:

• Patch libmikmod to use CMake config, or at least to use Find mode correctly.
• Add a wrapper for openal to make find_package(OpenAL) produce a complete list in OPENAL_LIBRARY. (libmikmod could be the test case.)

Usage test passed with x64-windows-static triplet.

Thanks for the update!