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) LDFLAGS=$(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
