New viewer - standalone or not?

When you build an SL viewer, you have to decide whether you want to build in "standalone" mode or not. What does this mean? Well, this helpful link explains it:

"A standalone build of the viewer refers to building a viewer against the shared libraries that are installed on your system instead of using precompiled libraries provided by Linden Lab."

For our new viewer project, the ideal build would be a combination of the two, so we have some hacking to do! Why would it be a combination? For the following reasons:

• If a library exists as a system package, it saves us from building it ourselves, making the build quicker
• System packages are often newer than the library versions that Linden Labs ships, meaning more bugfixes and features if we use them
• Conversely, if a library does not exist as a system package, we must build against the version included in the source tree instead of failing with an error message. A non-root user cannot install a library as a system package, and if we only have one command to build the viewer it must do the build for the missing libraries too.

None of the viewers that I've seen so far support this kind of "mixed" mode, so we need to tweak the build system in order to pass the "I have a dream" test. However, it should hopefully be possible to do so without too much trouble.

Windows build needlessly complex too!

My good friend BeccaPet alerted me to an intriguing blog post by Forestaurora who documents her brave and ultimately successful fight to get Phoenix to build on Windows.

Yes, that's right, Microsoft Windows. By far the most popular platform for SL users.

I mean, you would expect that the Phoenix dev team would have ironed out all of the little niggles years ago for the Windows platform! But it seems poor Forestaurora even had to alter the C++ code to make it build.

The list of prerequisite steps looks frighteningly too long to me as well. I'm no Visual Studio expert, but in RL I have worked on a large VS based project where the build steps on a fresh developer's box would be similar to the "I have a dream" test:

1. Unpack prebuilt dependency libraries and headers in a certain place

2. Open the VS .sln file that's checked in to the source control system

3. Press the "Run" button. This causes the compile and link, and runs the program successfully.

Maybe this should be the Windows equivalent of the "I have a dream" test? Certainly the steps that Forestaurora went through can be simplified so that future developers don't get put off. I already know of one Windows developer who has been scared off - who knows what contributions they could have made to the viewer? Hopefully we can make a better viewer build experience for people!

Snowstorm failing the 'I have a dream' test

OK, so we've seen how the third party viewers fail at supporting 64-bit Linux, but how about Linden Labs themselves? Surely they're the ones to support a seven-year-old CPU architecture in millions of people's computers across the world? Depressingly, they are full of fail in this regard too.

For this test, I used the same environment as for the Phoenix and Imprudence tests (see earlier posts) - Ubuntu 10.04 x86_64 with the given list of extra packages installed. As for the viewer itself, I chose to use Snowstorm, Linden Labs' showcase bleeding-edge open source viewer project. After all, this would have the best chance of supporting modern Linux distros and a 64-bit CPU. Let's get the source!

Snowstorm is in a Mercurial repository, at the time of this test the tip was this commit:

changeset: 12269:d6f323402dd2
tag: tip
parent: 12267:3ecfc3800b83
parent: 12268:8ceebd3612f0
user: Tofu Linden
date: Sat Sep 18 11:18:13 2010 +0100
summary: merge storm-192

OK, let's try a non-standalone build. The command "./develop.py -m64" seems to configure the build correctly after downloading lots and lots of libraries. Looking good so far!

The build command "./develop.py -m64 build", however, chokes virtually immediately with the following error message:

In file included from /space/SecondLife/viewer-development/indra/llcommon/llthread.h:31,
from /space/SecondLife/viewer-development/indra/llimage/llimage.h:33,
from /space/SecondLife/viewer-development/indra/llimage/llimagej2c.h:30,
from /space/SecondLife/viewer-development/indra/llimagej2coj/llimagej2coj.h:30,
from /space/SecondLife/viewer-development/indra/llimagej2coj/llimagej2coj.cpp:28:
/space/SecondLife/viewer-development/indra/llcommon/llapr.h:46:29: error: apr_thread_proc.h: No such file or directory
/space/SecondLife/viewer-development/indra/llcommon/llapr.h:47:30: error: apr_thread_mutex.h: No such file or directory
/space/SecondLife/viewer-development/indra/llcommon/llapr.h:48:24: error: apr_getopt.h: No such file or directory
/space/SecondLife/viewer-development/indra/llcommon/llapr.h:49:24: error: apr_signal.h: No such file or directory
/space/SecondLife/viewer-development/indra/llcommon/llapr.h:50:24: error: apr_atomic.h: No such file or directory

It seems to be missing something to do with "apr", whatever that is, but I have no idea why the build system didn't pull it in with all the other libraries it just downloaded!

OK, let's try a standalone build. With this, the stench of fail doesn't take long to appear - merely the configure command "./develop.py -m64 --standalone" is enough to make the poor thing barf with this error:

CMake Error at cmake/GoogleBreakpad.cmake:5 (MESSAGE):
*TODO standalone support for google breakad is unimplemented
Call Stack (most recent call first):
llcommon/CMakeLists.txt:12 (include)

Well at least they're nice enough to say it's TODO, even if they spell "breakpad" wrong! Google breakpad is a crash reporter, so basically instead of just building with no crash reporting support they're stopping us building standalone at all. In what world is that a sensible decision?

Imprudence 1.3.0 RC2 failing the 'I have a dream' test

This time it's the turn of a popular "alternative" viewer, Imprudence, to take Mariana's "I have a dream" test to see whether it compiles out of the box.

Right from the very start, Imprudence seems to be going badly. The build instructions are on this webpage, and the immediate fail starts here: http://imprudenceviewer.org/wiki/How_to_compile#GCC_4.4

Quoting from that webpage: "GCC 4.4 isn't compatible with the version of boost in Imprudence... The solution is to install GCC 4.3..."

NO! No no no no no! The solution is never to downgrade your system's compiler! You fix your code, you don't break the compiler for everyone else on the system! Apart from being a blindingly stupid idea, this immediately fails the "non-root user" part of the test.

I won't copy the results of the non-standalone compile attempt here, as (predictably) it chokes on Imprudence's broken version of Boost just as the webpage said. However, we can try a standalone build.

In standalone mode, the command "./develop.py --standalone" successfully configures the build. The command "./develop.py --standalone build", however, gets 45% of the way through the build before choking with the following error:

/space/SecondLife/imprudence/linden/indra/newview/llviewerjoystick.h:39:30: error: ndofdev_external.h: No such file or directory

Oops, it appears to want some library for a joystick that isn't included with Ubuntu. The configure stage is too lame to notice it's not there, and the build itself is too lame to either build successfully with no joystick support or pull it in from the version shipped with the code. Big truckload of fail from the Imprudence team!

Phoenix 1.5.1 failing the 'I have a dream' test

This is the first of several posts where I show how the current crop of viewers fail the "I have a dream" test (see earlier post) for the x86_64 architecture. I chose x86_64 because it's been around for seven years (since the AMD Opteron in 2003) and nearly every desktop system newer than about 5 years old supports it, including my current and last desktop systems.

The lucky viewer in question this time is Phoenix, everyone's favourite Emerald replacement. Yay! Let's see how it fares, shall we?

Step 1 (Install OS): Ubuntu 10.04 for x86_64

Step 2 (extra packages):

sudo apt-get install g++ binutils make cmake flex bison\
libc6-dev libstdc++6 libx11-dev libxrender-dev libgl1-mesa-dev\
libglu1-mesa-dev zlib1g-dev libssl-dev libogg-dev libpng12-dev\
libdbus-glib-1-dev libgtk2.0-dev\
libopenal-dev libvorbis-dev libalut-dev libapr1-dev\
libaprutil1-dev libboost-dev \
libc-ares-dev libxmlrpc-epi-dev libopenjpeg-dev libjpeg62-dev\
libgtk2.0-dev libsdl1.2-dev \
libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev\
libnotify-dev\
libboost-date-time-dev\
libboost-filesystem-dev\
libboost-iostreams-dev\
libboost-program-options-dev\
libboost-python-dev\
libboost-regex-dev\
libboost-signals-dev\
libboost-thread-dev\
libboost-wave-dev\
libcurl4-gnutls-dev\
libtut-dev\
subversion\
scons\
libhunspell-dev\
libqt4-dev

Step 3 (get viewer source): Cloned Mercurial repository at http://hg.phoenixviewer.com/phoenix-sg/ from tag "release-1.5.1"

Step 4 (compile): In the "indra" directory, run command "./develop.py -m64 --standalone". This fails like this:

CMake Error at cmake/FindJsonCpp.cmake:49 (MESSAGE):
Could not find JSONCpp library
Call Stack (most recent call first):
cmake/JsonCpp.cmake:9 (include)
newview/CMakeLists.txt:15 (include)


CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LLQTWEBKIT_LIBRARY (ADVANCED)
linked by target "media_plugin_webkit" in directory /space/SecondLife/phoenix-1.5.1/indra/media_plugins/webkit

-- Configuring incomplete, errors occurred!
Cleaning 'viewer-linux-x86_64-release'
Error: the command 'cmake' exited with status 1

Alternatively, we can try building non-standalone. Command "./develop.py -m64" succeeds in configuring the build, the command "./develop.py -m64 build" (to build it) fails with the following error:

/space/SecondLife/phoenix-1.5.1/indra/cmake/cmake_dummy.cpp:1: error: CPU you selected does not support x86-64 instruction set
make[2]: *** [cmake/CMakeFiles/cmake.dir/cmake_dummy.cpp.o] Error 1
make[2]: Leaving directory `/space/SecondLife/phoenix-1.5.1/indra/viewer-linux-x86_64-release'
make[1]: *** [cmake/CMakeFiles/cmake.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

Oh dear, poor Phoenix! The non-standalone build fails because one of the build files sets the build architecture to "i686", which is obviously wrong.

The standalone build is more interesting - it fails because it expects libjsoncpp and llqtwebkit to be installed as system packages. These two have to be done manually beforehand to even get Phoenix to compile, but this violates step 2 of the "I have a dream" test as the root user has to install non-system packages to the /usr/local directory.

My dream hasn't come true yet, but I know it will someday!

I have a dream

I have a dream, that can be summed up in one line: "A non-admin user should be able to compile a working Second Life viewer with one command."

For Linux, this means the following workflow should be possible:

1. Install Linux from a CD or DVD

2. The root user installs a certain set of system packages with something like apt-get. Only system-provided packages, not using some random person on the net's repository.

3. A non-root user downloads the source code for a viewer, most probably by cloning a version control repository somewhere

4. The same non-root user issues one single command. This command successfully builds a fully functional Second Life viewer.

As you may expect, none of the viewers I've tried so far pass this test on my system, which is Ubuntu 10.04 x86_64. Therefore, if I can get motivated enough, I will fork one of the existing viewers and make it possible. Obviously I will concentrate on x86_64 Linux as that's what I know, but it would be great if experts on Windows or Mac systems could help make it possible on those platforms too.

I envisage the new viewer project as primarily a viewer for developers, for people who want to compile their own and get stuck in adding features or fixing bugs. I believe the current difficulty of compiling viewers puts off would-be contributors, so we must work to change it!

Something is rotten in the state of Second Life

Hi, I'm Mariana Latynina and I exist as a character in Second Life. Of course I am also a real-life person behind the character - but, to quote Leslie Neilsen, "that's not important right now."

This blog is to organise my thoughts on how to improve Second Life. It would be nice if other people read it, but I'm not vain enough to think that many people will care! I will be talking about the things that bug me in SL which I think can be improved, and the first one of these is Viewer 2.

As anyone who uses SL regularly will know, Viewer 2's interface is one great big WTF-fest of weirdness. The "Communicate" window from the 1.x series viewers was a nice little thing that looked and behaved like an IRC client, but Viewer 2 threw out all of that for no readily apparent reason and has made chat a frustrating experience. Lots of things that used to be separate windows, like profiles and inventory, are now stuffed into a "sidebar" thing which basically means you can't open someone's profile and your inventory at the same time! It's all a gigantic mess.

My first reaction on encountering such an abomination was to try to rewrite it - in RL I'm a C++ programmer so I thought that it shouldn't be too hard.

Boy was I wrong!

I run 64-bit Linux, which seems to be woefully neglected by the Second Life developers. I've tried and failed to compile most of the viewers I can lay my hands on - the only one I've had some success with is Phoenix. I managed to coax that into compiling something, but the resulting viewer had incorrect fonts, showed me as being in no groups (which is wrong) and it crashed every time I tried to teleport anywhere. It did run, though!

I do have plans to improve both the compile situation and V2's interface, but I'll save that for further posts.