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

Re: debian/rules and environment variables

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.


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:
> The reason is that CDBS presets 
> 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.


> 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

Attachment: pgpah0okpFKq9.pgp
Description: PGP signature

Reply to: