(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 report): ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) # internal libraries need to be redirected to cross version DEB_MAKE_INVOKE+="QOF_LIBS=-L/usr/$(DEB_HOST_GNU_TYPE)/lib -lqof" # prevent CDBS overwriting CC (see bug #450483) DEB_CONFIGURE_SCRIPT_ENV = # 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/ else # only run make check if not cross compiling DEB_MAKE_CHECK_TARGET = check endif (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: ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) # internal libraries need to be redirected to cross version DEB_MAKE_INVOKE+="QOF_LIBS=-L/usr/$(DEB_HOST_GNU_TYPE)/lib -lqof" endif 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 ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) 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 'PKG_CONFIG_LIBDIR=/usr/$(DEB_HOST_GNU_TYPE)/lib/pkgconfig'. This setting is needed to cross build all packages that use pkg-config so it would make sense for this setting to be in dpkg-buildpackage. $ 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 qof-1 -I/usr/arm-linux-gnu/include/qof -I/usr/arm-linux-gnu/include/libxml2 -I/usr/arm-linux-gnu/include/glib-2.0 -I/usr/arm-linux-gnu/lib/glib-2.0/include 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 appropriate. 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 change. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: OpenPGP digital signature