Martin Spott wrote: > Erik Hofman wrote: > > I've tried several approaches to get Nasal working for big-endian > > (32-bit) systems but they all fail. I don't see a way to get this > > working and this makes FlightGear unusable for IRIX at least: > > Man, am I happy that I'm not the only one with disabled throttle on > IRIX :-)
Hrm. I kinda assumed when the reports stopped that this was just a symptom of a version skew or unsynchronized checkout. :( Try this: hard-code the definition at the top of nasal.h to be *little* endian. This will produce unsafe code*, but it should work. This will tell us that the problem is definitely the endianness handling. * It will be possible to create a special number value that "looks like" a reference, and therefore cause the interpreter to follow an arbitrary pointer. But the chance of that happening accidentally is 1 in 2^32, so the test should certainly work. I'm a little suspicious, though, because the structure layout code didn't change with these Nasal updates (and because the 64 bit layout works fine on my laptop). I'm wondering if something else is being triggered in the MIPS port. What seems to be happening is that something is clobbering a reference that points to live data, so the garbage collector cleans up the namespace hash incorrectly and you get undefined symbol errors. Almost any kind of memory corruption issue can cause this. Unfortunately I've since switched jobs, and don't have access to a big endian machine to test with any more. If someone can set me up with ssh access to a shell account (no need to run the whole fgfs binary) on a Mac or SGI or whatnot, let me know. :) Andy _______________________________________________ Flightgear-devel mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
