It is not fully clear why this is being reverted after so long, that ticket seemed to be closed satisfactorily, no users report, then ticket re-opened?

I'm not reverting all the changes; I'm only removing the sys_root field, since I think it's causing more problems than solutions, as I show in the changelog. I decided to reopen the issue, as all the comments relate to the workaround proposed and not a complete solution. Also, there are some incoming PRs in Conan-Center-Index introducing that piece of code, so it's better to avoid that.

Meson passes the value of sys_root to pkg-config via PKG_CONFIG_SYSROOT_DIR -

That variable ONLY makes sense when .pc files and their corresponding libraries/include dirs are inside a sysroot. The ones provided by Conan are not (they are in individual folders inside the Conan Cache).

This causes a situation like this:

• we have a pkg-config executable
• PKG_CONFIG_PATH defined to the generators folder (the .pc files generated by Conan)
• PKG_CONFIG_SYSROOT_DIR to some sysroot, e.g. set to /foo/bar)

pkgconf -cflags glib-2.0 will return something like

-L/foo/bar/root/.conan2/p/b/glib23dfafab81222/p/lib -lglib-2.0 -lpthread -L/foo/bar/root/.conan2/p/b/pcre2ce305147fcaf7/p/lib -lpcre2-16 -lpcre2-32 -lpcre2-posix -lpcre2-8 -L/foo/bar/root/.conan2/p/b/zlib62234271c6987/p/lib -lz -L/foo/bar/root/.conan2/p/b/bzip2aed9574462cf2/p/lib -lbz2

These paths do not exist on the machine doing the build and it will fail for every dependency where a pc file does not exist inside the sysroot.

So this would point at this being broken since the beginning, that is, passing PKG_CONFIG_SYSROOT_DIR to point to the sysroot just breaks the ability to find dependencies provided by Conan.

Meson uses it here: https://github.com/mesonbuild/meson/blob/751b09390996163348612f0b106114256305ee40/mesonbuild/dependencies/pkgconfig.py#L269-L273

Unlike CMake, which does use the contents of CMAKE_SYSROOT for some things (including passing --sysroot to compiler/linker), Meson uses in very few places (the most notable one being something related to mingw).

I would argue that Meson probably shouldn't pass PKG_CONFIG_SYSROOT_DIR - because there's long-standing issues with both pkg-config and pkgconf (e.g. pkgconf/pkgconf#213), in particular the one we rely on (being able to find dependencies outside of the sysroot even if a sysroot exists), and because Meson examples themselves point to using pkg-config wrappers instead, like here (these wrappers already internally handle sysroot logic)
https://github.com/mesonbuild/meson/blob/751b09390996163348612f0b106114256305ee40/cross/ubuntu-armhf.txt#L10-L12

and they handle --sysroot as arbitrary flags, rather than a setting:
https://github.com/mesonbuild/meson/blob/751b09390996163348612f0b106114256305ee40/docs/markdown/Release-notes-for-0.55.0.md#L69-L89

@jcar87 I know I'm a bit late since this was just merged, but I actually just ran into this issue (where pkgconf cannot find any conan packages if you have a sysroot set in PKG_CONFIG_SYSROOT_DIR). I went down the rabbit hole of looking at pkg-config and pkgconf issues and digging through the source code to see where they had introduced a fix for it...

It turns out, they check if the .pc filename ends in "-uninstalled", and if so they do not prepend the sysroot directory.

So, my solution was to have conan output "mypackage-uninstalled.pc" instead of "mypackage.pc" and that actually worked perfectly. I don't think there are any downsides to this? As I understand it, the point of an "-uninstalled" pc file is to use non-standard directories, so all dirs are used verbatim. Sounds like exactly what conan should be doing, no?

I'm not entirely sure what removing the sys_root property here does. Will setting PKG_CONFIG_SYSROOT_DIR still work?

I've added some notes on the related ticket #16468 , but my main question is -

If you do this, how do we ensure that the host sysroot is prepended to paths returned by *.pc files inside the host sysroot? Or will *.pc files not explicitly generated by conan just not be a supported scenario at all?

It turns out, they check if the .pc filename ends in "-uninstalled", and if so they do not prepend the sysroot directory.

This is documented in the pkg-config man page -

--uninstalled
Normally if you request the package "foo" and the package "foo-uninstalled" exists, pkg-config will prefer the "-uninstalled" variant. This allows compilation/linking against uninstalled packages. If you specify the "--uninstalled" option, pkg-config will return successfully if any "-uninstalled" packages are being used, and return failure (false) otherwise. (The "PKG_CONFIG_DISABLE_UNINSTALLED" environment variable keeps pkg-config from implicitly choosing "-uninstalled" packages, so if that variable is set, they will only have been used if you pass a name like "foo-uninstalled" on the command line explicitly.)

Please consider submitting a PR to have conan generate all its *.pc files as -uninstalled packages. I think this would be a better solution than removing the sys_root property, which has its own problems.

If you do this, how do we ensure that the host sysroot is prepended to paths returned by *.pc files inside the host sysroot?

In the vast majority of cases where the dependencies are installed in "system" locations (/usr/include, /usr/lib) they **MUST NOT** be passed to the compiler or linker. that is, we must not have -I/path/to/sysroot/usr/include when you pass--sysroot` to the compiler (and the linker), it already does the rerouting for the fallback "system" directories - so there's no need.

pkg-config is typically configured to "remove" those paths when it encounters them.

if on native Linux you invoke pkg-config --cflags foobar and foobar is installed in /usr/include, then this command will return "emtpy", it means "no flags need to be added because the compiler is already looking there"

This is very important. It is very common (on Linux), to have things like openssl, zlib, xz-utils installed - even the development files (includes, link libraries, etc). When using those same libraries from Conan, you want them to come from Conan, not from the system. If you pass -I/usr/include, you run the risk of the compiler picking up the system one.

The same applies when cross compiling.
GCC and the tools in the toolchain (binutils) are "hardcoded" to look in some locations, you have two options:

• a cross-toolchain on a multilib system (like Debian) - the sysroot is implicitly / and the system supports having libraries for multiple architectures
• a cross-toolchain that has its own sysroot (relative to the toolchain), or expects --sysroot . The "system" paths will be auto-prefixed with the sysroot path

So when cross-building, you really want pkg-config --cflags foobar to STILL come back empty if the compiler is already looking there.

I think this would be a better solution than removing the sys_root property, which has its own problems.

I very much disagree. It would be more helpful if more details are provided: what problems are you expecting? Are there build logs we can look at, or reproducible examples?