On Wed, 5 Sep 2007 19:31:48 +0200 Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> It has been suggested in bug #411520 that cdbs should be set up so that > it preserves CFLAGS set in the environment. But I haven't found any > clear specification about how debian/rules, being a makefile, should > deal with environment variables. http://lists.debian.org/debian-embedded/2007/08/msg00033.html Where MAKEFLAGS are concerned, packages and build tools should not be overriding environment variables and there is an issue in CDBS regarding this which I need to get around to filing. > CDBS is a culprit but also very easy to fix: > DEB_CONFIGURE_SCRIPT_ENV= > > The reason is that CDBS presets > DEB_CONFIGURE_SCRIPT_ENV = CC="$(CC)" CXX="$(CXX)" CFLAGS="$(CFLAGS)" > CXXFLAGS="$(CXXFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLA GS="$(LDFLAGS)" > > but passes those values TO ./configure instead of reading them > AFTER ./configure has had a chance to process --build= and --host=. This used to work because dpkg-cross explicitly overrode MAKEFLAGS but this caused build failures with packages that need to compile tools during the build - wrong architecture when executing. (#425445) Now the CDBS behaviour actually re-implements the broken dpkg-cross behaviour that is being fixed during the rewrite for #439979 so that although the dpkg-cross changes fix builds like libx11-6 (which compiles and then runs a tool {see #425445}, grep now fails to cross-build without the above patch to debian/rules because the ./configure setting (safely managed via dpkg-architecture) is thrown out. I would like to see that debian/rules and any other build tool NEVER changes MAKEFLAGS or any related environment variable to make cross-building easier. > The best I could find is Policy 10.1 which states that "the following > compilation parameters should be used: > > CC = gcc > CFLAGS = -O2 -g -Wall" > > (It doesn't say, "these variables should be set this way".) It appears, > however, that hardly any package (containing C language code) > explicitly sets CC, and I think it is certainly useful to be able to > set a different CC in the environment. Only with care. Just changing $CC is insufficient because you also need to change the include path for libraries and the LD_LIBRARY path, otherwise you'll end up compiling with arm-linux-gnu-gcc but linking against libraries from /usr/lib instead of /usr/arm-linux-gnu/lib. This is currently handled by remapping the paths for each command during the build using symlinks and a perl parser script in dpkg-cross. Guillem is working on a replacement dpkg method for ensuring that the cross-compiler finds the correct libraries. http://lists.debian.org/debian-devel/2007/08/msg01152.html > Yet at the same time most > packages set CFLAGS explicitly, overriding anything that's there > before. CFLAGS is less of a problem for cross-building (so far) - it is CC that has been the most problematic. > The language in the policy and various rules templates appear > to encourage that. But as the submitter of #411520 stated, it could > also be useful to be able to build a package with different compiler > flags. Not just the flags. On a related note, I'm thinking that *all* packages using ./configure should be using: DEB_HOST_GNU_TYPE := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE := $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) ... ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) \ ... This then allows cross-builders to simply call dpkg-architecture to set the correct environment and ./configure will do the right thing. Once the dpkg-cross rewrite makes it into unstable (hopefully in the next dpkg upload after the one today - i.e. in dpkg 1.14.7) I'll go for a rebuild of the Emdebian packages and start filing bugs against those packages that don't bother with these simple checks, tagged with the usertag 'cross-build'. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpCVgjXcTYdM.pgp
Description: PGP signature
