Your message dated Fri, 18 Jan 2008 20:50:35 +0100
with message-id <[EMAIL PROTECTED]>
has caused the Debian Bug report #461399,
regarding simgear_1.0.0-1 (alpha/unstable): FTBFS: Unrecognized CPU architecture
to be marked as having been forwarded to the upstream software
author(s) [EMAIL PROTECTED]
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Hi FlightGear developers.
It looks like there are some portability issues in the current code... I
got this report on the Debian packages. I could patch the missing ifdefs
I guess (though it'd be nice if you fixed them for a future release),
but could you comment on the 64-bit issue?
Steve Langasek skrev:
Package: simgear
Version: 1.0.0-1
Severity: serious
simgear is now failing to build on alpha, hppa, and s390 with the following
error:
if gcc -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -fPIC -pipe -g -O2 -D_REENTRANT
-MT bitslib.o -MD -MP -MF ".deps/bitslib.Tpo" -c -o bitslib.o bitslib.c; \
then mv -f ".deps/bitslib.Tpo" ".deps/bitslib.Po"; else rm -f
".deps/bitslib.Tpo"; exit 1; fi
In file included from nasal.h:7,
from data.h:4,
from bitslib.c:2:
naref.h:20:3: error: #error Unrecognized CPU architecture
[...]
A full build log can be found at
<http://buildd.debian.org/fetch.cgi?pkg=simgear&arch=alpha&ver=1.0.0-1&stamp=1198415406&file=log&as=raw>.
The reason for this is the following code in naref.h:
/* Rather than play elaborate and complicated games with
* platform-dependent endianness headers, just detect the platforms we
* support. This list is simpler and smaller, yet still quite
* complete. */
#if (defined(__x86_64) && defined(__linux__)) || defined(__sparcv9) || \
defined(__powerpc64__)
/* Win64 and Irix should work with this too, but have not been
* tested */
# define NASAL_NAN64
#elif defined(_M_IX86) || defined(i386) || defined(__x86_64) || \
defined(__ia64__) || defined(_M_IA64) || defined(__ARMEL__)
# define NASAL_LE
#elif defined(__sparc) || defined(__ppc__) ||defined(__PPC) || \
defined(__mips) || defined(__ARMEB__)
# define NASAL_BE
#else
# error Unrecognized CPU architecture
#endif
... which is a cop-out, and a serious regression because the old code built
and ran fine on all architectures.
The above code should have __alpha__ added to the NASAL_LE list, and
__hppa__, __s390__, and __s390x__ added to the NASAL_BE list.
BTW, according to data.h, the NASAL_NAN64 option exists to support stupid
union tricks:
// On 64 bit systems, Nasal non-numeric references are stored with a
// bitmask that sets the top 16 bits. As a double, this is a
// signalling NaN that cannot itself be produced by normal numerics
// code. The pointer value can be reconstructed if (and only if) we
// are guaranteed that all memory that can be pointed to by a naRef
// (i.e. all memory returned by naAlloc) lives in the bottom 48 bits
// of memory. Linux on x86_64, Win64, Solaris and Irix all have such
// policies with address spaces:
[...] Linux doesn't document this rigorously, but testing
// shows that it allows 47 bits of address space (and current x86_64
// implementations are limited to 48 bits of virtual space anyway). So
// we choose 48 as the conservative compromise.
So this assumes the kernel will never expose more than 48bits of address
space to userspace processes -- a short-sighted and groundless assumption,
the reason Linux hasn't "documented this rigorously" is because there is no
such guarantee. The NASAL_NAN64 option should be thrown out for all Linux
variants.
--- End Message ---
