Re: [Flightgear-devel] Bug#461399: simgear_1.0.0-1 (alpha/unstable): FTBFS: Unrecognized CPU architecture
Sorry for the late reply... been ill, and then I had much to catch up on afterwards, and so on... almost forgot I needed to answer this. Andy Ross skrev: Ove Kaaven wrote: It's not just him being cranky about his own pet issues, it's about policy and the pursuit of high software standards. High standards for software you (literally!) can't run? Please. This is pedantry and egotism at its worst. I'm terribly sorry my software isn't good enough for you, I really am. But you can either work with me to fix it or take potshots about trivial build problems and Heisenberg bugs that can't actually be exhibited. You and Steve picked the latter. I don't quite see what you're talking about. I never picked any of this. There are things called compromise, there are things called understanding someone else's viewpoint, and there are even things called seeing things from multiple angles. I'm capable of all these things, and sometimes I try to use my ability to do this to (try to) explain someone else's viewpoint in a rational manner, so that people can understand each other better and hopefully reach a compromise. In *no* way should you mistake *explaining* a viewpoint as unconditionally *sharing* it. I'd be equally capable of explaining *your* viewpoint to Steve if I wanted to. I just don't think it'd help. There's a principle: if two viewpoints (like Steve's and yours) are in irreconcilable conflict, then the rules win. And in this case, the rules are called Debian policy; they say there *is* a problem here, and I need to deal with it, or someone else will, probably by removing the package from the distribution. My only interest here is ensuring that this doesn't happen. To accomplish this, I need to do *something*, and I've explained what my options are. Doing what Steve asks is one, but not the only one. I asked which route to take, and you haven't even tried to answer that. (And for the record, by high standards I'm referring to portable code; in general, code written to be very portable is also more robust, and I'm pretty sure Steve holds that principle in high regard. But *I* never accused you of anything. I just want a solution, and reaching a Steve sucks consensus doesn't *really* bring me any closer to one.) [* Something, I will point out yet again, that no one has done. Do either you or Steve have console access to a s390, Alpha, or PA-RISC box with 3D hardware? Has *anyone* ever run the Debian fgfs binary on those architectures?] For this issue, that doesn't matter. Like I said in my previous mail, if the package is declared Architecture: all, then FlightGear *must* build on everything, whether or not anyone actually uses it. Otherwise, the package would have to declare a list of the supported architectures (which would also resolve this bug report, albeit it wouldn't be quite as pretty, and I'd have to maintain that list - but if you insisted...) Still, I know for a fact that some people have run fgfs on Alpha in the past. I'm not sure about S/390 and PA-RISC. Debian developers have SSH access to machines of all Debian architectures. I think the PA-RISC one is currently taken offline until they get around to upgrading its kernel, but I could log into the others. I may not be able to run anything that requires X, though (or, well, maybe I could forward X11 over SSH...). And I'd very much prefer the gcc output I asked for to anything that comes out of a single individual's brain. This stuff is too easy to get wrong, and it's literally one command to run. Just run it and send me the output. Or don't, I guess. Your call. Attached. (So, any surprises in there?) #define __DBL_MIN_EXP__ (-1021) #define __FLT_MIN__ 1.17549435e-38F #define __DEC64_DEN__ 0.001E-383DD #define __CHAR_BIT__ 8 #define __WCHAR_MAX__ 2147483647 #define __DBL_DENORM_MIN__ 4.9406564584124654e-324 #define __FLT_EVAL_METHOD__ 0 #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 #define __GNUC_PATCHLEVEL__ 3 #define __DEC64_MAX_EXP__ 384 #define __SHRT_MAX__ 32767 #define __LDBL_MAX__ 1.18973149535723176508575932662800702e+4932L #define __UINTMAX_TYPE__ long long unsigned int #define __linux 1 #define __DEC32_EPSILON__ 1E-6DF #define __CHAR_UNSIGNED__ 1 #define __LDBL_MAX_EXP__ 16384 #define __linux__ 1 #define __SCHAR_MAX__ 127 #define __USER_LABEL_PREFIX__ #define __STDC_HOSTED__ 1 #define __LDBL_HAS_INFINITY__ 1 #define __DEC64_MIN_EXP__ (-383) #define __DBL_DIG__ 15 #define __FLT_EPSILON__ 1.19209290e-7F #define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L #define __DEC32_MAX__ 9.99E96DF #define __unix__ 1 #define __DECIMAL_DIG__ 36 #define __gnu_linux__ 1 #define __LDBL_HAS_QUIET_NAN__ 1 #define __GNUC__ 4 #define __FLT_HAS_DENORM__ 1 #define __DBL_MAX__ 1.7976931348623157e+308 #define __DBL_HAS_INFINITY__ 1 #define __s390__ 1 #define __DEC32_MIN_EXP__ (-95) #define __LDBL_HAS_DENORM__ 1 #define __DEC128_MAX__
Re: [Flightgear-devel] Bug#461399: simgear_1.0.0-1 (alpha/unstable): FTBFS: Unrecognized CPU architecture
Ove Kaaven wrote: It's not just him being cranky about his own pet issues, it's about policy and the pursuit of high software standards. High standards for software you (literally!) can't run? Please. This is pedantry and egotism at its worst. I'm terribly sorry my software isn't good enough for you, I really am. But you can either work with me to fix it or take potshots about trivial build problems and Heisenberg bugs that can't actually be exhibited. You and Steve picked the latter. I think he already provided the requisite defines, though somewhat buried in his mail. Beyond that, perhaps this web page would be of interest: http://predef.sourceforge.net/prearch.html No, someone needs to *run* this and *test* it on those architectures.* I'm not going to commit blind changes to either Nasal or SimGear. Since you can't actually run the code you are complaining about, someone needs to work with the command line Nasal interpreter from http://plausible.org/nasal to do the test. [* Something, I will point out yet again, that no one has done. Do either you or Steve have console access to a s390, Alpha, or PA-RISC box with 3D hardware? Has *anyone* ever run the Debian fgfs binary on those architectures?] And I'd very much prefer the gcc output I asked for to anything that comes out of a single individual's brain. This stuff is too easy to get wrong, and it's literally one command to run. Just run it and send me the output. Or don't, I guess. Your call. Andy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug#461399: simgear_1.0.0-1 (alpha/unstable): FTBFS: Unrecognized CPU architecture
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=simgeararch=alphaver=1.0.0-1stamp=1198415406file=logas=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/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug#461399: simgear_1.0.0-1 (alpha/unstable): FTBFS: Unrecognized CPU architecture
Ove Kaaven wrote: It looks like there are some portability issues in the current code... On three platforms which don't have the CPU power (or GPU support!) to actually, y'know, run the software. :) Steve Langasek wrote: 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 is in the Nasal interpreter. Language interpreters routinely enjoy making some platform assumptions in the name of performance. In this case, that union trick chops the size of a naRef (and therefore the memory footprint of almost everything Nasal does) in half. I'm more than prepared to pay for this benefit in the form of the occasional dispeptic rant from uninformed distribution folks who are more interested in wagging their fingers at developers than they are in actually running the software [How's that for tone, Steve? I can flame with the best of them if you really want to throw down. Try a little less presumption next time.] As explained very clearly in the comments, all known platforms support this code just fine, and the benefits are very large. And I'm even conservative about refusing to compile on platforms on which I can't test, thus the #error (it's a feature, not a bug!). I'm happy to take patches, though. This support is trivially really easy to add, if Mr. Langasek is actually willing to help out a little. Just the output of echo | gcc -dM -E - on each of the platforms is sufficient. ... which is a cop-out, and a serious regression because the old code built and ran fine on all architectures. On all *debian* architectures. I had a ton of trouble getting the original stuff to work for everyone who wanted to use it. Manually enumerating architectures was the overwhelmingly simpler choice. I'm sorry you disagree. Andy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
