Gvsbuild produces *.pc files with wrong path format

[Febbe]

I have several issues with the build binaries and their pkg-config-files (in CMake): First, the shipped pkg-config produces broken paths (for CMake), somehow it tries to interpret the backslashes as escape character, resulting in paths like C:gtk-buildgtkx64release\ instead of: C:\gtk-build\gtk\x64\release\ switching to the msys2/mingw64 provided binary fixed that. This seems to be actually a problem with gvsbuild (could be that the pkg-config.exe is not meant to be used by the user).

Then, when using the msys pkg-config, I get cflags, which can't be interpreted by msvc, also *.dll files are found for the libs instead of *.lib files.

Having the following find module for cmake:

FindGTK.cmake // modified by me, original is from poppler

include(FindPackageHandleStandardArgs)

find_package(PkgConfig REQUIRED)

pkg_check_modules(GTK3_internal IMPORTED_TARGET "gtk+-3.0>=${GTK_REQUIRED}" "gdk-pixbuf-2.0>=${GDK_PIXBUF_REQUIRED}")

add_library(_find_gtk3_internal INTERFACE)
target_link_libraries(_find_gtk3_internal INTERFACE PkgConfig::GTK3_internal)
target_link_directories(_find_gtk3_internal INTERFACE ${GTK3_LIBRARY_DIRS})

add_library(PkgConfig::GTK3 ALIAS _find_gtk3_internal)

message(STATUS "GTK3_internal_FOUND: ${GTK3_internal_FOUND}")
message(STATUS "GTK3_internal_LINK_LIBRARIES: ${GTK3_internal_LINK_LIBRARIES}")
message(STATUS "GTK3_internal_LIBRARIES = ${GTK3_internal_LIBRARIES}")
message(STATUS "GTK3_internal_CFLAGS = ${GTK3_internal_CFLAGS}")
message(STATUS "GTK3_internal_LIBRARY_DIRS = ${GTK3_internal_LIBRARY_DIRS}")
message(STATUS "GTK3_internal_LDFLAGS = ${GTK3_internal_LDFLAGS}")

set(GTK3_FOUND ${GTK3_internal_FOUND})
set(GTK3_CFLAGS ${GTK3_internal_CFLAGS})
set(GTK3_LINK_LIBRARIES ${GTK3_internal_LINK_LIBRARIES})

find_package_handle_standard_args(GTK DEFAULT_MSG GTK3_FOUND GTK3_LINK_LIBRARIES GTK3_CFLAGS)

results in:

[cmake] -- GTK3_internal_FOUND: 1
[cmake] -- GTK3_internal_LINK_LIBRARIES: gtk-3;gdk-3;C:/Windows/System32/gdi32.dll;C:/Windows/System32/imm32.dll;C:/Windows/System32/shell32.dll;C:/Windows/System32/ole32.dll;C:/Windows/System32/winmm.dll;C:/Windows/System32/dwmapi.dll;C:/Windows/System32/setupapi.dll;C:/Windows/System32/cfgmgr32.dll;C:/Windows/System32/hid.dll;winspool;C:/Windows/System32/comctl32.dll;C:/Windows/System32/comdlg32.dll;pangowin32-1.0;pangocairo-1.0;pango-1.0;P:/vcpkg/installed/x64-windows/debug/Bin/harfbuzz.dll;atk-1.0;cairo-gobject;cairo;gio-2.0;gdk_pixbuf-2.0;gobject-2.0;glib-2.0;intl
[cmake] -- GTK3_internal_LIBRARIES = gtk-3;gdk-3;gdi32;imm32;shell32;ole32;winmm;dwmapi;setupapi;cfgmgr32;hid;winspool;comctl32;comdlg32;pangowin32-1.0;pangocairo-1.0;pango-1.0;harfbuzz;atk-1.0;cairo-gobject;cairo;gio-2.0;gdk_pixbuf-2.0;gobject-2.0;glib-2.0;intl
[cmake] -- GTK3_internal_CFLAGS = -IC:/gtk-build/gtk/x64/release/include/gtk-3.0;-IC:/gtk-build/gtk/x64/release/include/pango-1.0;-IC:/gtk-build/gtk/x64/release/include;-IC:/gtk-build/gtk/x64/release/include/glib-2.0;-IC:/gtk-build/gtk/x64/release/lib/glib-2.0/include;-IC:/gtk-build/gtk/x64/release/include/harfbuzz;-IC:/gtk-build/gtk/x64/release/include/fribidi;-IC:/gtk-build/gtk/x64/release/include/freetype2;-IC:/gtk-build/gtk/x64/release/include/libpng16;-IC:/gtk-build/gtk/x64/release/include/cairo;-IC:/gtk-build/gtk/x64/release/include/gdk-pixbuf-2.0;-IC:/gtk-build/gtk/x64/release/include/atk-1.0
[cmake] -- GTK3_internal_LIBRARY_DIRS = C:/gtk-build/gtk/x64/release/lib
[cmake] -- GTK3_internal_LDFLAGS = -LC:/gtk-build/gtk/x64/release/lib;-lgtk-3;-lgdk-3;-lgdi32;-limm32;-lshell32;-lole32;-lwinmm;-ldwmapi;-lsetupapi;-lcfgmgr32;-lhid;-lwinspool;-lcomctl32;-lcomdlg32;-lpangowin32-1.0;-lpangocairo-1.0;-lpango-1.0;-lharfbuzz;-latk-1.0;-lcairo-gobject;-lcairo;-lgio-2.0;-lgdk_pixbuf-2.0;-lgobject-2.0;-lglib-2.0;-lintl

As you can see, the GTK3_internal_LDFLAGS are completely useless for msvc, the LC parameter can't be used for the msvc-link.exe therefore the path is not searched, and the libs can't be found. The GTK3_internal_LINK_LIBRARIES is also useless, since it contains *.dll's which is bad, since in windows you don't link against dlls ever.

==

It would be nice, if you can help me find the real cause of this mess.

[danyeaw]

Hi @Febbe, thanks for the bug report. What are you trying to use gvsbuild for? Are you trying to build other libraries with cmake outside of gvsbuild?

We do use pkg-config for building libraries, and it is possible that there are issues with it that we should try to get fixed upstream. Do you have a minimum reproducible example?

[Febbe]

What are you trying to use gvsbuild for? Generally, I want to finally build https://github.com/xournalpp/xournalpp with msvc.

In this case, I tried to compile a dependency of xpp: poppler, which failed.

Are you trying to build other libraries with cmake outside of gvsbuild?

Yes, that's what I try. Since the libraries build via gvsbuild seem to be compatible to msvc, I tried to just link them via pkg-config.

My example:

1. Had clang-14, ninja, cmake, msvc, and MSYS2+mingw-64(gcc, pkg-config) in the path
2. Build gtk via gvsbuild
3. added gtk, including the pkg-config along with it to the path, but above MSYS2
4. tried to compile poppler via cmake

=> First problem with the paths

1. Had clang-14, ninja, cmake, msvc, and MSYS2+mingw-64(gcc, pkg-config) in the path
2. Build gtk via gvsbuild
3. added gtk, including the pkg-config along with it to the path, but below MSYS2
4. weird dll's in the linker path, gtk/gdk/... could not be found.

[danyeaw]

In this case, I tried to compile a dependency of xpp: poppler, which failed.

With gvsbuild or separately?

In general, gvsbuild is for building libraries with gvsbuild. If you create an environment that mixes a lot of tools that gvsbuild also provides, and mix gvsbuild with mingw-64, you are going to have issues. If you want to build poppler, then build it with gvsbuild. If you don't want to use gvsbuild for that, then I recommend removing it off your path.

[Febbe]

Separately, But with gvsbuild first, vcpkg second and mingw third in the path. I also made sure, that no lib is found in a mingw subdir (I know that those libs are incompatible).

I am new to gvsbuild. Furthermore, I just wanted to use the binaries, build by gvsbuild. So actually, I don't know how to build external (git) libraries directly with gvsbuild. I only have mingw64 in the path, because we build xournalpp with it currently. Also, I would lose the "working" pkg-config.

--

~~I debugged it further and now think that the pkg-config is not buggy, it's more like cmake which has issues with interpreting \. I modified the CMake module and it turns out that the path is returned correctly by pkg-config:~~ No, pkg-config uses \ to escape spaces, so using \ as path separator can't work. But using \ should be fine tho.

[cmake] -- Invoking pkg-config for glib-2.0;gobject-2.0;gio-2.0 with prefix GLIB2 and varname LIBRARY_DIRS and regexp (^| )-L
[cmake] -- _pkgconfig_invoke_result: -LC:/gtk-build/gtk/x64/release/lib -LC:\gtk-build\gtk\x64\release/lib -LC:\gtk-build\gtk\x64\release/lib -LC:/gtk-build/gtk/x64/release/lib -LC:/gtk-build/gtk/x64/release/lib

results in

[cmake] -- _pkgconfig_invoke_result: -LC:/gtk-build/gtk/x64/release/lib -LC:gtk-buildgtkx64release/lib -LC:gtk-buildgtkx64release/lib -LC:/gtk-build/gtk/x64/release/lib -LC:/gtk-build/gtk/x64/release/lib

~~I believe it's a bug in string(REGEX REPLACE)~~ No, see: https://github.com/wingtk/gvsbuild/issues/606#issuecomment-1164080058

How you can fix this:

One lib seem to export an .pc file containing a path with backslashes. This should not be a problem tho, but it will be a workaround to export those consequently with forward slashes.

The files are: libffi.pc, gtk+-3.0.pc, gtk+-win32-3.0.pc, gdk+-win32-3.0.pc, gdk+-3.0.pc, expat.pc

The ddl issue also seems to be a cmake bug, but I did not examine the cause of it.

[Febbe]

It's not an cmake bug in this case: https://gitlab.kitware.com/cmake/cmake/-/issues/23641 It's more like, that pkg-config does not sanitize paths. They also officially don't use a specific output format (UNIX or WINDOWS or PLATFORM_DEPENDENT)

So you have to fix this by replacing all \ with / in the paths.

[mikekaganski]

Note also, that e.g. cairo.pc (built using gsvbuild) has corerect forward slashes, but wrong prefix path (it has an extra /bin appended).

So to be useful, the lib/pkgconfig needs manual post-processing :(

[nacho]

the path in the pc files does not matter for windows. pkgconfig will override it anyway

[mikekaganski]

It does. I use it under cygwin (LibreOffice toolchain), and its pkgconfig creates wrong include/library paths. If it might not matter in some circumstances isn't a reason to keep it wrong :)

[Febbe]

the path in the pc files does not matter for windows. pkgconfig will override it anyway

The path indeed matters, using a pkg-config, for example build via msvc + msvcrt and not msys2 + mingw_X, paths are not normalized to unix style.