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).[^3][^4]
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
./runprebuild.sh; nant
- check out opensim-libs:
svn co http://opensimulator.org/svn/opensim-libs/libsl1550 opensim-libs- build:
cd opensim-libs; nant - you should end up with a sparkling new libsecondlife.dll in
bin - copy that one over into the
opensim/bindirectory.
- enter
opensim-libs/openjpeg-libsland do- a
make, and then - copy the newly built
libopenjpeg-libsl-2.1.2.0.sointoopensim/binas well
- a
- almost there! enter
opensim/binand edit libsecondlife.dll.config and remove thecpu="x86"tag in the last dllmap line, so that it looks like this:
start OpenSim.exe and enjoy.

Trying to do opensim-libs, see template error message, but build fails after that. Here’s what I get:
map:
BUILD FAILED
Nested build failed. Refer to build log for exact reason.
comment by Scott Norman — February 13, 2008 @ 10:04
Tried building opensim-libs, I see error on message_template.msg, but build fails after that and never creates ibsecondlife/Packet.cs. Sent email with details. I’m on PowerBook G4 and tired with 10.5.2, 10.5.1, 10.4.11.
comment by Scott Norman — February 13, 2008 @ 11:21
that is, as i wrote in step 2, to be expected. the nant build file tries to regenerate the message templates — which is not necessary (and, since the mapgenerator is borked) actually messes up
libsecondsecondlife/_Packets_.cs.so, proceed as follows:
that will restore
_Packets_.csto its former glory and then build the rest.comment by DrScofield — February 13, 2008 @ 11:40
sigh…just realized that i was not using markdown markup correctly:
_characters got lost. i’ve corrected the main post and cleaned it up (learned some more markdown markupawfully sorry about that & thx for getting back to me on this!
comment by DrScofield — February 13, 2008 @ 11:56
Need one more change its Packets, not Packet.
comment by Scott Norman — February 13, 2008 @ 13:16
got a patch in for
libsl1550/libsecondlife/libsecondlife.build— the dance with_Packets_.csis no longer necessary & i’ve removed the steps in the instructions above.comment by DrScofield — February 13, 2008 @ 20:03
Thanks for the update. I added your steps to the OpenSim Wiki and linked to this page so people could see the info on the issues with PowerPC.
comment by Scott Norman — February 15, 2008 @ 08:22
[...] mentioned in an earlier post, opensim’s libsecondlife sources are not contained within the main opensim source tree, you [...]
pingback by xyzzy xyzzy… » re-building opensim’s libsecondlife… — March 13, 2008 @ 16:19