The design of the currentpkg-config application and the interface ofPKG_PROG_PKG_CONFIG allows them to be instrumental in proper cross-compilation of software, when used correctly. This only requires following a few simple rules.
When cross-compiling packages with multiple dependencies or entire operating system images, the focus is usually around one specific directory, calledsysroot, used as prefix while mimicking the installation layout of a normal running system. This path needs to be prefixed to the paths added to the list of searched paths for headers and libraries, i.e., those that are passed to-I/-L, respectively to the compiler and link editor. At the same time, it should not be compiled in programs to refer to at runtime, nor it should be used as the destination path during installation.
Sincepkg-config original, and main, task is to report flags and paths, it is crucial that the sysroot handling is taken into consideration. At the time of writing, with version 0.25 ofpkgconfig package, this is achieved mainly through thePKG_CONFIG_SYSROOT_DIR variable, which is set to the path of the sysroot, and is inserted in-between the-I or-L flags and the following path.
The content ofPKG_CONFIG_SYSROOT_DIR is not injected in paths that are returned bypkg-config --variable, which makes them unsuitable to use during cross-compilation unless specifically designed to be used at that time.
To design a variable to contain a path that needs to be used at build time, such as the path where a generation script is, you can prefix it in the.pc file with the built-in variable${pc_sysrootdir}.
Often, during cross-compilation, builds are mixed of tools to use on the host, and libraries to install on the target, making it unfeasible to simply setPKG_CONFIG_SYSROOT_DIR during the build. To cope with this, the usual method to set the variable is to use a wrapper script, with either a custom a general${CHOST}-pkg-config name.
This is supported by theautoconf macros provided by the package, as they all respect$PKG_CONFIG if set in the environment, and look for a target tool (${CHOST}-pkg-config) before falling back to the usualpkg-config command.
When using the tool to identify variables within aconfigure.ac orMakefile.am file, it is thus important to not call it directly, but to rather call$PKG_CONFIG so to not bypass sysroot awareness.
It also requires other build systems to respect the value set into the environment, the code for which depends on a system by system basis.
The wrapper script should not only set thePKG_CONFIG_SYSROOT_DIR variable: when cross-compiling you want to ignore the packages installed in the system, and instead rely only on those installed in the cross-compiled environment. This is achieved by resettingPKG_CONFIG_PATH (which lists additional search paths), and at the same time settingPKG_CONFIG_LIBDIR to override the default base search paths.
As ofpkg-config version 0.28, a tool-prefixed executable, with the same name as the wrapper documented in this section, is installed by default, both when cross compiling and when not, to support multiple ABI on the same system. This does not, though, make the wrapper approach obsolete, yet.
Example 4.4. Commonpkg-config wrapper script for cross-compilation
#!/bin/shSYSROOT=/build/rootexport PKG_CONFIG_PATH=export PKG_CONFIG_LIBDIR=${SYSROOT}/usr/lib/pkgconfig:${SYSROOT}/usr/share/pkgconfigexport PKG_CONFIG_SYSROOT_DIR=${SYSROOT}exec pkg-config "$@"Autotools Mythbuster byDiego Elio Pettenò.
Licensed under aCreative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Based on a work atautotools.info.