as you hopefully have not noticed (well, there was some downtime, but not more than usually afflicted by cablecom) i switched xyzzyxyzzy.net from gentoo to running ubuntu server 7.10 on monday.¹ along with that came a reorganization of the web server directory layout — and i took the chance to clean up. pretty much everything is running again (and thx to having that complete backup of the mysql databases all blogs and photo blogs are back as well — with the exception of the QR code stuff, which was not really generating QR codes for new posts anymore.

this had me baffled as all the path names and what have you were looking ok, permission were fine, the works. still no QR codes and the test image wouldn’t work either…i did manage to get it working, here’s a brief overview² of what i did:

# install command line php5 so that we can poke at the php code manually, so to speak
% sudo apt-get install php5-cli

# qrcode lib lives in /usr/local/share/qrcode/qrcode_php0.50beta10
% cd /usr/local/share/qrcode/qrcode_php0.50beta10

# let's try invoking the sample.php via php5
% php5 sample.php
[...lots of error messages...]

those error messages revealed that i had forgotten to adjust QRCODE_DATA_PATH — for some strange reason, wp-qrcode doesn’t get that across from the wordpress configuration — fixing that path fixed the problem. sweat

define ("QRCODE_DATA_PATH","/usr/local/share/qrcode/qrcode_php0.50beta10/qrcode_data");

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:

1. check out opensim itself:
   • svn co http://opensimulator.org/svn/opensim/trunk opensim
   • build according to instructions
     • ./runprebuild.sh; nant
2. 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/bin directory.
3. enter opensim-libs/openjpeg-libsl and do
   • a make, and then
   • copy the newly built libopenjpeg-libsl-2.1.2.0.so into opensim/bin as well
4. almost there! enter opensim/bin and 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.