On Wed, 5 Sep 2007 19:31:48 +0200
Peter Eisentraut <peter_e@gmx.net> 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/
Attachment:
pgpah0okpFKq9.pgp
Description: PGP signature