Following up on my earlier post on the open source release of Second Life, I’ve now successfully built Second Life from source on both Mac OS X and Ubuntu. The Mac OS X build in Xcode went smoothly. The build in Linux was a little more finicky, but not bad considering that it’s still alpha. Read on if you’d like to vicariously live the gory details.
There’s something extraordinarily satisfying about exploring a world created by users, in a virtual body you designed yourself, using a client you built yourself. An open source client completely fits with the Second Life philosophy.
On my Mac I compiled it using Xcode 2.2.1. That’s what I had installed on my fastest laptop, so I figured I’d try it while waiting for Xcode 2.4.1 to download, even though they recommend 2.4.1. I got two warnings about unused variables, but otherwise it compiled without complaint. I only ran into one hitch: the first time around I compiled it using the “Development” build configuration instead of the “Deployment” build configuration. The compiled application opened up the login window, with an extra text field containing the value “DMZ”. When I tried to log in I got the error message: “Unable to connect to server. Could not request domain name: userserver.dmz.lindenlab.com”. I’m guessing this is a test server that only lives within Linden and isn’t accessible from outside.
I experimented with the extra text field and found that it autocompleted “Agni”, “Ganga”, “Siva”, and “Local” in addition to “DMZ”. Local gave me an error message that I suspect means it couldn’t find a Second Life server running on localhost, and the others gave me error messages that I suspect mean the server was accessible, but I don’t have an account on that box. I take this as a positive sign that they are making progress on transitioning to a multi-server virtual world. The one thing I couldn’t figure out was what to enter in the extra field to get to the live server. [Though from later debugging efforts in the Linux client, it looks like Agni may be the live server.] So I recompiled with the “Deployment” build configuration, and logged in to the live server without a hitch. (In fact, I’m still there as I write this, sitting in on Magnatune‘s classical channel on Kula 1 while watching the sun rise.)
On the Linux side, they could definitely take some steps to simplify the build process. Aside from debugging compile errors (pretty much all caused by dependencies that weren’t listed in the wiki until I added them), I spent a silly amount of time manually copying files from one location to another. Both the dependency checking and the file copying could be handled by a simple makefile, so I expect they could also be handled by scons (Second Life’s chosen build tool).
The specific problems I ran into were missing header files: gl.h, glext.h, glu.h, Xlib.h, and Xutil.h. I got these from the mesa-common-dev, libglu1-mesa-dev, and libx11-dev packages on Ubuntu. Then the compile failed because it was missing yacc and lex, so I installed bison and flex.
Then it failed with “error: previous declaration of `int yyparse()'”. I worked around it with hack from the common compilation problems wiki page: “comment out #ifdef __cplusplus lines in lscript/lscript_compile/indra.y”.
Then it failed with an error “/usr/bin/ld: cannot find -lz”, so I installed the zlib development package (Ubuntu package zlib1g-dev, looks like in Red Hat the equivalent is zlib-devel).
Then it failed with an error “undefined reference to `yyparse'”, so I had to go back and undo the hack to indra.y. Apparently it really only needed the zlib development package the first time.
The final build problem I ran into was the same problem as the Mac client: the compilation instructions suggest compiling with BUILD=release, but this puts you into the development login screen. So I recompiled with BUILD=releasefordownload, and logged in to the live Second Life world. Which promptly crashed with image rendering errors: “j2k_to_image: failed to decode image!” and “llrender/llimagegl.cpp(811) Bad number of components for texture: 0”. Ah well, it is an alpha client. At least now I have a chance of tracking down the problem and fixing it myself.