Cross compilation with debuild
n-dechesne at ti.com
Tue Aug 24 15:05:41 BST 2010
> +++ Dechesne, Nicolas [2010-08-23 23:31 +0200]:
>> I have another question related to cross compilation...
>> I am still trying to setup a functional cross compilation environment for our
>> packages. I want to be able to build without xdeb, using debuild command (this
>> is mainly because we use other tools such as git-buildpackage).
> This should work fine if you pass -aarmel
> If you want to do the same thing in a controlled environment you can
> now also use pdebuild. I got this working last week. pdebuild-cross
> is just some hook scripts for pbuilder/pdebuild (and a multistrap config so
> it's trivial to make a cross-build chroot with base system+marcin's
> cross tools, but it doesn't actually matter how you get that
> environment created).
> So that's building in a chroot rather than directly on your system,
> which has the advantage that your system doesn't fill up with piles of
> cross-packages (which tends to cause breakage eventually when the
> original native packages get updated), and ensures that the build is
> not relying on unspecified stuff which just happens to be installed.
> But it's slower because pbuilder unpacks chroot and installs stuff
> each time. If building the same thing often then updating the chroot
> image to have the necessary deps is a good idea.
I am building in a chroot already, on a PC running lucid, even though I
am not using pdebuild-cross.
> You use it exactly the same way as pbuilder by changing into the
> source tree and doing 'pdebuild-cross'.
> Get in touch if you are interested in using it because pdebuild-cross
> isn't yet in maverick and you need an updated multistrap for it to be
for now, we use pbuilder already on native h/w, and I am just looking
for a build acceleration method, so cross compilation would be perfect.
I don't think we need pdebuil-cross for now, but I will get back to you
>> When I build a package which has dependency on another .so file, my ./configure
>> script fails, pkg-config complains that it cannot find my package config file
>> (which is available in /usr/arm-linux-gnueabi/lib/pkgconfig.
> Was that ./configure called with the right --build and --host options?
> It should find the pkgconfig files if so. Otherwise I'd say it was
I am using cdbs autotools classe. My debian/rules file only includes
that file. So I don't control how ./configure is called, and this is why
I would have expected that somehow PKG_CONFIG_LIBDIR would be set
>> If I set PKG_CONFIG_LIBDIR to /usr/arm-linux-gnueabi/lib/pkgconfig, then my
>> build is fine, e.g. debuild -ePKG_CONFIG_LIBDIR=/usr/arm-linux-gnueabi/lib/
>> pkgconfig -b -aarmel -us -uc.
>> Is that expected?
> It is generally the responsibility of the build-system config tool to
> set PKG_CONFIG_LIBDIR correctly - i.e autofoo or cmake or whatever.
> That's a problem with packages which don't use such a system, but do
> use pkgconfig. I haven't seen many of those but there probably are
> some and they need that env var setting somehow when cross-building.
> In fact that path ought to be /usr/arm-linux-gnueabi/lib/pkgconfig:
> /usr/arm-linux-gnueabi/share/pkgconfig/ as there are some packages
> which install arch-independent PKGCONFIG files (eg pthreads).
you're right. I know I need share/pkgconfig but not for this specific
> I'm not sure if there are things that would break if an external build
> tools sets this. I can't think of any offhand, however it is currently
> the case that we rely on the rules files to correctly set the build
> environment when called in cross-build form. I'm inclined to leave
> that responsibility there, but I'm open to arguments that it should be
> done elsewhere.
>> I would appreciate any feedback on this.
> What packages are you building? I'd like to be able to reproduce your
well, i cannot share that right now, but these packages will be
available soon on launchpad, we are still working on making them public!
More information about the Linaro-dev