<div dir="ltr">On 29 May 2017 at 15:20, Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> wrote: > > On 26 May 2017 at 14:55, Jussi Kukkonen <<a href="mailto:jussi.kukkonen@intel.com">jussi.kukkonen@intel.com</a>> wrote: > > On 26 May 2017 at 14:32, Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> wrote: > >> > >> On 26 May 2017 at 08:52, Jussi Kukkonen <<a href="mailto:jussi.kukkonen@intel.com">jussi.kukkonen@intel.com</a>> wrote: > >> > > >> > > >> > On 24 May 2017 at 16:39, Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> wrote: > >> AFAICT there are a couple of alternative solutions - have you > >> considered/tried any of them? > >> > >> a) w/o a wrapper script > >> $ export PKG_CONFIG_PATH= // you need this if using the system > >> pkgo-config. if the local/native one is used, this should be optional > >> $ export > >> PKG_CONFIG_LIBDIR=$path_to_non_system_host_pkgconfig:${SYSROOT}/usr/{lib,share}/pkgconfig > >> $ export PKG_CONFIG_SYSROOT_DIR=${SYSROOT} > > > > We're using a natively built pkg-config which sets all the pkg-config > > variables to what I believe are the correct values: the problem is that none > > of those variable is for the _native_ sysroot location so they don't help in > > this case. There is now way to say in a .pc file that this path should be > > prefixed with something like "${pc_native_sysroot_dir}" if it's defined. > > > >> b) with a wrapper script - see [1]. > >> I think that the "export PKG_CONFIG_DIR=" is a typo (should be ..PATH > >> instead) and is not strictly required - feel free to check either way. > >> Note that the exec at the end might need to be amended to > >> /path/to/$(CHOST)-pkg-config. > > > > We don't provide a target wrapper -- I believe because it provides no value > > at all on top of the setup we have (the pkg-config that autotools finds has > > all the environment variables set correctly. It is essentially > > $(CHOST)-pkg-config already). > > > > If I've missed something, I'd be happy to hear that. At the moment I think > > pkg-config just does not help in this case. > > > I'm confused a bit - did you try the above suggestions? If so can you > share which one and how it fails? I'm sorry but I do not see what I could test that could help: I mentioned that the pkg-config that gets used by PKG_CHECK_MODULES() is essentially a wrapped one: In more detail the build tool sets these variables: export PKG_CONFIG_DIR = "${STAGING_DIR_HOST}${libdir}/pkgconfig" export PKG_CONFIG_PATH = "${PKG_CONFIG_DIR}:${STAGING_DATADIR}/pkgconfig" export PKG_CONFIG_LIBDIR = "${PKG_CONFIG_DIR}" export PKG_CONFIG_SYSROOT_DIR = "${STAGING_DIR_HOST}" export PKG_CONFIG_DISABLE_UNINSTALLED = "yes" export PKG_CONFIG_SYSTEM_LIBRARY_PATH = "${base_libdir}:${libdir}" export PKG_CONFIG_SYSTEM_INCLUDE_PATH = "${includedir}" When we're building target software STAGING_DIR_HOST is the target sysroot. This setup works fine for everything except the case where pkg-config is used to locate tools that need to be run during the build (like wayland_scanner variable): we wouldn't want to use tools from the target sysroot. When e.g. target mesa is being built a native sysroot already exists and it contains a wayland-scanner we should run. but there is no way to tell pkg-config a) native sysroot path (via a env variable) b) that variable wayland_scanner specifically should be prefixed with native sysroot if present (similar to ${pc_sysrootdir} but for native sysroot)<div> </div><div>Jussi</div></div>