Package: dpkg-dev Version: 1.15.4 Severity: normal User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu karmic
The PKG_CONFIG_LIBDIR override introduced for cross-compilation purposes due to #439979 (so courtesy-copying Neil as the reporter of that bug, although ISTR he's trying to reduce his involvement with Emdebian at the moment) has a somewhat awkward consequence. I'm not sure I have a good solution for this right now, but would like to have a bug open for discussion. It's true that setting PKG_CONFIG_LIBDIR when cross-compiling makes it a lot easier to build the majority of packages that use pkg-config in simple ways. You ask pkg-config for libraries, it automatically looks them up for the host architecture, and your job's done. However, consider the case where you need to build a binary for use during the build that needs to link against external build-architecture libraries that should be discovered using pkg-config. An example of this is dbus-glib, which builds a binary (dbus-binding-tool) both for use during its build and to ship in one of its .debs. This binary uses the dbus-1 and gobject-2.0 pkg-config modules, linking against the corresponding libraries. In the cross-compilation case, we clearly need to build this binary twice - but now we need to persuade pkg-config to give us build libraries! I've approached this in a hacky fashion in my experiments by using things like this in configure.ac: DBUS_CFLAGS_FOR_BUILD=`unset PKG_CONFIG_LIBDIR; pkg-config --cflags dbus-1` The problem with this is that it's horribly Debian-specific, and it would really be easier for everyone if this kind of change (which I am able to implement in Autoconf/Automake without resorting to packaging-level changes, although it's not all that pretty) could go upstream. The standard upstream approach to this kind of thing is documented in /usr/share/doc/pkg-config/README: Users can define the PKG_CONFIG environment variable to point at the right one, or if they cross-compile and have a correctly named pkg-config (eg. arm-linux-pkg-config) in their PATH that will be used in preference. So, really what it seems that we ought to do is require $host-pkg-config on all cross-building systems just like we require $host-gcc etc. and then *not* set PKG_CONFIG_LIBDIR; maybe as a fallback we could set PKG_CONFIG_LIBDIR in the event that $host-pkg-config is not on the path. With that done, it would be possible to use $host-pkg-config and pkg-config depending on whether cross or native builds are needed, the way it was clearly intended to work upstream. I'm not sure how to get there from here, though. Perhaps get cross-targeted pkg-config packages onto buildd.emdebian.org and allow a while for people to install them? A further wrinkle is that $host-pkg-config will indeed be automatically used for anyone who's using the PKG_CHECK_MODULES Autoconf macro (which I suspect is the majority, but certainly won't be everyone), but not for anyone who's just calling pkg-config directly. Should we just say that if they're doing that then they need to compare build and host architectures directly, the way they're probably already doing for gcc and friends? Would this be a serious regression for Emdebian that would need to be tackled in advance? Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
