Wrong link path for dependencies when using windows-*-static #1337
Comments
|
Thanks for the report and the trace logs. So, yes, there is a copy paste error in this line fluidsynth/cmake_admin/FindGLib2.cmake Line 38 in 231b690 which should be The problem of the build log you have linked is
However, all the cmake-related places I see in that log is where @pedrolcl might have a look, maybe I'm missing something. |
|
sets the relative path intl.lib, iconv.lib, pcre2-8.lib on GLib2::glib-2. It has an INTERFACE_LINK_DIRECTOREIS, but that's lost and only the INTERFACE_LINK_LIBRARIES are passed on in FluidSynthTargets.cmake
sets those libraries on FluidSynth::libfluidsynth-OBJ then links to FluidSynth::libfluidsynth as I read the trace. |
|
I'm not at all an expert either in cmake or your use case so take this with a grain of salt, but wouldn't it be possible to use IMPORTED_TARGET on the pkg_check_modules call and skip most of the hand coded extraction? |
That hand coded extraction in PkgConfigHelpers.cmake gives us control over the target name to use. I.e. if pkgconfig fails to discover that lib, we just create a target with the same name and populate it through the CMake I agree that FluidSynthTargets.cmake is the culprit. But it's autogenerated. I need to figure out how to convince cmake to populate the |
|
Can you pls. try the following: In FluidSynthTargets.cmake, locate the line and replace it by From my understanding of the docs, the |
|
That edit did not resolve the issue. |
|
I tried a couple other things that didn't help too; the gobject fix mentioned at the top; using target_link_libraries instead of target_set_properties, and setting interface_link_directories with the list of targets, even explicitly setting with: So far the only things that have worked are removing fluidsynth |
|
https://github.com/microsoft/vcpkg/blob/master/ports/qtbase/GLIB2-static.patch may be useful, or maybe a similar patch should be applied upstream by vcpkg. |
|
Please try
Please confirm that this fix correctly populates the Btw, where exactly in CorsixTH is libfluidsynth linked against? |
|
There were two lines that I had to change: originally is missing the G, as well as the line you mentioned. Changing both of those does fix that line in the cmake trace: For the second question, CorsixTH doesn't directly link fluidsynth but does so indirectly through sdl2_mixer. From our vcpkg.json In our CMakeList.txt we do: SDL2_mixer-static-targets.cmake has this line: |
Ok, thanks, I just committed a fix for this.
Ok, so the next step should be to figure out whether the error lies in fluidsynth logic or in the way how the dependencies are propagated via sdl2_mixer. To do this, I suggest you find_package(fluidsynth CONFIG REQUIRED)
find_package(SDL2_mixer CONFIG REQUIRED)i.e. discover fluidsynth via the cmake logic before discovering SDL2_mixer. This will create If it fails, it might be necessary to explicitly link against liblfuidsynth target_link_libraries(
CorsixTH
PRIVATE
$<IF:$<TARGET_EXISTS:SDL2_mixer::SDL2_mixer>,SDL2_mixer::SDL2_mixer,SDL2_mixer::SDL2_mixer-static,FluidSynth::libfluidsynth>)If that works, I'd say that the dependencies and their linker directories are correctly exposed by fluidsynth and the problem needs to be deferred to SDL2_mixer. |
@derselbst I've tried to reproduce the problem with this minimal project using SDL and SDL_mixer with Fluidsynth dependency. It can be linked statically with vcpkg dependencies without issues. Here are the installed vcpkg packages: I am too busy to debug other people buildsystems right now. |
|
@pedrolcl I can reproduce with your project. Checkout https://github.com/TheCycoONE/sdlmixtest/tree/repo (repo branch of my fork). I just added the vcpkg files and CMakePresets. The x64 version does not reproduce (CorsixTH also sometimes works on my local for x64, though never in the GitHub action pipeline - I haven't figured out the criteria but this is another data point) From the root of the repo run: cmake --preset win-x86-rel |
|
From the vcproj: So this is a slightly different variant where glib2 is fine, only pcre is impacted. Actually glib2 doesn't look exactly fine since it's mixing debug versions with release versions... |
|
On the x64-windows-static triplet I'm getting the same mixed debug/release issue but no missing library paths. |
|
I don't use the Visual Stupido Code or the siblings. I have installed only the MSVC 2019 command line build tools. As IDE, I use Qt Creator. I don't need a CMakePresets.json, the settings are provided by QtCreator.
In case of VCPKG, I install the libraries I need, for instance in this case for x86 static: Here is the output of CMake, when run from Qt Creator: Two relevant arguments (among others) are:
And finally the build process: No errors in this build. |
|
One point of clarification, the above does not use Visual Studio Code, it's just using vcpkg with the recommended CMake setup: https://learn.microsoft.com/en-us/vcpkg/get_started/get-started?pivots=shell-powershell |
FluidSynth version
2.3.5
Describe the bug
When building a program that statically links fluidsynth and and uses static linkage on windows with vcpkg the libraries added by FindGLib2 do not contain their absolute path, and linking may fail. e.g.:
D:/a/CorsixTH/CorsixTH/build/win-x64-rel/vcpkg_installed/x64-windows-static-release/share/fluidsynth/FindGLib2.cmake(219): set_target_properties(GLib2::gobject-2 PROPERTIES IMPORTED_LOCATION D:/a/CorsixTH/CorsixTH/build/win-x64-rel/vcpkg_installed/x64-windows-static-release/lib/gobject-2.0.lib INTERFACE_COMPILE_OPTIONS INTERFACE_INCLUDE_DIRECTORIES D:/a/CorsixTH/CorsixTH/build/win-x64-rel/vcpkg_installed/x64-windows-static-release/include/glib-2.0;D:/a/CorsixTH/CorsixTH/build/win-x64-rel/vcpkg_installed/x64-windows-static-release/lib/glib-2.0/include INTERFACE_LINK_LIBRARIES libffi;GLib2::glib-2 INTERFACE_LINK_DIRECTORIES )The same is true for the pcre dependency.
Expected behavior
I would expect all libraries found to have their absolute path so that they can be linked properly.
Additional context
A cmake run with tracing is logged here: https://github.com/CorsixTH/CorsixTH/actions/runs/9532652685/job/26274993008
Related vcpkg ticket: microsoft/vcpkg#36139
The text was updated successfully, but these errors were encountered: