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. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
