On Thu, Sep 22, 2011 at 09:24:24AM +0200, Vincent Danjean wrote: > > Keeping /usr/lib/pkgconfig on the path was quite deliberate on my part. > > Certainly any library shipping in /usr/lib/pkgconfig is not a multiarch > > library, but that doesn't actually mean it has to be a *native* library: it > > will be possible to cross-install many -dev packages for a while before it's > > possible to co-install them together with the native versions.
> > So I do think it's useful to look in /usr/lib/pkgconfig by default even in > > the cross-config (and obviously as a last resort, after searching the > > architecture-specific directories). In general I think people will find it > > easier to simply remove any conflicting native -dev packages from their > > build environment than to fiddle with the pkg-config path. > For my part, I think this is really error prone. Well, we'll have to agree to disagree then and let the maintainer decide. > Lots of native libraries will be wrongly detected as present when > cross-compiling. Why do you have -dev packages for "lots of native libraries" installed in your cross-build environment? If you *have* a .pc for the foreign-arch library, why isn't this being found first (in one of the mentioned paths)? If you *don't* have a .pc for the foreign-arch library, you must not want to build against that library. Why doesn't the build system of the software you're building have an option to disable using that library even if present? I just don't see that being a common case; whereas I do see a big benefit to having this work out of the box with lots of -dev packages currently in the Debian archive, with no further modifications to pkg-config paths. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
