Posted in Developer Zone, Programming, Second Life, Viewers

Compiling the Firestorm Viewer

Last updated 23-Jul-2021


Extended instructions, tips, and ‘gotchas’ on how to compile and build Firestorm, a third-party Open Source viewer for use with Second Life by Linden Lab.

First published in February 2014, and regularly updated ever since.

NOTE: This article assumes that you are a competent software developer who is comfortable with C++ build environments and command consoles. Most people will have no need to build their own version of Firestorm from the source code.


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.

After encountering and solving a few “gotchas”, I have successfully built Firestorm under Windows 7 (64-bit), Windows 10,  and also under Ubuntu 16.04 LTS 64-bit, Ubuntu 18.04 LTS, and Ubuntu 20.04 LTS.

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.

Although this article is primarily about compiling Firestorm, it could prove useful for other third-party viewers too, although your mileage may vary.

Update: It’s worth noting that I originally wrote this page whilst the Firestorm build instructions were out of date and full of inaccuracies and omissions, and during that time this page was quite useful. However, now that they have been brought up to date my page is possibly a little less useful for Windows builds as the instructions are now very good and straightforward, however there is still some extra useful information here and I go into more detail on some things than the official build instructions do.

 


Setting up the build environment

This covers the sections in the Firestorm build instructions to do with setting up the build environment.

Setting up your build environment is something you only need to do once. I will cover Windows and then Linux.

Windows

The follow section applies only to Windows builds.

The Firestorm build instructions are currently very accurate and straightforward, and currently there are not many gotchas.

The notes in this section will take you up to the “Prepare third party libraries” part of the Firestorm build instructions. You should then stop, and read on below here before continuing.

Specifically, you should not do the bit on FModStudio until you have read my notes further down.

C++ Compiler

The build system now uses Microsoft Visual Studio 2017 (VC15), and the Firestorm build instructions have been updated to reflect this.

Prior to the switch to Visual Studio 2017, it was possible to have multiple versions of Visual Studio installed, and I used to use VS2013 for compilation and VS2019 as the IDE. However, this seems to no longer work and autobuild gets confused if you have more than one version of Visual Studio installed. In the end I had to uninstall all versions of Visual Studio apart from VS2017.

It is absolutely fine to use the Community Edition of Visual Studio 2017, since it specifically and explicitly allows you to use it free of charge for Open Source projects. It’s not immediately obvious where to get it though, and requires a little digging around the Microsoft website, but it is currently available from Microsoft [link] (note: requires creating a free account) or from TechSpot (unverified source).

pip

The build instructions say to download get-pip.py from https://bootstrap.pypa.io/get-pip.py but that link is to a version that requires Python3 and we want the Python2 version.

Instead you should download it from https://bootstrap.pypa.io/2.7/get-pip.py as that is the version for Python 2.7 which is the one we want.

Cygwin

Do not install the GCC compiler, or make, or CMake. If you do then I have found that Firestorm won’t compile because it picks up Cygwin’s version of CMake rather than the one it needs, and they were not compatible with each other at the original time of writing. I don’t know if this has since been fixed.

 

Linux (Ubuntu)

There are several versions of the build instructions for compiling Firestorm under Linux. They are all subtly different, and look like a bit of a maintenance nightmare – someone isn’t keeping them in step.

I used these build instructions and, as recommended, I initially used Ubuntu 16.04 LTS (64-bit) running as a Virtual Machine (VM) under VirtualBox.

I subsequently also did successful builds with Ubuntu 18.04 LTS and 20.04 LTS.

The following headings refer to the equivalent headings in the Firestorm build instructions for Linux…

Create your source tree
No notes on this. You can just do this.

Install Required Libraries
In this section, it mentions “libatspi2.0-dev/xenial” which is fine if you are building on 16.04 Xenial but for anything else will barf. Just remove the “/xenial” bit and then all is good.

Install Required Tools
Omit “python-pip” as this will install an incorrect version of pip that does not have support for Python 2.7 and instead substitute it for “python” (so that python gets installed)

NOTE: Make sure you have updated your repositories in Synaptic (or equivalent) to include main, universe, restricted, multiverse, and (importantly) ‘Canonical Partners’. Under 20.04 I experienced a 404 with http://security.ubuntu.com/ubuntu which appeared to be fixed with that, although it could have been transient and unrelated.

Now we download and install the correct version of pip

cd ~/src
wget https://bootstrap.pypa.io/pip/2.7/get-pip.py
sudo -H python get-pip.py

CMake
The Firestorm build instructions say to build CMake but this takes ages. Instead you could get a pre-build binary by following the instructions at https://apt.kitware.com for 16.04 or 18.04, and for 20.04 a simple “sudo apt install cmake” will suffice as this gives you a CMake that is plenty new enough.

Git
You can now carry on through to”Git“. Don’t be tempted to do “Git Alternative” instead, because under 16.04 that installs v2.7.4 which doesn’t have the “exclude” command.

However, building git from source is rather a palaver. So as an alternative you could consider the following:

sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get install git

This installs the latest git from the git-core PPA on launchpad.

Install Autobuild
You can do this section “as is” although it’s not necessary to upgrade pip as we only just installed it.

Download the Source Code
You can go ahead and do this, but before cloning FModStudio read on below, and then we’ll continue further on down.

 


Building the libraries

This applies to both Windows and Linux.

Most of the libraries that are required by a Viewer are pulled in automatically by autobuild, with the exception of FModStudio and KDU.

FModStudio 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 FModStudio, the build instructions do not say 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-commercial license is US$250 which rules it out for me. Fortunately you do not need it as without it the Viewer just uses 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 FMod 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, and also lacking Havok support. I’ll explain how to resolve this issue later on.

KDU

As mentioned above, it is not feasible to build KDU but it can be omitted.

FModStudio

FModStudio is supported in Firestorm v5.1.1 onwards. Older versions used FModEx, and I have now removed my notes on that (although you may still be able to find it on the Wayback Machine).

You will need to go to the FMod website and login (you’ll need to create an account if you don’t already have one) and then you can download FModStudio from the download area. Be sure to download the FMOD Engine (a.k.a. the FMOD Studio API), not the FMOD Studio Tool.

Select the appropriate version from the droplist, and download the version appropriate for your operating system. For Windows, download the Windows version (not the Windows 10 UWP version).

Copy it to the 3p-fmodstudio directory that was created when you were following the build instructions.

Edit the file build-cmd.sh and change the 3rd line from

FMOD_DOWNLOAD_BASE="http://192.168.1.115/dev/pkg/"

to

FMOD_DOWNLOAD_BASE="http://localhost/dev/pkg/"

This is very important, as  otherwise the script will try to download the package from the internet, and will fail (possibly with  “curl: (7) Failed to connect to 192.168.1.115” or “curl: (28) Connection timed out after 300305 milliseconds“, followed by “ERROR: building configuration“).

The Windows build instructions, as they currently stand at the time of writing, don’t result in a 64-bit version of FModStudio, and cause a build error when building the 64-bit Windows version of Firestorm, so I would suggest adding the -A 64 build option as follows:

autobuild build -A 64 --all
autobuild package -A 64

As mentioned in the build instructions, note down the “wrote” and “md5” output values as you will need them later.

 


Build parameters

I mentioned earlier on that the predefined build parameters are rather “all or nothing”. But it’s easy to work round this.

Since there is no build parameter for “do not use KDU” we compile with the ReleaseFS_open target (since this does not include KDU) and then use the build parameters to add back in what we want.

First we want to include FModStudio in order to get sound, so we include the switch --fmodstudio

Then, because doing an OpenSim build disables the Havok physics engine, we add --no-opensim to fix that.

For 64-bit builds we add -A 64

Finally, the build system lets you enable Advanced Vector Extensions (AVX), an explanation of which is beyond the scope of this article.

To enable AVX you add --avx to the configure command or for AVX2 you add --avx2 instead. The build will barf if you try to use both.

CAUTION:
Choose carefully whether or not to enable AVX or AVX2, because if you run the resulting build on a CPU that does not support it then it will crash on startup.

 


Performing a build

Windows

    1. Open a command window in the location of your source folder.Note: A standard Windows command prompt, not the VS2017 command prompt.
    2. Set up the VC15 build environment for 64-bit compilation, which I do with a batch file that executes the following commands
      pushd "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\"
      call vcvarsall amd64
      popd

      Note: This assumes that Visual Studio is installed on your c: drive. If you have it elsewhere then adjust as necessary. Also, the above commands must be executed in a batch file and not from the command line!

    3. Update autobuild.xml (or my_autobuild.xml if you are doing that) with the fmodstudio information.
      Note: You only need to do this the first time you do a build, or if you revert the file.
      (I use a batch file for this, which I show below).

      autobuild installables edit fmodstudio platform=windows64 hash=md5 url=file://wrote

      The values of md5 and wrote are the values output when you built FModStudio.

    4. Ensure that the AUTOBUILD_VSVER and AUTOBUILD_VARIABLES_FILE environment variables are set (this is a new requirement for v5.1.1 onwards)
    5. Execute the following command
      autobuild build -A 64 -c ReleaseFS_open -- --chan MY_CHANNEL --package --fmodstudio --no-opensim -DFS_UPGRADECODES='GUID1,GUID2' -DLL_TESTS:BOOL=FALSE

      (add in any other flags like --avx etc. that you wish, but read my caution on the use of --avx that I mentioned earlier)

      MY_CHANNEL is the name of your private build, eg. AwesomeSauce, which would result in a version of Firestorm that identifies itself as “Firestorm-AwesomeSauce”. If you omit this, it will use the name of your computer, prefixed by “private-“.
      Do not use spaces or punctuation!

      GUID1 and GUID2 are generated by, for example, the Visual Studio GUID Generator. Make sure to always use the same GUIDs per channel. They identify the installation for upgrades and installation.

      GUIDs should be in registry format, but without the curly braces, eg. FC4F6A13-04BF-4613-983A-0E6864FF44B0

      Note: You should use different GUIDs for GUID1 and GUID2

This should then build a 64-bit version of Firestorm for Windows that has sound.

You can either run the resulting executable directly for testing purposes, or else run the installer in order to install it properly.

NOTE:
I have a few batch files that I use, which make things more convenient for me.

Firstly I have a batch file that creates my_autobuild.xml for me.

update_autobuild.bat

@echo off
echo Copying autobuild.xml to my_autobuild.xml
copy autobuild.xml my_autobuild.xml /Y 
set AUTOBUILD_CONFIG_FILE=my_autobuild.xml
echo.
echo Updating FModStudio info...
echo.
setlocal EnableDelayedExpansion
pushd ..\3p-fmodstudio\
set "FMODSTUDIO_LOCATION=%CD%"
popd
set FMODSTUDIO_PLATFORM=windows64
set FMODSTUDIO_HASH=6a9c0a72224e6f332925cb359ecdf898
set FMODSTUDIO_FILE=fmodstudio-2.01.08-windows64-210650145.tar.bz2
set "FMODSTUDIO_FILENAME=!%FMODSTUDIO_LOCATION%\%FMODSTUDIO_FILE%!"
echo Location: %FMODSTUDIO_LOCATION%
echo Platform: %FMODSTUDIO_PLATFORM%
echo Hash:     %FMODSTUDIO_HASH%
echo File:     %FMODSTUDIO_FILE%
autobuild installables edit fmodstudio platform=%FMODSTUDIO_PLATFORM% hash=%FMODSTUDIO_HASH% url=file:///%FMODSTUDIO_LOCATION%\%FMODSTUDIO_FILE%
endlocal

That copies the file, and then updates it with my FModStudio information that I mentioned earlier.

Then I have a batch file that does the configure step (I actually have several of these, that build with AVX, without AVX, and build ‘Release with debug info’ for debugging).

config_ReleaseFS_open_64-bit_NoAVX.bat

@echo off
set AUTOBUILD_CONFIG_FILE=my_autobuild.xml
call autobuild configure -A 64 -v -c ReleaseFS_open -- --chan Beccapet --package --fmodstudio --no-opensim -DFS_UPGRADECODES='********-****-****-****-************,********-****-****-****-************' -DLL_TESTS:BOOL=FALSE

(Note: my GUIDs have been obfuscated with ‘*’ characters. Obviously you would substitute this for your own GUIDs)

And finally a batch file that does the actual build. Doing it this way slightly speeds up doing iterative compilation as it allows you to cut out the configuration step when doing subsequent builds.

build_ReleaseFS_open_64-bit.bat

@echo off
set AUTOBUILD_CONFIG_FILE=my_autobuild.xml
call autobuild build -A 64 -v -c ReleaseFS_open --no-configure --verbose

Linux

  1. Open a terminal window in the location of your source directory
  2. Update autobuild.xml (or my_autobuild.xml if you are doing that) with the fmodstudio information.Note: You only need to do this the first time you do a build, or if you revert the file.
    autobuild installables edit fmodstudio platform=linux64 hash=md5 url=file:///wrote

    The values of md5 and wrote are the values output when you built FModStudio.

    So for example

    autobuild installables edit fmodstudio platform=linux64 hash=b304c25772ddfb546d750e765d503e6f url=file:////home/becca/src/3p-fmodstudio/fmodstudio-2.02.01-linux64-212001931.tar.bz2

    (Note the four slashes. The first three are for file:/// and then the fourth is the start of the path)

    Note: You need to specify an absolute path; relative paths don’t seem to work

  3. Ensure that the autobuild variables are exported
    export AUTOBUILD_VARIABLES_FILE=$HOME/src/fs-build-variables/variables
  4. Execute the following commands
    autobuild configure -A 64 -v -c ReleaseFS_open -- --chan="MY_CHANNEL" --package --fmodstudio --no-opensim -DLL_TESTS:BOOL=FALSE
    autobuild build -A 64 -v -c ReleaseFS_open --no-configure --verbose
    

    MY_CHANNEL is the name of your private build, eg. AwesomeSauce, which would result in a version of Firestorm that identifies itself as “Firestorm-AwesomeSauce”. If you omit this, it will use the name of your computer, prefixed by “private-“.
    Do not use spaces or punctuation!

This should then build a 64-bit version of Firestorm for Linux that has sound and targets Second Life (but not OpenSim).

As with the Windows version above, I have several shell scripts that speed things up for me.

update_autobuild.sh

#!/usr/bin/env bash
cp -f autobuild.xml my_autobuild.xml
export AUTOBUILD_CONFIG_FILE=my_autobuild.xml
autobuild installables edit fmodstudio platform=linux64 hash=0e8842ec2cf693fe023050d0b0441bd1 url=file:////home/becca/src/3p-fmodstudio/fmodstudio-2.02.01-linux64-212010127.tar.bz2

 

config_ReleaseFS_open_64-bit_NoAVX.sh

#!/usr/bin/env bash
export AUTOBUILD_VARIABLES_FILE=$HOME/src/fs-build-variables/variables
export AUTOBUILD_CONFIG_FILE=my_autobuild.xml
autobuild configure -A 64 -v -c ReleaseFS_open -- --chan Beccapet --package --fmodstudio --no-opensim -DLL_TESTS:BOOL=FALSE

 

build_ReleaseFS_open_64-bit.sh

#!/usr/bin/env bash
export AUTOBUILD_VARIABLES_FILE=$HOME/src/fs-build-variables/variables
export AUTOBUILD_CONFIG_FILE=my_autobuild.xml
autobuild build -A 64 -v -c ReleaseFS_open --no-configure --verbose

 


Building the release viewer instead

All of the above instructions are for building the latest “bleeding edge” developer code from the trunk of the repository. However, if you want to play it safe and build the latest release branch, then it is possible to do so.

Under Mercurial, you needed a different URL but since the move to git, the release branch is an actual branch so just switch your local repo to that.


 

Summary

My build instructions result in a private build of Firestorm for Second Life that uses OpenJPEG but also links in FModStudio, giving 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, although your mileage may vary.

Although the above looks a little daunting, most of the work is in setting up your build environment, and it’s not as bad as it looks.

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.

Anyway, I hope that this post has been useful to someone.

 


Links and Further Reading

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

32 thoughts on “Compiling the Firestorm 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?

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

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

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

          1. 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?).

          2. You’d probably need to take that up with one of the Third Party Viewer teams such as Firestorm, Kokua, Niram, etc.

  2. Hello Becca, just wanted to let you know how to go about grabbing FMOD Ex for windows (Or any platform, really). All you have to do is sign up on fmod.com and contact support at support@fmod.com asking for access to the FMOD Ex downloads. They will ask you what you want to use it for, or you can blatantly specify in your request email as I did. They got back to me within a few days. You can then find your downloads at https://fmod.com/download under the “FMOD Ex” tab, category “FMOD Ex API”. Hope this helps!

      1. I have a question myself, now. Maybe you can help place me in the right direction since I’m not entirely a buff in bash files and google it is so ambiguous I can’t help myself. I’m autobuilding fmod right now, and so far I’ve gotten it to work right up to the very last line of build-cmd.sh , which is “pass”. Cygwin has no installable package named “pass”, there is no “pass.exe” in cygwin’s bin folder, and google has no idea what it is either. Running autobuild package doesn’t work because autobuild-package.xml is missing at this point, so I assume “pass” needs to complete. Any idea what this line accomplishes or how to fix it? Thanks.

        1. I didn’t use Cygwin’s build environment. I suspect you have installed the full development tools of Cygwin and you are picking up the Cygwin version of cmake and autobuild, rather than the Linden Labs’ / Phoenix Firestorm one. I mentioned this as a “gotcha” in the Cygwin section.

          If it’s not that then I’m afraid I don’t know. 🙁

      2. I’m using LL’s autobuild. Are you saying there’s a version of it for firestorm instead? Cygwin is not conflicting as far as I’m aware, just that pass is not a command that exists on my system. Maybe I can just rewrite it to accomplish the same thing without pass. Or rename the files myself.

      3. No, I don’t think there is a specific version of autobuild from Firestorm – I’m pretty sure it uses the LL version. It does sound like it is picking up something it should not though. I didn’t experience the issue that you are having and I don’t know how to resolve it I’m afraid. 🙁

      4. After about 11 hours of hardships and torment, I’ve finally gotten a complete build. I will admit most of my problems came from a minor discrepancy between LL’s guide and Firestorm’s. It seems LL uses their own autobuild here https://bitbucket.org/lindenlab/autobuild-1.1 (or https://bitbucket.org/lindenlab/autobuild-1.0) where as firestorm (and your guide) works with https://bitbucket.org/NickyD/autobuild-1.0 . Note that only NickyD’s autobuild has -m64 as an argument. The rest have -A 64 which will not compile firestorm correctly. Possibly my fault, but just writing it here in case anyone has similar issues. Thanks to your guide for helping me along the way!

      5. I’ve updated the article with the new info in these comments – specifically on getting the FModEx libraries and also on the caveat about autobuild. Thank you so much for taking the time to share – I really appreciate it. ♥

  3. Hi beccapet, I’ve been following your guide, thanks a lot! I’m having a python issue though after running autobuild configure -c ReleaseFS_open which will configure Firestorm to be built with all defaults and without third party libraries according to the https://wiki.phoenixviewer.com/fs_compiling_firestorm_windows guide, not sure if this text area is appropriate for this python error log format:
    Warning: no –id argument or AUTOBUILD_BUILD_ID environment variable specified;
    using a value from the UTC date and time (183410640), which may not be uniqu
    e
    ‘bash’ ‘../scripts/configure_firestorm.sh’ ‘–config’ ‘–version’ ‘–opensim’ ‘
    –version’ ‘–platform win32’ ‘–chan’ ‘MyViewer’ ‘-DLL_TESTS:BOOL=FALSE’
    Traceback (most recent call last):
    File “c:\python27\lib\runpy.py”, line 174, in _run_module_as_main
    main“, fname, loader, pkg_name)
    File “c:\python27\lib\runpy.py”, line 72, in _run_code
    exec code in run_globals
    File “C:\Python27\Scripts\autobuild.exe__main__.py”, line 9, in
    File “c:\python27\lib\site-packages\autobuild\autobuild_main.py”, line 263, in
    main
    sys.exit(Autobuild().main(sys.argv[1:]))
    File “c:\python27\lib\site-packages\autobuild\autobuild_main.py”, line 250, in
    main
    tool_to_run.run(args)
    File “c:\python27\lib\site-packages\autobuild\autobuild_tool_configure.py”, li
    ne 105, in run
    environment=environment)
    File “c:\python27\lib\site-packages\autobuild\autobuild_tool_configure.py”, li
    ne 158, in _configure_a_configuration
    return configure_executable(extra_arguments, environment=environment)
    File “c:\python27\lib\site-packages\autobuild\executable.py”, line 104, in c
    all

    return subprocess.call(commandlist, env=environment)
    File “c:\python27\lib\subprocess.py”, line 168, in call
    return Popen(*popenargs, **kwargs).wait()
    File “c:\python27\lib\subprocess.py”, line 390, in __init__
    errread, errwrite)
    File “c:\python27\lib\subprocess.py”, line 640, in _execute_child
    startupinfo)
    WindowsError: [Error 2] The system cannot find the file specified

    I’m using Windows 7 64 bit, and that free Community edition of VS2013 also I’m using python 2.7.14 and just to make sure I checked python version in Command Prompt by typing: python –version and that shows Python 2.7.14 it’s all fine but why I’m getting python issues?

    1. Updating…. I could fix that by running commands through the Cygwin64 terminal instead of Command Prompt windows, I got same error related to python though but that came up near the end of the process compilation, so if someone is having same issues try to compile on Cygwin64 terminal! Thanks.

    2. Hmmm. That’s odd. I don’t get that issue. Have you set up the build environment correctly as per the FS build instructions?
      Also, have you upgraded your autobuild to the LL version? NickyD’s version is no longer compatible.

  4. Hi beccapet, I figured out that the way to fix all those issues is by running the Cygwin64 terminal from the C:\cygwin64\bin\mintty directory I was running by the C:\cygwin64\Cygwin so I still got that python issues, anyway runnin by the mintty file I could get a successfully build! Everything working fine, no error logs, but when I used the http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/ repository I couldn’t run my build after finished I got an error related to settings xml etc,. but using http://hg.phoenixviewer.com/phoenix-firestorm-release/ repository instead so that works just fine for me, and my autobuild version is 1.1.7 I guess it’s up to date isn’t it?

    1. I’m afraid I don’t know what you are doing different then. I’ve got this to compile fine on a clean install of Win7 Pro by just following the build instructions, so you must have missed something.

      1. Hi beccapet, I will ask you something which is not related to this topic. I’ve been searching for a chatbot lsl script but I couldn’t find a good one, by searching on google I just find Racter script and others based on notecards which is deprecated. Long time ago I had a chatbot script that was based on machine learning which is pretty good, that was basically 3 scripts, 1 for the main engine and the rest as memory extensions, you know where to find something like that? Perhaps you have something similar to share?

  5. Hi beccapet, third party libraries such as kdu, fmodex, fmodstudio are preset in the autobuild.xml right? So I wonder how to set new ones, either through autobuild.xml or VS2013, is it possible? I tried some c++ external libraries by importing dependencies to VS2013 Firestorm.sln project, but it failed to compile, you have a tutorial for this?

    1. Hi. I have actually done this for my private build, but did it using the CMake files.
      Ultimately I would like to work out how to do it with autobuild.xml which is why I have never blogged about it.

      1. Thank you beccapet, using CMake files it seems a workaround for me, even though I’m not familiar with CMake but I guess it has something to do with CMakeLists.txt, by looking into \firestorm\phoenix-firestorm-lgpl there’re a lot of CMakeLists.txt though, which one should I edit? Is the following commands a proper use for it: INCLUDE_DIRECTORIES for header location and LINK_DIRECTORIES + TARGET_LINK_LIBRARIES for libraries? How did you manage to do such a thing?

  6. Hi. When build fmodstudio show this error: “”cp -dR –preserve=mode,timestamps api/core/lib/x64/fmodL_vc.lib /cygdrive/c/firestorm/3p-fmodstudio/stage/lib/debug
    cp: cannot stat ‘api/core/lib/x64/fmodL_vc.lib’: No such file or directory””. Can you help me?

    1. Hi arturo. Sorry for the slow reply.

      Hmmm, that’s an odd one. It looks like something isn’t configured correctly but I’m afraid I don’t know what. Sorry I can’t be more helpful. 🙁

      1. Do not worry, I already solved the problem. The guide was very useful for me. Thank you!

        I would like that the viewer will not have the name of Firestorm but rather a custom name. How could I do it?

  7. I’ve previously built Firestorm on Ubuntu 16.04 LTS, and made some improvements in the region crossing area. Now I’m on Ubuntu 18.04 LTS, and your comments above suggest that there’s no version of GCC which both works under 18.04 LTS and will compile Firestorm. (The PPA of obsolete toolchains agrees: https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test)

    This (https://vcs.firestormviewer.org/phoenix-firestorm-lgpl/files/5e2050564bd3730f0ce7843860afdb25da3d2346/README_BUILD_FIRESTORM_LINUX.txt) says to use GCC 4.9.

    GCC 4.8, though, is a standard package for Ubuntu 18.04 LTS. That’s what I used to build Firestorm two years ago on 16.04 LTS. Will that work?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.