Repository: mesonbuild/meson

Issue:
No docs on handling sysroot for pkg-config in cross-builds?
Hi,

1. First, my impression is that the recommended way to make pkg-config work when cross-compiling is to set PKG_CONFIG_PATH and PKG_CONFIG_SYSROOT_DIR.  Is this accurate?

2. Second, assuming that #1 is at least partially accurate, can we say something about this in the help for doing cross-compilation?  I ask because I spent about 5 hours figuring this approach out while doing a cross-compile from linux to windows using gtk2 libs from `repo.msys2.org`.

   There's nothing about sysroots in here: http://mesonbuild.com/Cross-compilation.html

   It also looks like setting the sys_root property is (maybe) deprecated and (maybe) doesn't do anything?  Maybe this should also be mentioned in the docs.  if @nirbheek or @jpakkane can give my an overview I can make a PR with some attempted docs.

3. Third, it looks like there is no way to set the PKG_CONFIG_PATH and PKG_CONFIG_SYSROOT variables in the cross file.  is this intentional?

My apologies if I'm just overlooking some documentation.  Meson is pretty nice overall to use for cross-building.

-BenRI


Discussion:
See #3801 #3802 #3803 
Maybe #1849
The sysroot property has never really been used for anything. It's just there in the cross file so you can access it from `meson.build` if it is necessary (which is rare).

The "correct" way to do this is to have a pkgconfig binary in the cross file that points to the pkg-config executable for that host platform. Usually this is shipped with the toolchain but if not, then you can write a wrapper script that sets the necessary envvars and calls the system's pkg-config.
Sure, Debian ships a  `/usr/bin/x86_64-w64-mingw32-pkg-config` for cross-builds from linux to windows.  This doesn't solve the problem though, since the windows libraries themselves are not in some standard system location, but normally in a users home dir.  Debian ships a lot of other cross-compilers, and I'm guessing the same problem exists for all of them.

In practice this means that on Debian, meson works fine for cross building with only a cross file -- until you want to use libraries from the host platform.

If we added a short section on pkg-config to http://mesonbuild.com/Cross-compilation.html it might lower the barrier to entry in cases where the user needs to create a wrapper.  We could, for example, include a link to https://autotools.io/pkgconfig/cross-compiling.html, which has an example of such a wrapper script.  That would have saved me a lot of time.

Interestingly, the example of a cross-file in /usr/bin/i586-mingw32msvc-pkg-config has
```
pkgconfig = '/usr/bin/i586-mingw32msvc-pkg-config'
```
This is basically what I was doing -- it doesn't work.  It reports _native_ libraries as being installed, although perhaps only the native libs that are header-only.

An update to the cross-compile docs could fix that also, I suppose.
In this example `i586-mingw32msvc-pkg-config` is supposed to point to the wrapper script. This does work fine for me.
Note that this only affects dependencies found with pkgconfig, not any other dependency type, not find_library either. Another gotcha is that when the wrapper script is not found, meson will behave quite weird and not give a clear warning what happened, currently.
This problem has plagued me for a while too, and in the meantime I resorted to hardcoded path hacks.

I'm cross-compiling with Yocto, and the solution is to use a wrapper script.
I had built a separate SDK package (populatesdk option in Yocto) and installed that on the local machine, and was pointing the Meson c, cpp, ar, strip, pkgconfig cross compiler paths to that. pkgconfig was finding nothing, ever.
I ran the installed cross-platform pkgconfig --list-all, and it had nothing. That's why. The Yocto-built pkg-config binary did not even work out of the box.

Write a wrapper script using this template, and it works:
https://autotools.io/pkgconfig/cross-compiling.html

I agree this problem is needing some documentation, because it is frustrating for the user, and this may be the first reason for them to attempt to run a broken pkg-config binary.
I have the same problem, but compiling from within msys2/mingw. Meson's way to run commands in Windows do not allow it to call scripts, and it ignores all environment variables passed to meson (they are not passed to its child processes).

So, I have no idea how to call pkg-config correctly for mingw.

Resolving patch:
diff --git a/mesonbuild/dependencies/base.py b/mesonbuild/dependencies/base.py
--- a/mesonbuild/dependencies/base.py
+++ b/mesonbuild/dependencies/base.py
@@ -655,9 +655,13 @@ def _call_pkgbin(self, args, env=None):
             env = env.copy()
 
         extra_paths = self.env.coredata.builtins_per_machine[self.for_machine]['pkg_config_path'].value
+        sysroot = self.env.properties[self.for_machine].get_sys_root()
+        if sysroot:
+            env['PKG_CONFIG_SYSROOT_DIR'] = sysroot
         new_pkg_config_path = ':'.join([p for p in extra_paths])
         mlog.debug('PKG_CONFIG_PATH: ' + new_pkg_config_path)
         env['PKG_CONFIG_PATH'] = new_pkg_config_path
+
         fenv = frozenset(env.items())
         targs = tuple(args)
         cache = PkgConfigDependency.pkgbin_cache


Test patch: