Building Second Life
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.
tags: open source
| comments: 20
| Sphere It
submit: 
0 TrackBacks
TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/5155
Comments: 20
Christian, I admire the sentiments that started this effort, but "public domain" is not the right choice of licensing arrangement. The biggest and most obvious problem is that you don't have the right to release any code from Linden to the public domain. Only the copyright holder has the right to do that. I understand that the public domain often appears to be a "simpler" legal solution, but it's not. I can connect you with a number of experienced open source lawyers, if you'd like to learn more.
But really, at this point I recommend contributing your Visual Studio 2005 instructions back to the Second Life developer wiki, and dropping the opensecondlife.org wiki. Forking an open source project to add value makes sense, but it looks to me like you're forking just to prove you can.
Allison, couple of things. opensecondlife.org is not putting the Second Life source code in the "public domain", hopefully that can be made more clear on the front page. All of the patches that are accepted in to the tree must be released under the public domain. They can also release a version of their patches to LL under the contributor agreement, or whatever the original author likes but any *modifications* that go in to opensecondlife.org will be under public domain.
The Visual Studio 2005 instructions are already on the developer wiki, and the code patches are in the bug tracking system and awaiting approval. opensecondlife.org is filling the gap in between patch submission and acceptance, not "forking to prove it can".
Other than that your article looks well researched, I enjoyed the technical detail on what you encountered in the build process.
Actually it's because Linden Lab is only offering the source as an archived drop every 2 weeks. We have the only source repository for people to collaborate around.
OpenSecondLife will be working with Linden Lab to approve contributors under an agreement that Linden Lab's legal department will accept.
All of the patches that are accepted in to the tree must be released under the public domain. They can also release a version of their patches to LL under the contributor agreement, or whatever the original author likes but any *modifications* that go in to opensecondlife.org will be under public domain.
You misunderstand the fundamental nature of the public domain. Anything released under the public domain has no protection under copyright law. A public domain release of rights is not reversible, so the contributors will no longer own the rights in order to grant any kind of separate license to Linden. And given the legal complexity of maintaining a repository of mixed public domain and copyrighted code, I expect Linden would be unable to accept any patches released under the public domain.
The Visual Studio 2005 instructions are already on the developer wiki...
Good. Are you merging any changes people make to one copy of the text over to the other?
...and the code patches are in the bug tracking system and awaiting approval.
Also good.
opensecondlife.org is filling the gap in between patch submission and acceptance...
So, what will you do if the patches are rejected? Back out the changes in your repository? Continue to maintain the forked code? Will you continue to maintain it when the code from Linden has conflicting changes? There's a reason there aren't any significant forks of big projects like Apache. The effort is too great, and the benefit is too small.
Someday, someone will make a fork of Second Life to build a new game, or a flight-simulator, or an educational tool, or abstract the features into a game-building toolkit, or embed it in a web browser. These are good reasons to fork. A disagreement over patch-submission procedures is not a good reason to fork.
Actually it's because Linden Lab is only offering the source as an archived drop every 2 weeks. We have the only source repository for people to collaborate around.
Did you ask Linden if they would consider creating a read-only public repository for the code before you created your own? They're not a faceless, evil corporation. They're a good group of people, who care about open source, and want to build a community around their codebase. The thing about communities is that they work together to improve their environment. If there's an obstacle to participation, talk about it in a kind and reasonable way. You'll make things better for everyone.
OpenSecondLife will be working with Linden Lab to approve contributors under an agreement that Linden Lab's legal department will accept.
Good. This is the best thing I've heard so far.
Did you ask Linden if they would consider creating a read-only public repository for the code before you created your own?
Yes. Please see https://wiki.secondlife.com/wiki/Version_control_repository
You misunderstand the fundamental nature of the public domain. Anything released under the public domain has no protection under copyright law. A public domain release of rights is not reversible, so the contributors will no longer own the rights in order to grant any kind of separate license to Linden. And given the legal complexity of maintaining a repository of mixed public domain and copyrighted code, I expect Linden would be unable to accept any patches released under the public domain.
Wait, what legal complexity? Put simply, anyone can take code in the public domain and slap it into their code; no special tracking is required, and no liability is incurred by doing so (assuming that the code is, in fact, truly in the public domain). (They don't even have to record the source of the code!)
A disagreement over patch-submission procedures is not a good reason to fork.
Tell that to ECGS and X.org.
As it stands, Linden Lab is chronically understaffed, and if all goes well, they won't have time to deal with all the patches coming their way. This means that they will become the bottleneck for open-source contributions. In reality, what will likely happen is we will maintain our own set of patches, regularly resync with upstream, and good / stable / useful features will eventually make their way back upstream.
You might have seen Rob's statement on the SLDEV mailing list that Linden Labs source code repository won't be coming for a minimum of two months, and that's an optimistic guess. I do realize Linden Labs is not a faceless evil corporation as I have been working with them for almost a year now as the lead developer of libsecondlife (http://www.libsecondlife.org/). If you know something that they don't about patch submission you should talk to Linden Labs directly as we've been collaborating with them each step along the way so far.
To answer your question about forking, you don't have to look as far off in to the distant future as a flight simulator client to see why it's inevitable, or in fact has already happened. There are lots of useful patches that the developer community wants in their client but no one else cares about and are unlikely to be merged in the official codebase. One is a readline-style support for the chat bar to scroll up and down through chat history and another is my Copy UUID pie menu item that is a helpful tool during development. The assumption that the codebases will become incompatible is a little hasty, if LL sticks to their original timeline opensecondlife.org will only be really relevant for another few months.
Wait, what legal complexity? Put simply, anyone can take code in the public domain and slap it into their code; no special tracking is required, and no liability is incurred by doing so (assuming that the code is, in fact, truly in the public domain). (They don't even have to record the source of the code!)
Indeed that's true. But forever after you include public domain code in your repository, some parts are protected under copyright law, and some aren't. Unless you carefully track which are which (a difficult task), you'll have a devil of a time proving that some particular piece of code is or isn't subject to copyright protections.
My hope is that opensecondlife.org won't become "irrelevant", but that the people and energy involved there will roll back into mainline Second Life development, similar to how Mozilla has a healthy community of developers who aren't Mozilla Corp employees. I'm glad to hear you're talking to Linden, please continue to do so. And be patient. Contrary to popular belief, growing a commercial product into an open source project actually absorbs more resources than it adds in the first year or two.
Allison,
Thanks once again for your thoughts; much of what you mention indeed touches on a subset of the issues through which we are working as the OpenSL project takes shape and the Second Life community evaluates the best way to transfer "ownership" of the client to the public domain. I've posted a more detailed explanation in an attempt to better define the need and evaluate the best way to meet that need.
Again, I do appreciate your feedback, and share some of your concerns; I certainly welcome any suggestions you or your readers may have on how best to enable content and interface developers and facilitate their efforts.
Christian
Hi Allison, so how did you get SL Viewer to compile on our Mac? I've been trying on my PowerBook G4 using gcc 3.3, xcode 2.4.1 and the lastest beta version 1.4.1.1, trying to follow the instructions on SL Developer Wiki, but a number of the modules won't compile, so can't get to even to compile the program. I'm not a c++ person, want to learn, hoping to do it through SL viewer, but hard when instructions don't help to get it compile.
That bug report is not it. I'm having issues with XMLRPC-epi, OpenJPEG, CURL, and Mozilla not building. I've posted my issues on https://wiki.secondlife.com/wiki/Talk:Compiling_the_viewer_%28Mac_OS_X%29 under my SL name, Mokelembembe Mokeev. Maybe I should go back to the version 1.3.x and see if I can get that to compile, if that works, then go from there.
That bug is not my problem. I'm having issues getting XMLRPC-epi, OpenJPEG, CURL, and Mozilla to build. I've listed my issues on https://wiki.secondlife.com/wiki/Talk:Compiling_the_viewer_%28Mac_OS_X%29 under my SL name Mokelembembe Mokeev. I'm going to go back and try to build Release (r56702) from 2007-Jan-12 and see if I can get that to compile.
Trying to get Release (r56702) from 2007-Jan-12, get to XML-EPI 0.51 to compile, get this error message (including a couple of lines before) during Make:
cd . \
&& CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
Making all in src
cd .. && automake --gnu src/Makefile
src/Makefile.am: required file `./depcomp' not found
make[1]: *** [Makefile.in] Error 1
make: *** [all-recursive] Error 1
Got 1.14.0.1 to build!!! :-) After learing can build the viewer by only downloading linden source that includes the third party precompiled binaries. Had to add a couple of directories and files but it built. Yeah! Now to try some tweaking and also go back to see if I can those third party libraries that wouldn't compile to compile. Go on the SL Dev mailing list, so hopefully can get some help there
I'm kind of giving up on SL. To much in the focus of marketeers which doesn't really add interesting people I would like to meet... :-(
Regarding "One is a readline-style support for the chat bar to scroll up and down through chat history ..."
I'd love that, and I bet a lot of folks would like it too, even if they don't realize it.
It would need to be done in such a way as to not affect established keyboard habits.
Same here, i got this error message:
cd . \
&& CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
Making all in src
cd .. && automake --gnu src/Makefile
src/Makefile.am: required file `./depcomp' not found
make[1]: *** [Makefile.in] Error 1
make: *** [all-recursive] Error 1
Post A Comment:
STAY CONNECTED
RECENT COMMENTS
- Meteko on Building Second Life: Same here, i got this e...
- SuezanneC Baskerville on Building Second Life: Regarding "One is a rea...
- Gave up on Second Life on Building Second Life: I'm kind of giving up o...
- Scott T. Norman on Building Second Life: Got 1.14.0.1 to build!!...
- Scott T. Norman on Building Second Life: Trying to get Release (...
- Scott T. Norman on Building Second Life: That bug is not my prob...
- Scott T. Norman on Building Second Life: That bug report is not ...
- Allison Randal on Building Second Life: I haven't tried to comp...
- Scott T. Norman on Building Second Life: Hi Allison, so how did ...
- christian on Building Second Life: Allison, Thanks once a...
RADAR TOPICS
christian [01.12.07 07:16 PM]
Allison,
To complement LL's wiki, OpenSecondLife.org has a public subversion repository available, as well as additional instructions on some of the intricacies associated with building under Visual Studio 2005.