mesonbuild
Meson fails to retrieve the "system" include folder with pkgconf on Windows
Describe the bug
pkgconf by default strips the "system" include folder when querying --cflags. For that, it needs either --keep-system-cflags or the environment PKG_CONFIG_ALLOW_SYSTEM_CFLAGS set.
This, for example, prevents linking harfbuzz against ICU under MSVC on Windows, when both libraries and pkgconf were built against the same prefix.
Meson already handles this, but for some reason only for the Fortran language:
https://github.com/mesonbuild/meson/blob/719dd0d2a04592812194e8588279827ec52fc92e/mesonbuild/dependencies/pkgconfig.py#L208-L213
To Reproduce
Build and install ICU from the Meson wrap, then try to build harfbuzz.
Flags I used were: -Dbuildtype=debugoptimized -Dprefix=E:/krita-win/msvc/i/ -Dlibdir=lib '--native-file E:/krita-win/msvc/b_deps/meson-compiler.ini'
meson-compiler.ini (adjust as needed, this was automatically generated from the corresponding CMake variables):
[binaries]
c = 'C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.34.31933/bin/Hostx64/x64/cl.exe'
cpp = 'C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.34.31933/bin/Hostx64/x64/cl.exe'
ar = 'C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.34.31933/bin/Hostx64/x64/lib.exe'
strip = ''
pkgconfig = 'E:/krita-win/msvc/i//bin/pkgconf'
[properties]
c_args = ['-guard:cf']
cpp_args = ['-guard:cf']
c_link_args = ['-GUARD:CF']
cpp_link_args = ['-GUARD:CF']
[built-in options]
pkg_config_path = 'E:/krita-win/msvc/i//share/pkgconfig,E:/krita-win/msvc/i//lib/pkgconfig'
You will see the following in meson-log.txt:
Pkg-config binary for 1 is cached.
Determining dependency 'icu-uc' with pkg-config executable 'E:/krita-win/msvc/i//bin/pkgconf'
env[PKG_CONFIG_PATH]: E:/krita-win/msvc/i/share/pkgconfig;E:/krita-win/msvc/i/lib/pkgconfig
Called `E:/krita-win/msvc/i//bin/pkgconf --modversion icu-uc` -> 0
72.1
env[PKG_CONFIG_PATH]: E:/krita-win/msvc/i/share/pkgconfig;E:/krita-win/msvc/i/lib/pkgconfig
Called `E:/krita-win/msvc/i//bin/pkgconf --cflags icu-uc` -> 0
env[PKG_CONFIG_ALLOW_SYSTEM_LIBS]: 1
env[PKG_CONFIG_PATH]: E:/krita-win/msvc/i/share/pkgconfig;E:/krita-win/msvc/i/lib/pkgconfig
Called `E:/krita-win/msvc/i//bin/pkgconf --libs icu-uc` -> 0
-LE:/krita-win/msvc/i/lib -licuuc
env[PKG_CONFIG_PATH]: E:/krita-win/msvc/i/share/pkgconfig;E:/krita-win/msvc/i/lib/pkgconfig
Called `E:/krita-win/msvc/i//bin/pkgconf --libs icu-uc` -> 0
-licuuc
This, and more extensive testing, is being done as part of our Krita development here.
Expected behavior
Building and linking should succeed out of the box.
system parameters
- Is this a cross build or just a plain native build (for the same computer)? Native build
- what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.) Windows 10 21H2
- what Python version are you using e.g. 3.8.0 3.10.7
- what
meson --version0.64.0 - what
ninja --versionif it's a Ninja build 1.10.2
cc: @eli-schwartz
Meson already handles this, but for some reason only for the Fortran language:
Well, to be fair the fortran check claims that fortran outright does not look in the system includedir.
It's interesting to note on the other hand that e.g. method: 'cmake' will tend to add -I/usr/include on my system, because cmake doesn't filter it out? and neither does Meson. But Meson will filter it out manually if you use -isystem or dependency('zlib', method: 'cmake', include_type: 'system').
The thing is that ultimately, the compiler's builtin includedir shouldn't need to be manually specified in build.ninja's compile args, so it's not clear why we need to add it anyway.
... unless, the compiler is not actually treating this directory as a default includedir. In which case, maybe that is really the fault of the pkgconf build itself.
...
Granted, this isn't perfect today, because as said above -- the cmake method messes with this.
Been following this issue because of our own MSYS2 woes, and think there's something that needs clarifying here:
While yes on Linux /usr/include is a system include path, it is not on MSYS2 for Windows reasons, and is instead treated as any other normal include path. /<abi>/include is a system path by comparison, because the setup under MSYS2 is much more complicated due to that ABI problem.
Furthermore, on both Linux and other OSes where pkgconf or pkg-config can be run, you are also limited by what it considers to be "system" folders. For instance, as seen above, it will strip its own installation prefix unless told not to (which requires access to a Bourne shell and Autotools to rebuild), and this will break the build unless the compiler was also installed in that prefix. MSVC in particular has no "system" folders, except those provided by the developer shell in the INCLUDE environment variable, so these folders must be listed explicitly.
It doesn't need clarifying.
I was attempting to gently lead people to the conclusion that they need to rebuild pkgconf.
/usr/include was only ever mentioned as an aside, and that aside was "using Eli Schwartz's system as an example content string [...]".
...
If you're using msys2 as a convenient source of a prebuilt pkgconf.exe but not using msys2's path setup, this is similar to the cross compiler case on Linux. And it has the same (very common) solution -- take a look at pkgconf's "personality" files, add a msvc.personality, and invoke pkgconf as either msvc-pkg-config or pkg-config --personality msvc.
If you're building your own pkgconf, then:
- it is a bug that its meson.build doesn't support the same options as configure.ac, maybe submit a bug report or a PR to pkgconf?
- personality files still work, although it's a bit meh to have to specify a personality in order to get the default behavior.
I was attempting to gently lead people to the conclusion that they need to rebuild pkgconf.
From a quick look at the official repo, it's unclear how to achieve what you say. In other words-- what configuration does pkgconf require for the reported use case?