> +++ Dechesne, Nicolas [2010-08-23 23:31 +0200]:
>    
>> Hello,
>>
>> 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
> painless.
>    
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
> buggy.
>    
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 
properly...
>    
>> 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 
package.
> 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
> issues.
>    
well, i cannot share that right now, but these packages will be 
available soon on launchpad, we are still working on making them public!
> Wookey
>    

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Reply via email to