Compiling your own Viewer

Back in September 2010 I wrote about the pain of compiling your own Viewer and of the efforts of my friends Mariana and Forestaurora to try to write tutorials on doing it. Fortunately, things have moved on enormously since then and now it is fairly easy to do a private build. A majority of the work is in setting up your build environment, and there are clear instructions on how to do this (I will provide links at the end). After encountering and solving a few “gotchas”, I have successfully built Firestorm v4.6.x under Windows 7. I thought it was worth noting down the “gotchas” I encountered, which is what this article is about.  If it helps just one other person in short-cutting the issues I have had, then this article will have been worth writing. These gotchas could just as easily apply to the Official Viewer, or any of the other Third Party Viewers; they are unlikely to be Firestorm-specific. So without further ado, here they are.

Python version

The first “gotcha” was that the build instructions said to install Python. The actual wording was “Version 2.7.1 works with the build scripts”, which is slightly misleading as I read that to mean that that v2.7.1 had been explicitly tested but anything greater than that would also be fine. This is not the case. I installed v3.3.4 which installs by default to c:\Python33 on Windows. When I got to the point of building FModEx, I got the following build error:

D:\projects\firestorm\3p-fmodex>autobuild build --all
Traceback (most recent call last):
File "D:\bin\autobuild\bin\autobuild", line 38, in <module>
from autobuild import autobuild_main
File "D:\bin\autobuild\autobuild\autobuild_main.py", line 36
print parser.format_help()
      ^
SyntaxError: invalid syntax

A friend suggested that I tried Python 2.7 as the instructions had said v2.7.1 had been tested, so I installed v2.7.6 (the current latest on the 2.7 series) and the problem went away. I have to say that I am surprised by the break of backward compatibility, so am calling this a “gotcha”. So, in summary: you must use v2.7 for it to work.

Cygwin

This is a minor one. I’m running the 64-bit version of Windows 7, and when I installed Cygwin I specified the install location as d:\cygwin and added d:\cygwin\bin to my path. I was therefore a little surprised to get various errors about being unable to find 'bash' and various other Cygwin components. I double checked the installed components, scratched my head a little, and then suddenly realised that Cygwin had actually decided to overrule me and install to d:\cygwin64 instead. Therefore my path wasn’t pointing to where Cygwin was actually installed (as it was pointing to where I had told it to install to, rather than where it had decided to install to). Once that was fixed the problem went away.

7Zip

Another build failure I encountered was autobuild not being able to find 7Zip. This isn’t mentioned in any of the build instructions. I have 7Zip installed on my PC but it is not in the path – adding it to the path cured this.
Note: It’s possible that I encountered this issue because I have 7Zip installed.

FModEx and KDU

Most of the libraries that are required by a Viewer are pulled in automatically by autobuild. However, FModEx and KDU both have to be built locally. FModEx is the library that the Viewers use to play sounds. If you don’t have this library linked in, your Viewer will behave as if you have muted all sounds. The build instructions detail how to build this library, but do not tell you how to link it in. I will shortly mention how. KDU (Kakadu) is a library that is to do with rendering JPEG2000 images. Unlike FModEx, the build instructions do not mention how to build this, but there is a mention that if you want to use it you must license it yourself and build it yourself. Currently a personal non-commerical license is US$250 which rules it out for me. Fortunately if you do not want to use KDU then the Viewer can use the OpenJPEG library instead which, although not as fast as KDU, is free. The trouble is that the predefined build configurations have a bit of an “all or nothing” approach. If you build with ReleaseFS then it tries to link both FModEx and KDU, and fails because KDU is missing. If you build with ReleaseFS_open then it uses neither and you are left with a muted Viewer. Fortunately there is a way round this, which is what this “gotcha” is all about (everything up to now has been background). You need to add the switch --fmodex to the end of the configuration command. Whilst you’re there you can also use --avx to turn on AVX optimisations. If you want to use LeapMotion then add --leapmotion (I don’t have one so didn’t bother). Thus my config and build commands become

set AUTOBUILD_CONFIG_FILE=my_autobuild.xml
autobuild configure -c ReleaseFS_open -- -DLL_TESTS:BOOL=FALSE -DFMOD:BOOL=TRUE --fmodex --avx
autobuild build -c ReleaseFS_open --no-configure

This builds an OpenSim-compatible Firestorm that uses OpenJPEG but also links in FModEx, giving me a Firestorm that connects fine to Second Life and has sound. Exactly what I want. The lack of KDU doesn’t make it noticeably slower for me, but I do have an extremely powerful PC so your mileage may vary.

Settings and cache

One slightly annoying aspect of switching between the installed Firestorm and the private build one, is that it seems to clear my cache. That means that every time I switch between them, I rezz as a cloud and have to wait ages for my inventory to load. I haven’t found a way round this yet, although I’m sure one exists. In the meantime it’s something to be aware of.

Summary

Having resolved all of the above I can now build Firestorm under Windows with no problems. Hopefully this article can be of some interest to others.

Update:

August 2015

The build system now uses Visual C++ 2013 and the Firestorm build instructions are fairly out of date right now. You will need to follow the instructions on the official Linden Lab page to set up your build environment, but after that the Firestorm ones are still relevant, although out of date.
In particular, the location of autobuild has changed and you do need the latest version in order to compile successfully.


Links and Further Reading

Get source and compile – Official Second Life Viewer build instructions
Firestorm Windows Builds – build instructions tailored for Windows builds
Compiling Firestorm Viewer – a top-level page for all platforms

Advertisements

6 thoughts on “Compiling your own Viewer

  1. What advantage would I gain with a personal build? Can I tweak options and remove limits in debug settings if I build my own? Can I completely remove features I don’t use? Will that “break” the build. If I remove features do I gain some performance? How do we make the custom tweaks? Are there tutorials available for Noobs?

    • The main advantage is being able to apply your own code changes. On my personal build, you don’t slump when you go AFK, don’t go AFK when minimised, and snapshots to disk are named with the date and time in the filename.

      To make changes, you need to be proficient in the C++ programming language. There are many tutorials around, but it is not a beginners programming language and the learning curve would be pretty steep.

      • Well that’s me out of the loop then unless there are people who do “requests” for a build with the specific features you want. Would that be matter of deleting code rather than “additions” in most cases? Is that easier?

      • To be honest, there would be no advantage in removing stuff. For a start, it would be hard for you to know what to remove without breaking something. And the end result wouldn’t give you any advantage as it would be compiled without Kakadu.
        Best bet would be to put a Feature Request in to the Firestorm team if there is a specific feature you want.

      • My request would be to remove features I don’t need actually. I’m guess that would be a performance gain since the V1 UI seems to be faster than V3 UI. If you remove anything to do with features that are using bandwidth would help (chat and any media or audio for example?).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s