we noticed last week (well, actually a bit longer than that) that OpenSim would not really care to run on PowerPC platforms. the symptoms were that (a) it would die with an array index exception on restart, and (b) the SL client would crash horribly when connecting to the region before the restart :-( with most of the development going on on intel boxes, suspecting endian issues was not really rocket-science.
short detour: when we talk of “endian issues” we refer to the way a CPU organizes data internally. to quote wikipedia:
endianness is the byte (and sometimes bit) ordering used to represent some kind of data. Typical cases are the order in which integer values are stored as bytes in computer memory (relative to a given memory addressing scheme) and the transmission order over a network or other medium. When specifically talking about bytes, endianness is also referred to simply as byte order.
the terms big endian and little endian are much older than computers, much older. they originate with the inhabitants of jonathan swift’s Lilliput and Blefuscu and refer to the way they would crack an egg open: big endians started at the big end.
for reasons shrouded in the fogs of history, intel x86 CPUs are little endian, motorola CPU generally are big endian as are PowerPC CPUs.1
anyhow, to return to our story, we were suspecting endianess issues with OpenSim — and the underlying libsecondlife. following up on clues provided by Neas Bade i started looking at openjpeg-libsl (the native code library responsible for doing most of the JPEG2000 coding). that turned out to be a dead end more or less.
turning my attention to the terrain handling, it transpired that the terrain when generated was looking fine (you can save a generated terrain via OpenSim’s region console — which i did and then examined it using [the gimp]). loading it back in from the data stores (OpenSim supports a number of data storage adapters) however, returned a corrupted terrain image. that lead to fix #1: serialization of the terrain in the SQLite and MySQL data storage adapters was fine, but reification was borked.2
unfortunately, while OpenSim would now restart fine, we still could not connect as the client would barf violently on the terrain data OpenSim was handing out :-( looking at the code in OpenSim that supplied the client with the ill-digested terrain dope it transpired that this time it was libsecondlife that was cracking the eggs open from the little end only. actually, it was doing so in two places: LLUUIDs were not properly serialized and packed bits were completely oblivious of the fact that one could start cracking the eggs open at the big end. bug fixes #2 and #3 (this time to libsecondlife).34
so, what steps do you need to take to get OpenSim running on PPC? here are the instructions:
- check out opensim itself:
svn co http://opensimulator.org/svn/opensim/trunk opensim
- build according to instructions
- check out opensim-libs:
svn co http://opensimulator.org/svn/opensim-libs/libsl1550 opensim-libs
cd opensim-libs; nant
- you should end up with a sparkling new libsecondlife.dll in
- copy that one over into the
make, and then
- copy the newly built
- almost there! enter
opensim/binand edit libsecondlife.dll.config and remove the
cpu="x86"tag in the last dllmap line, so that it looks like this:
start OpenSim.exe and enjoy.
…waiting for the explanations to appear in the comments :-) ↩
submitted via Neas Bade to OpenSim and in the code base starting with subversion release 3397. ↩
submitted to libsecondlife by yours truly, still waiting for check-in to libsl’s subversion repository. also, submitted by Neas Bade into the opensim-libs code base. ↩
now also in libsl code base (subversion release 1638 for release branch, release 1640 for trunk branch) :-) ↩