Posted in Developer Zone, Programming, Second Life, Viewers

Compiling the Firestorm Viewer


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.
Last updated 19-Jul-2019.

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 and also under Ubuntu 16.04 LTS 64-bit and Ubuntu 17.04 64-bit.

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

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.

You can follow the Firestorm build instructions now that they have been updated, but it may be useful to refer back to the instructions on the official Linden Lab page too.

C++ Compiler

The build system uses Microsoft Visual Studio 2013 (VC12) and the Firestorm build instructions have been recently updated to reflect this.

You can use the IDE of Visual Studio 2015 (VC14) but you must not let it upgrade everything to the VC14 toolset or it won’t compile. However, VS2015 seems to be clever enough to be able to compile using the VC12 toolset (although since I have both installed, I don’t know if it’s just calling VS2013).

Note: The free Community editions of VS2013 and VS2015 work just fine – you don’t need a full paid-for version. The license for the Community editions specifically allows use for contribution to Open Source projects.

Autobuild

As of Firestorm 5.1.1 (following the merge of Linden Labs’ project Alex Ivy), Firestorm now uses Linden Labs’ version of autobuild. Previous versions used NickyD’s version of autobuild which is incompatible.

If you previously used NickyD’s version, you must force an upgrade with the command

pip install hg+http://bitbucket.org/lindenlab/autobuild-1.1#egg=autobuild --upgrade

(ie. append --upgrade to the end of the install command).

CAUTION: Once you do this, you will no longer be able to build versions of Firestorm before the merge of Alex Ivy (so v5.0.x and before). I’ll mention solutions to this later.

If you are building an older version of Firestorm, pre Alex Ivy, and need the instructions for installing NickyD’s version of Autobuild, then they are as follows:

In a command prompt, do

hg clone https://bitbucket.org/NickyD/autobuild-1.0/ \autobuild

Modify your path after cloning to include the \autobuild\bin directory.
Also, add an environment variable named AUTOBUILD_VSVER and set the value to 120

Python version

The build instructions say to install Python. The actual wording is “Version 2.7.1 works with the build scripts”, which is slightly misleading if you are not aware that Python 3 is not backwardly compatible with Python 2

So, make sure you install Python 2 (currently v2.7.15) not Python 3.

Cygwin

This is a minor gotcha. 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 but was instead pointing to where I had told it to install to. Once that was fixed the problem went away.

Note: Do not install the GCC compiler or make / 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 are not compatible with each other.

7Zip

I encountered an error saying that autobuild was not 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. When I set up a build environment on a clean machine that didn’t have 7Zip, I did not experience this issue.

Linux (Ubuntu)

NOTE: These instructions are for building versions of Firestorm prior to the merge of Linden Labs’ project Alex Ivy. As such they are now out of date and you cannot build the latest development branch of Firestorm with them. The official Firestorm instructions say that it is currently not possible and that they are working on it.

The following has been tested with Ubuntu 16.04 LTS (64-bit) and Ubuntu 17.04 (64-bit), using the Firestorm 5.0.11 codebase. As mentioned above, they will not currently work with the latest code.

The only gotcha here is that 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 the build instructions specifically for Ubuntu 16.04 64-bit, and I followed the build instructions to the letter. The only erroneous information in the instructions is occasionally they omit a “sudo” when it is needed.

It’s interesting to note that these instructions currently mandate gcc-4.7, however another version says gcc-4.8 and another says gcc-4.9.

I used a fresh install of Ubuntu 16.04 LTS running as a Virtual Machine (VM) under VirtualBox in order to verify the procedure, and it compiled without a problem with the vanilla build command in the instructions with gcc-4.7, as recommended.

I repeated the procedure with a VM of Ubuntu 17.04 and gcc-4.7, with the same results.

After installing gcc-4.9 and making it the default compiler with Ubuntu 17.04, I was not able to get a successful build. Trying gcc-4.8 was also unsuccessful. Downgrading to gcc-4.7 again then succeeded again.

Therefore I would conclude that you must use gcc-4.7, and not gcc-4.8 or above.

I would also conclude that Ubuntu 17.04 is fine to use and you are not limited to Ubuntu 16.04 LTS.

Update: I also tried this with Ubuntu 17.10 and can report that currently there is no g++-4.7 package available for this release, which means you cannot build Firestorm under 17.10 (or later) and should stick with 17.04 or 16.04 LTS for now.


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 FMod and KDU.

FMod (either FModEx or 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 Windows build instructions detail how to build this library (and are also applicable to Linux builds), 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 FMod, 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-commerical 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.

It’s not immediately clear from the build instructions what you are meant to do about this, but the solution is simply to add the switch --fmodex (for FModEx) or --fmodstudio (for FModStudio) to the end of the configuration command.
Whilst you’re there you can also add --avx to turn on AVX optimisations for both Windows and Linux builds.
For Windows builds you can add --avx2 to turn on AVX2 optimisations.

CAUTION: Use --avx and/or --avx2 with extreme caution under Windows. I’ve observed that on a friend’s twin Xeon workstation this caused the resulting build to crash on startup due to an Illegal Instruction in std::numeric_limits::quiet_NaN() which was resolved by omitting them. However I experienced no such issues on my single Intel i7 desktop.

KDU

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

FModStudio

FModStudio is the preferred FMod library to use as it is newer. It’s supported in Firestorm v5.1.1 onwards.

To build FModStudio, follow the instructions in the Firestorm build instructions for Windows.

You only need to do this once, as FModStudio rarely changes.

There is a bit of a problem, however; fmodstudio can no longer be downloaded without a login, so the build script instead tries to download it from a local IP address which is not accessible over the internet.
The script will fail to download the package, and then terminate with failure (possibly “curl: (7) Failed to connect to 192.168.1.115” or “curl: (28) Connection timed out after 300305 milliseconds“, followed by “ERROR: building configuration“). Either way it doesn’t work.

You must therefore get the libraries yourself.

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

At of the time of writing, the version you need is 2.00.01 which you can select from the droplist, although if you want to use a later version (if available) then this is easy to do as mentioned in the build instructions.

Download the package appropriate for your targeted operating system. The easiest thing to do is to place it in the same directory as FModStudio (usually 3p-fmodstudio)

You’ll then need to change the value of a variable called URL_BASE in the file build-cmd.sh

Since the package is now in the same directory as the script, you can simply change the value of URL_BASE to "file://./" and it will pick it up.

If you downloaded to a different location, then you should adjust the value of URL_BASE accordingly.

NOTE
I’ve found that the standard build instructions 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.

FModEx

FModEx is an older FMod library, which was used in Firestorm v5.0.x and earlier. If building that codebase you will need these instructions, otherwise you should skip this section and use FModStudio instead.

You only need to do this once, as FModEx very rarely changes.

To build FModEx you will need to do the following:

Get the source code by executing the following command:

hg clone https://bitbucket.org/NickyD/3p-fmodex

There is a bit of an problem, however, just like with FModStudio (see above) – you must download the library yourself, because the script tries to download it from an IP address that is not publicly accessible.

You will need to go to the FMod website and create a login (if you don’t already have one). However, this will not grant you immediate access, as the FMod Ex project is retired and no longer accessible.

You must then send an email to support, stating your username and asking for access and explaining why (saying you want to build the Second Life Firestorm viewer was sufficient for me), and then they will then grant access and allow you to download the pre-built libraries.
[Credit: Many thanks to Zenny3D for telling me about this in the comments section]

You will have access to the current and all previous versions. As of the time of writing, the most recent version is v4.44.64 but the version you require is v4.44.61 so be sure to download that one.

Download the package appropriate for your targeted operating system. The easiest thing to do is to place it in the same directory as FModEx (usually 3p-fmodex)

You’ll then need to change the value of a variable called URL_BASE in the file build-cmd.sh

Since the package is now in the same directory as the script, you can simply change the value of URL_BASE to "file://./" and it will pick it up.

If you downloaded to a different location, then you should adjust the value of URL_BASE accordingly.

Now that you have the package, you can build it. The procedure for building is the same for both Windows and Linux.

From the 3p-fmodex source directory, simply execute the following commands.

autobuild build --all
autobuild package

When built, you will get an output similar to the following (although obviously the values will be different).

packing fmodex
wrote /home/becca/src/3p-fmodex/fmodex-44461-linux-201706151710-r24d.tar.bz2
md5 a1ea2bad2489718f49707e245cfc52a1

You will need these values later on.


Performing a build

Windows

    1. Open a command window in the location of your source folder.(Note: A standard Windows command prompt, not the VS2013 command prompt)
    2. Set up the VC12 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 12.0\VC"
      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.

    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.

      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 -DFS_UPGRADECODES='GUID1,GUID2'

      (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 and works in both Second Life and OpenSim.

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

Linux

Note: These instructions apply to Firestorm v5.0.x and have not yet been updated for later versions or tested with later versions.

  1. Open a terminal window in the location of your source directory.
  2. Update autobuild.xml with the fmodex information.
    Note: You only need to do this the first time you do a build, or if you revert the file.

    autobuild installables edit fmodex platform=linux hash=md5 url=file://wrote

    The values of md5 and wrote are the values output when you built FModEx.
    So in the example I posted earlier, this would be.

    autobuild installables edit fmodex platform=linux hash=a1ea2bad2489718f49707e245cfc52a1 url=file:///home/becca/src/3p-fmodex/fmodex-44461-linux-201706151710-r24d.tar.bz2

    (Note the three slashes! The first two are for file:// and then the third is the start of the path)

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

  3. Execute the following commands
    autobuild -m64 build -c ReleaseFS_open -- --chan MY_CHANNEL --package --fmodex --avx

    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 works in both Second Life and OpenSim.

Note: The above uses NickyD’s version of autobuild which uses -m64 for a 64-bit build and is not compatible with Linden Labs’ autobuild.

I have verified this by installing a resulting build on a bare metal Linux box running Ubuntu 17.04, an nVidia GTX 780, and the latest nVidia proprietary drivers, and it ran absolutely fine and as fast as the official Firestorm build. And, crucially, had sound.


Building the release viewer instead

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

Instead of cloning the source with

hg clone http://hg.phoenixviewer.com/phoenix-firestorm-lgpl

clone it with

hg clone http://hg.phoenixviewer.com/phoenix-firestorm-release

Parallel builds of pre- and post- Alex Ivy

Due to incompatibility issues between NickyD’s autobuild and Linden Labs’ autobuild, it’s not possible to build both pre-merge and post-merge branches on the same PC. The build instructions suggest getting round this by using virtualenv.

However, my aim is to have two different user accounts on Windows, one for pre Alex Ivy code and one for post Alex Ivy, using User environment variables, the User path, and per-user installs.

So far I have not achieved this, as a standard install of Linden Labs’ autobuild affects all users, and doing a per-user install with pip’s --user flag doesn’t yield an autobuild that works.

Now that the release branch is post Alex Ivy, I don’t propose to investigate this further.

However, I have confirmed that you can uninstall autobuild-1.1 again with the command

pip uninstall hg+http://bitbucket.org/lindenlab/autobuild-1.1#egg=autobuild

and that NickyD’s autobuild can be used again. If you don’t switch between builds that often, it could be a solution.


Summary

My build instructions result in an OpenSim-compatible Firestorm that uses OpenJPEG but also links in FModEx or 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, but I do have a powerful PC so 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
Firestorm Windows build instructions – build instructions tailored for Windows builds.
Firestorm 64-bit Ubuntu 16.04 build instructions – build instructions tailored for Ubuntu 16.04
Compiling Firestorm Viewer – a top-level page for all platforms

31 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?

Leave a Reply

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