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:
pgpDmOIMtJD7T.pgp
Description: PGP signature