archive:fs_compiling_firestorm_alexivy_ubuntu_16 - ↷ Page moved from ...

This procedure is used for building a 64-bit version of Firestorm 5.1 on 64-bit Ubuntu systems. It was tested and verified on Ubuntu 16.04. This procedure assumes that your system has been properly updated.

This procedure will not work on other versions of Ubuntu, and has not been tested on any other version of Ubuntu or any other distribution/variant/derivative.

The build process requires at least 4GB RAM with swap, a modern dual-core CPU and 32GB available HDD space. Recommended 8GB or more RAM, quad-core CPU and 32GB available HDD space.

This is needed for compiling any viewer based on the LL open source code and only needs to be done once.

This repository is needed so that gcc version 6 can be installed.

sudo add-apt-repository "deb http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu xenial main"
sudo apt update

The required tools, some of which may already be installed, are:

sudo apt upgrade # to make sure all installed packages are current
sudo apt install --install-recommends bison bzip2 cmake curl doxygen flex g++-6 gdb m4 mercurial moreutils pkg-config \
                                      python python-dev python-pip

(the –install-recommends flag tells apt-get to install all packages recommended by each named package.)

The build environment needs to know to use gcc 6

update-alternatives --remove-all gcc 
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 6 \ 
--slave /usr/bin/g++ g++ /usr/bin/g++-6 \
--slave /usr/bin/gcov gcov /usr/bin/gcov-6
update-alternatives --config gcc

Note that this will “hide” the current gcc (v7) from the build environment, so you will want to add it as an alternative, then use the “update-alternatives –config gcc” command to switch versions as needed.

If you build in a virtual machine (guest), you probably don't want to run the viewer from there, but rather from the host, or a different machine altogether. To simplify the process of sending the viewer oustide the guest, you will need rsync. Rsync will copy only the changed files, dramatically speeding up subsequent processes, and it will properly handle symbolic links.

Note that this procedure assumes you have correctly configured your guest and host, and that the destination path is accessible and writable from the guest.

sudo apt install --install-recommends rsync

Firestorm 5.1, like Linden Lab's AlexIvy release, is built with the USESYSTEMLIBS flag set so that the libraries are installed on the user's system as needed and not shipped with - or maintained by - the viewer. This means that a large number of development libraries must be installed on the build system.

These libraries should all be available in the standard Debian repositories, and some may already be installed:

sudo apt install --install-recommends libalut-dev libapr1-dev libaprutil1-dev libatk1.0-dev libboost-all-dev libcairo2-dev \
libcollada-dom2.4-dp-dev libcurl4-openssl-dev libdbus-glib-1-dev libfreetype6-dev libgl1-mesa-dev \
libglu1-mesa-dev libgtk2.0-dev libjpeg-dev libjsoncpp-dev libnghttp2-dev libogg-dev libopenal-dev \
libpangox-1.0-dev libpng-dev libsdl1.2-dev libssl-dev libstdc++6 liburiparser-dev libvorbis-dev libx11-dev \
libxinerama-dev libxml2-dev libxmlrpc-epi-dev libxrender-dev zlib1g-dev

Autobuild is a Linden Lab resource that does all the hard work. Firestorm 5.1 uses a stock, unmodified version of autobuild from Linden Lab, version 1.1 or above.

sudo pip install --upgrade pip
sudo pip install autobuild

This will install autobuild and add a link in the exec path.

Plan your directory structure ahead of time. If you are going to be producing changes or patches you may be cloning a copy of an unaltered source code tree for every change or patch you make, so you might want to have all this work stored in its own directory on its own hard drive, or on a hard drive with lots of free space. Currently, the source code tree takes up over 1GB initially, 3GB after configuring and several times that after building the viewer. If you are a casual compiler and won't be producing any changes, you can use one directory. For this document, I will assume ~/src.

cd ~/src

There are several repositories but the one we are after is the lgpl (release) repository. You can grab all the sources if you wish, but keep in mind that each requires over 1GB initially.

hg clone https://hg.firestormviewer.org/phoenix-firestorm-lgpl

This will create a folder called phoenix-firestorm-lgpl and add all the source files. If you desire, you can choose a different folder name by adding the name to the end of the command:

hg clone https://hg.firestormviewer.org/phoenix-firestorm-lgpl firestorm-source

The rest of this document will assume the default directory, phoenix-firestorm-lgpl

This can take a bit, it's a rather large download. On a slow network, it may fail, and this script can help mitigate the issue:

pull_in_chunks.sh

#!/bin/bash
 
cd ~/src
hg clone -r 10000 https://hg.firestormviewer.org/phoenix-firestorm-lgpl
cd phoenix-firestorm-lgpl
for i in {15000..50000..5000}
do
	echo "Grabbing to change $i"
	hg pull -u -r $i
done
echo "Grabbing to tip"
hg pull -u
cd ~/src

Autobuild 1.1 uses a separate file to control compiler options, switches, and the like for different configurations. Ansariel Hiller maintains a Firestorm-specific version of this file and an associated convenience script. You will want to put this near your source code tree. The rest of these instructions will assume you put it in the source tree at the same level as your main source repository, using the default name.

cd ~src
hg clone https://hg.firestormviewer.org/fs-build-variables

Autobuild 1.1 uses a series of environment variables to control the build process. The fs-build-variables reposirory includes a convenience script to set them. You will need to perform this step in any new shell window that you are going to run autobuild in.

cd ~/src/phoenix-firestorm-lgpl
source ../fs-build-variables/convenience Release
export AUTOBUILD_VARIABLES_FILE=$HOME/src/fs-build-variables/variables

Unlike previous versions of autobuild, version 1.1 requires the address size switch (-A) after the command, not before it. If you want a 32-bit build, you must specify that; there is no longer a default.

cd ~/src/phoenix-firestorm-lgpl
autobuild configure -A 64 -c ReleaseFS_open

This will set up to compile with all defaults and without non-default libraries. It will fetch any additional necessary libraries.

There are a number of switches you can use to modify the configuration process. The name of each switch is followed by its type and then by the value you want to set.

• LL_TESTS (bool) controls if the tests are compiled and run. There are quite a lot of them so excluding them is recommended unless you have some reason to need one or
  more of them.
• clean will cause autobuild to remove any previously compiled objects and fetched packages. It can be useful if you need to force a reload of all packages
• package will result in a bzip2 archive of the completed viewer. Enabled by default, you would have to use -DPACKAGE:BOOL=Off to disable it
• chan will set a unique channel (and the name) for the viewer, appending whatever is defined to “Firestorm-”. By default, the channel is “private” followed by your computer's name.

TIP: OFF and NO are the same as FALSE; anything else is considered to be TRUE

Examples:

autobuild configure -A 64 -c ReleaseFS_open -- -DLL_TESTS:BOOL=FALSE
autobuild configure -A 64 -c ReleaseFS_open -- --clean
autobuild configure -A 64 -c ReleaseFS_open -- --chan="MyBuild"

In the last example, the channel and resulting viewer name would be “Firestorm-MyBuild”.

The first time you configure, several additional files will be downloaded from Firestorm and Second Life sources. These are mostly binary packages maintained outisde the viewer development itself. And if you use the –clean switch, you will re-download them all.

autobuild build -A 64 -c ReleaseFS_open

Now, sit back, read War and Peace, calculate PI to 50 places, tour the country, whatever you desire. Compiling can take quite a bit of time depending on your computer's processing power.

NOTE: It is possible to use autobuild to do both the configure step (only needed once) and the build step with one command (autobuild build -A 64 -c ReleaseFS_open – –clean [more switches]). For clarity, they are mentioned separately.

If you build the viewer using a virtual machine (guest), you may want to copy the viewer files over to your host or to a different machine in order to use the viewer. Your guest may not have sufficient resources to run the viewer. The rsync program can make copying easy and accurate. And if you build the viewer again, the options included in the command example will cause rsync to only copy the new files, cutting down on the time needed to copy.

rsync -rptgoDLK --update --progress $HOME/src/phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged/* /path/to/host/machine

Again, we will assume that you have already made that destination accessible and writable by the guest.

Create the desktop launcher

cd ~/src/phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged/etc
./refresh_desktop_app_entry.sh

Then open your applications menu and look in the Internet or Network branch for the Firestorm launcher.

cd ~/src/phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged
./firestorm

You can copy or move the contents of ~/src/phoenix-firestorm-lgpl/build-linux-i686/newview/packaged to another location if you choose, and then launch firestorm from there. Example:

mkdir ~/Firestorm
cp -a ~/src/phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged/* ~/Firestorm
cd ~/Firestorm
./firestorm # or etc/refresh_desktop_app_entry.sh to create a desktop launcher

If you encounter errors or run into problems, please first double check that you followed the steps correctly. One typo can break it. Then, check whether someone else already had the same issue. A solution might be known already.

• IRC: The #phoenixviewer-dev channel is the best place to look for solutions.
  A lot of self-compilers and project developers hang out there and are ready to help you.

• Jira:JIRA may contain resolved tickets.
  Search using the error you encountered.

• Included documentation: In the Firestorm root folder are several “README” documents. You should make yourself familiar with their content, even if they appear to be out of date.

If you found a procedural error in this document, please let us know in as much detail as you can, either contact the team (preferred) or discuss on IRC.

• Missing libraries/applications/packages This may occur if you did not or could not install the listed packages. The packages do exist in the default Ubuntu repositories, so make sure you did not disable those. If you find that a library or application is in a different package for your system, contact the team with the name of the library or application, the name of its package and your Linux OS so that information can be checked and added here.

• Delayed sounds Some users have noted that OpenAL plays sounds from the viewer up to 20 seconds after they are triggered. There is no solution to this via the viewer, but there may be some solutions on the Internet

• No Sounds The viewer will try to use whatever sound service you have running, but might need a little coaxing. Read through the firestorm script inside the program folder, you will find various commended options. Uncommenting one or more may help restore sound.

• Voice Won't Connect It was observed in testing that voice would not connect unless “No Device” was chosen for the Input device (Preferences ⇒ Sound & Media ⇒ Voice ⇒ Audio Device Settings). This was resolved by replacing Firestorm/lib/libvivoxal.so.1 with a copy from release.

• Voice Won't Connect pt 2 The current version of the voice files may not function correctly in the Linux viewer, in which case you will see the red indicator on the Nearby Chat tab, and you may or may not get an error message. This is a known issue and is being addressed. Hopefully we can soon remove this as an issue. The workaround is to copy the win32 folder from our Release viewer's bin folder and paste it into your build's bin folder.