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.
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.
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.
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.
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.
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