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

dpkg-cross, gccross wrapper and libtool

(For the debian-devel audience, gccross is a wrapper script in the
dpkg-cross package that remaps the @ARGV values passed to the cross
compiler during the cross build so that the correct locations are
specified. i.e. it remaps every call to arm-linux-gnu-gcc at every stage
of the cross build. -L/usr/lib is remapped to -L/usr/arm-linux-gnu/lib
if --host=arm-linux-gnu etc. If no -L option is given, the -l option has
a suitable -L variable prepended. This allows the cross compiler and
libtool to continue even if the original arguments would have caused an
attempt to link against object files of the wrong architecture. Whilst
useful, it is a gross hack and needs a better solution that does not
involve running a script to reprocess every single instruction.)

I've recently spent a lot of time building and testing a variety of
cross built packages, trying to identify reasons for certain common
build failures and bugs and identifying which parts of the current cross
build support are package-specific, which are dpkg-specific and which
can be removed.

One result of this analysis is that the gccross handling inherited from
the dpkg-cross diversion of dpkg-buildpackage and currently handled
within emdebuild from emdebian-tools, is *not* needed for all packages,
just some. Typically, it is required for those packages that both build
a shared library *and* link other objects against that internal library
(whether the linked objects are packaged or not appears immaterial).

The idea for emdebian-tools (>= 0.8.0) is that this workaround will only
be enabled for those packages that require it by putting a tag into
debian/xcontrol (via Emdebian patches) and filing a wishlist crossbuilt
tag against the package as part of the long term mass bug filing for
cross build support. (See the debian-xcontrol package for info on that.)

The problem appears when internal libraries are linked against binaries
built within the same package - a common task. The .la file gets the
wrong location and without gccross, the build tries to link the internal
library against other dependencies in /usr/lib/ which then fails with
"wrong architecture" or "unknown file format".

I originally thought this was due to a broken libtool script - it is not.

I managed to reproduce the problem with one of my own upstream library
packages and this made it a lot easier to work out where things were
going wrong. With the following section in debian/rules, libqof1 can now
be cross built using just 'dpkg-buildpackage -a' (albeit that it
requires a patched dpkg-shlibdeps that is the subject of a separate bug

# internal libraries need to be redirected to cross version
# prevent CDBS overwriting CC (see bug #450483)
# Emdebian-specific customisation
DEB_CONFIGURE_EXTRA_FLAGS += --disable-gdasql
# enable dpkg-shlibdeps to find the internal libraries.
DEB_SHLIBDEPS_INCLUDE_libqof1 = ./debian/tmp/usr/lib/
# only run make check if not cross compiling

(This is for the upcoming libqof1 0.7.3-1 release, --disable-gdasql is
not supported in QOF 0.7.2).

For this bug, the relevant instructions are:

# internal libraries need to be redirected to cross version

Like many upstreams, QOF defines QOF_LIBS as a hardcoded value of
QOF_LIBS="-lqof" in configure.in|ac and is unable to rely on pkg-config
because that would make the package pre-depend on itself (or run
./configure twice just to parse the pkg-config data for a value that is
obvious to the upstream developer(s) anyway). I decided not to
explicitly set this value in the upstream because I cannot be sure that
other cross-building situations outside Debian would actually want to
use /usr/arm-linux-gnu/lib.

Other non-CDBS packages can have similar values passed to $(MAKE) using
the same process as the current mass bug filing for general cross
building support which already uses ifneq
by extending $(CROSS) or $(confflags).

I intend to incorporate these variables into existing cross building
support where necessary, via the same mass bug filing.

A more common need is relatively simple for dpkg-buildpackage to adopt:
pkg-config needs the PKG_CONFIG_LIBDIR variable to be set by
'dpkg-buildpackage -a' as

This setting is needed to cross build all packages that use
pkg-config so it would make sense for this setting to be in

$ pkg-config --libs qof-1
-lqof -lglib-2.0
$ PKG_CONFIG_LIBDIR=/usr/arm-linux-gnu/lib/pkgconfig pkg-config --libs qof-1
-L/usr/arm-linux-gnu/lib -lqof -lglib-2.0
$ pkg-config --cflags qof-1
-I/usr/include/qof -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
$ PKG_CONFIG_LIBDIR=/usr/arm-linux-gnu/lib/pkgconfig pkg-config --cflags
-I/usr/arm-linux-gnu/include/qof -I/usr/arm-linux-gnu/include/libxml2

In this way, all the other variables used by the QOF build are already
remapped by pkg-config when PKG_CONFIG_LIBDIR is set correctly.

Once that is set, a lot of packages will cross build without needing
gccross support. Those that do will have crossbuilt bugs filed against
them (wishlist) and will require the workaround support from
emdebian-tools until those bugs are closed. gccross can then become a
conditional part of cross building support and emdebuild can skip that
stage whenever possible, simplifying the cross build process enormously.

Other packages can be modified within debian/rules to provide the custom
data required for the cross compiler to correctly locate the internal
objects and for libtool to correctly relink those objects upon
installation into debian/tmp/usr/lib or debian/foo/usr/lib etc. as

It would be good if dpkg-buildpackage could ensure that the
PKG_CONFIG_LIBDIR is set when 'dpkg-buildpackage -a' is called.

I have therefore decided *not* to seek the support of gccross within
dpkg itself so I'm retitling this bug to only seek the PKG_CONFIG_LIBDIR


Neil Williams

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: