[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cross pkgconfig



+++ Enrico Weigelt [2011-05-07 13:07 +0200]:
> * Wookey <wookey@wookware.org> schrieb:
> > What did you conclude about cross-pkgconfig
> > Should we be using --host <triplet> or <triplet>-pkg-config to call it
> > in 'cross-mode'?
> 
> Relying on the triplet for crosscompiling is a bad idea.
> As soon as you got two different targets which just happen to
> have the same triplet, you'll get into trouble ...

What we want if for pkg-config to be using the same paths as the
cross-libraries are installed to. In dpkg-cross world that is the
triplet path, matching the cross-compiler path.

In multiarch world that is the multiarch path for the specified
architecture.

If the triplet is not reliable for pkg-config then it's not reliable
for cross-comiling in general, because it's also used to call the
compiler. I'm well aware of the issues here in x86 where 4 different
triplets map onto one ABI. For all other Debian architectures we have
a unique triplet for each ABI. 

Currently cross-compiling is still using the dpkg-cross mechanism
until enough packages have arch-dependent header files moved to
multiarch paths (and tools understand the build-depends
cross-dependency extension syntax). 

The existing wrapper does not do anything clever at all and simply
uses the (dpkg-cross-style) path it is told to use (encoded into the
symlink name). At some point that can be changed to use the
corresponding multiarch path.

So calling arm-linux-gnueabi-pkg-config sets PKG_CONFIG_LIBDIR to 
/usr/arm-linux-gnueabi/lib/pkgconfig 

calling i486-linux-gnu-pkg-config set it to
/usr/i486-linux-gnu/lib/pkgconfig

The wrapper script could do some sanity checks and even mapping from
triplet to multiarch path with dpkg-architecture but a) that limits
its use to targets known to dpkg-cross (so it won't work for avr32 or
armhf (yet) and b) I'm not sure it knows what to do any better than
whatever is calling it. I decided a simple tool was best and the
surround build-foo should call it with the right name (and ensure that
a uitable symlink existed). 

If people have better ideas about how this should work I'm happy to
hear them, as I'm not yet sure that the above is sufficient for all
use-cases. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


Reply to: