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

Re: Cross dependency syntax - do we need :native?



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).
 
> 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.

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.
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.

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.

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.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpFYcryCKZT0.pgp
Description: PGP signature


Reply to: