Bug#96436: gcc 2.95 package build stomps on dpkg-dev script variables

[Matthias Klose <doko@cs.tu-berlin.de>]

Daniel Jacobowitz writes:
 > On Sat, May 05, 2001 at 02:50:35PM -0400, Gray Carper wrote:
 > > Package: gcc-2.95
 > > Version: 2.95.4.ds1-0.010424
 > > 
 > > In truth, this applies to all gcc-2.95 versions.
 > > 
 > > When building the gcc-2.95 package, four key dpkg-dev
 > > variables are utilized like this (in "rules.defs")...
 > > 
 > > DEB_HOST_ARCH := $(shell ")
 > > DEB_HOST_GNU_CPU := $(shell dpkg-architecture -qDEB_HOST_GNU_CPU)
 > > DEB_HOST_GNU_SYSTEM := $(shell dpkg-architecture
 > >                         -qDEB_HOST_GNU_SYSTEM)
 > > DEB_HOST_GNU_TYPE := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 > > 
 > > On the systems which we attempted the build (all working from the
 > > *unstable* tree, granted), the build process failed first with
 > > the dpkg-gencontrol script (and then later with the dpkg-genchanges
 > > script). The scripts reported, for example, a lack of architecture
 > > (saying that " " was the host architecture).
 > > 
 > > It turned out that, after the above varibles were set, queries
 > > to those variables through dpkg-architecture returned absolutely
 > > nothing. So, when the dpkg-dev scripts tried to do the queries,
 > > the host architecture (among other variables) was seen as blank.
 > > This caused a build failure every time.
 > 
 > Huh?  THere must be something more going on.  Witness:
 > drow@nevyn:~% export DEB_HOST_ARCH=foo1
 > drow@nevyn:~% export DEB_HOST_GNU_CPU=foo2
 > drow@nevyn:~% export DEB_HOST_GNU_SYSTEM=foo3
 > drow@nevyn:~% export DEB_HOST_GNU_TYPE=foo4
 > drow@nevyn:~% dpkg-architecture -qDEB_HOST_ARCH
 > foo1
 > drow@nevyn:~% dpkg-architecture -qDEB_HOST_GNU_CPU
 > foo2
 > drow@nevyn:~% dpkg-architecture -qDEB_HOST_GNU_SYSTEM
 > foo3
 > drow@nevyn:~% dpkg-architecture -qDEB_HOST_GNU_TYPE  
 > foo4
 > 
 > Those names are used -because- dpkg-architecture uses the same names.
 > 
 > More likely this is going wrong:
 > ifneq ($(TARGET),native)
 > DEB_HOST_ARCH = $(TARGET)
 > endif
 > 
 > I see at least two problems:
 > - TARGET is not set when we include rules.defs from debian/rules directly.

but TARGET isn't _used_ in debian/rules.

 > - $* is not set in these targets:
 > 
 > binary-indep: install $(binary_stamps)
 >         $(MAKE) -f debian/rules2 TARGET=$* $@
 > 
 > binary-arch: install binary-arch-hack $(binary_stamps)
 >         $(MAKE) -f debian/rules2 TARGET=$* $@

ok, but this doesn't explain, why the binary target in debian/rules
fails as well with dpkg-1.9.4