How severe are FTBFS bugs caused by the source using uname?
how severe are FTBFS bugs caused by the source using uname to
determine the host/build architecture instead of using
The problem is that on multiarch architectures, most notably amd64
cpus, the uname will not resemble the host/build architecture:
(from a normal Debian Sid i386 system running a 64bit kernel)
% uname -a
Linux dual 2.6.5-amd64 #2 Sun May 9 16:34:33 UTC 2004 x86_64 GNU/Linux
% uname -m
the Debian policy says the following about determining the
architecture we build on and build for:
4.8. Main building script: `debian/rules'
The architectures we build on and build for are determined by `make'
variables using the utility `dpkg-architecture'. You can determine
the Debian architecture and the GNU style architecture specification
string for the build machine (the machine type we are building on) as
well as for the host machine (the machine type we are building for).
Here is a list of supported `make' variables:
* `DEB_*_ARCH' (the Debian architecture)
* `DEB_*_GNU_TYPE' (the GNU style architecture specification
* `DEB_*_GNU_CPU' (the CPU part of `DEB_*_GNU_TYPE')
* `DEB_*_GNU_SYSTEM' (the System part of `DEB_*_GNU_TYPE')
where `*' is either `BUILD' for specification of the build machine or
`HOST' for specification of the host machine.
But some (a lot?) of sources are using uname to determine the
host/build system. The result can be that packages are build for the
wrong architecture or fail to build completly giving gcc/ld errors or
claiming not to know/support the architecture.
So how sever is a FTBFS caused by not setting the arch/host from the
dpkg-architecture variables and uname failing?