Re: Cross dependency syntax - do we need :native?
+++ Neil Williams [2011-01-18 20:38 +0000]:
> On Tue, 18 Jan 2011 19:05:48 +0000
> Wookey <wookey@wookware.org> wrote:
>
> > I need examples of packages which, when cross-built, depend on a
> > native (i.e build architecture) library package at build-time. That
> > would be because they build a tool which is used during the build, but
> > is not shipped in the package, and that tool needs a library that
> > is not in build-essential to build.
>
> libgtk2.0-0
> libpango1.0
> Anything using CORBA
> Anything using GObject marshalling for introspection (potentially).
OK. I'll check that lot out. I'm aware of the gobject introspection
fun and games, but it didn't imply external (build arch) library
dependencies so far as I could tell. It does usually break in
cross-builds.
> > I suspect such things exist but I've been told that we should find at
> > least one example of this actually occuring in the archive before
> > putting functionality to cater for this in the multiarch spec.
>
> Anything which requires CC_FOR_BUILD in the Emdebian Crush patches.
No, i don;t believe that is sufficient indication: lots of things need
a build-arch compiler to build something, but that does not imply any
requirement in that build for build-arch libs beyond libc.
> Also, check the xcontrol files for *extra* build dependencies relative
> to the control file of the same version - typically the same package as
> the one trying to be cross-built. Some of these tools will themselves
> depend on their own libraries (like libglib2.0-0) which would have to
> exist in the cross-building environment as both native and host.
Right, but if the tool ends up in the final package then we can just
use it and reply on its (install)dependencies to get the right stuff
installed. So there is no need here for a specific build-depends:
libfoo:native. You only need that when the tool is not available in the
archive.
> Specifically, libglib2.0-0 is a bit interesting here - pkg-config now
> depends on it but pkg-config is not a dependency of build-essential but
> *is* a build-tool dependency of many packages, whether those use GLib
> or not, so it will be installed as a native package anyway.
>
> Basically, the thing with GTK and Pango is that there are tools, built
> during the build, which are executed during the build which create
> (generally data) files which are then packaged and underpin the
> functionality of the package.
>
> When cross-building, either you skip this tool entirely (which led to
> Crush having missing text and missing graphics) or you bring it in
> from a natively built package for the build architecture and find a
> way to execute that script within the cross-build tree and yet get all
> their paths right in the final package.
Agreed. And how often are such tools not available from a package in
the archive, but do depend on native libs to be built? Do the GTK and
pango build-time tools end up in packages or not?
> IDL is another example of the same thing. A tool built during the
> build which is executed. In a cross-build, that tool would need to be
> provided by the native version of the package. This was the main reason
> why liborbit was such a PITA to cross-build for Crush.
>
> In most cases, the tool itself is packaged with a library - sometimes
> the -dev package of the library.
Indeed. I'm looking for cases when it isn't.
> These internal dependencies are completely hidden until the native
> version of the tool is not available in the cross build environment.
>
> A different side of the same problem is arbitrary config scripts - ones
> where most people would expect the package ./configure to use
> pkg-config. Although most of the ones I remember were Arch:all there may
> be some compiled ones. (The Arch:all ones generally don't allow path
> changes to look in the right locations, adding to the problems.) Again,
> ORB packages can rely on such tools.
It should always be possible to make things look in/operate on the right
locations, although it may well not be easy. Do we know of cases where
this realy is not a valid assumption?
You have provided some useful things to check. thanks.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: