View source

== Issues when compiling a standalone Linux viewer ==

This is on Linux Ubuntu Hardy 8.04.--oobscure 13:20, 1 September 2008 (PDT)

With 'standalone Linux' I mean using system libraries instead of libraries provided by Linden Lab as mentioned at [[CMake#Prebuilt_libraries_vs._standalone_builds]]. This can be done running the develop.py script with the '--standalone' option:
 ./develop.py --standalone

''Error message''
* possible solution
<br>

''CMake Error: Could not find BerkeleyDB library''
* sudo apt-get install libdb-dev

''CMake Error: Could not find APR library''
* sudo apt-get install libapr1-dev

''CMake Error: Could not find APRUTIL library''
* we should probably install libaprutil1-dev or libaprutil1.0-dev, but this doesn't work on my system (Ubuntu 8.04) because of dependencies problems that apparently can't easily solved.

=== Comment ===

I do not use the --standalone option, even for compiling standalone viewers since this will fail depending on what libraries versions exist on your system (for example, with Mandriva 2009.0, I have db v4.6 and not db v4.2 as required by the viewer, and forcing a compilation with db 4.6 results in a non-functional viewer).
<br />Instead, I compile a release viewer but I replace the pre-built libraries with the compatible libraries of my system. To do this easily, I wrote a script: [[Building_the_viewer_with_CMake/cmake-SL_script|cmake-SL]]. The result is a mostly standalone viewer (for example, in Mandriva 2009.0, I keep the pre-built DB4.2 and APR libraries).
<br />[[User:Henri Beauchamp|Henri Beauchamp]] 17:24, 1 December 2008 (UTC)

== CMake and Visual Studio C++ 2005 Express Edition ==

For me, the process of building the client wasn't as straightforward as the documentation made it seem. Here's some tips that will hopefully prevent the next person from experiencing the same frustrations. 

I made the mistake of copying everything the [[Compiling_the_viewer_(MSVS2005)]] page told me to copy. You *only* need to do the fmod section (3.2.1). After doing that, ignore the rest of that page.

First off, getting develop.py to work: You need to specify your visual c++ version explicitly. Without any arguments specifying the version, develop.py will complain and error out. So from the command line:

for VS C++ 2005

 <code>python develop.py -G VC80</code>


or

for VS C++ 2008

 <code>python develop.py -G VC90</code>


As far as I can tell, at the very end of the environment setup develop.py attempts to run a utility called vstool. vstool doesn't like the Express Edition, so the last few messages it will print are:

 Value cannot be null.
 Parameter name: type
 Quitting to do error opening: C:\...\linden\indra\build-VC80\SecondLife.sln

Don't worry about this, the solution files have been created successfully.
develop.py should have created a build-VC80 (or build-VC90) folder. In it you'll find SecondLife.sln. Open it, but before you build you have to do a few things. In Visual Studio, you'll need to set secondlife-bin as the StartUp project. Do this by right clicking the secondlife-bin project, then selecting Set as StartUp Project.

Under the copy-win-libs project, in the CMake Rules folder, delete all the llkdu.dll.rule files. This will force the client to fall back on openjpeg, which is good because I have no clue where to get llkdu.dll. The one in C:\Program Files\Second Life will only cause you pain and misery, so don't try it. 

Select the secondlife-bin project. In the drop-down to the right of the green play button at the top, select RelWithDebInfo then click the play button. This will build a Release viewer that has extra debug information printed to the console (and debug symbols too?). Build it. It will fail, complaining about not being able to find fmod.dll.

This is because it's looking in the wrong place by default. Right click the secondlife-bin project, and click Properties. In the Property Pages dialog that appears, under Configuration Properties, click Debugging. Change the working directory to wherever you put linden\indra\newview. Try building again, and it should work! 

Hope this helps.
--[[User:Christopher Omega|Christopher Omega]] 12:51, 7 September 2008 (PDT)

Er, well the llKdu.dll worked perfectly fine for me, your problem is that you grabbed it from the wrong client build, I can't remember from which one it was, but it was either the RC or the PG Mono client. --[[User:Nexii Malthus|Nexii Malthus]] 13:16, 7 September 2008 (PDT)

I had issues after compiling the viewer where I didn't hear any sound. In order to activate sound I ran Cmake, marked the box to activate FMOD and recompiled the viewer. This action enabled sound, thanks to Michelle Zenovka for pointing this out.

The notes in this section also apply to the 2008 express edition.

I posted the steps I took to compile the source using 2008 Express here: [https://wiki.secondlife.com/wiki/User:Jodiah_Jensen How I Compiled SL Source w/ VC++ 2008 Express Edition ]

--[[User:Jodiah Jensen|Jodiah Jensen]] 03:34, 29 October 2008 (UTC)

== CMake and Python 2.6 ==
First, make sure you are using the WINDOWS versions of CMake and Python, do not use the CMake and Python versions included with Cygwin.

You can get CMake for win32 here: http://www.cmake.org/files/v2.4/cmake-2.4.8-win32-x86.exe

You can get Python here: http://www.python.org/download/


If, when you run the develop.py script, you are getting an error complaining about not finding the Python Interpreter ('''''"CMake Error: No Python interpreter found"'''''), you may need to modify the \linden\indra\cmake\Python.cmake file as follows: (thanks to [https://wiki.secondlife.com/wiki/User:Lear_Cale Lear Cale] for this code)

    find_program(PYTHON_EXECUTABLE
       NAMES python25.exe python23.exe python.exe
       NO_DEFAULT_PATH # added so that cmake does not find cygwin python
       PATHS
       '''[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.6\\InstallPath]'''       #<-- add this line
       [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.5\\InstallPath]
       [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.4\\InstallPath]
       [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.3\\InstallPath]
       )

This should allow CMake to find your python interpreter when it needs it.
(This change was needed as of version 1-21-r99587 of the source code)

If you are still having the problem finding the python interpreter after this modification, try re-installing Python.

--[[User:Jodiah Jensen|Jodiah Jensen]] 03:34, 29 October 2008 (UTC)

'''GOOD NEWS:'''

''"...saw your Python 2.6 tweak, and nudged the dev team to pick up the change, so that it should work in the future without needing that edit (it'll be in the next trunk rev, and will show up in roughly the 1.23 timeframe)."''-- [[User:Rob Linden|Rob Linden]] 16:23, 29 October 2008 (UTC)

== CMake wishlist ==

List of issues that we +1 to get fixed

*  [http://public.kitware.com/Bug/view.php?id=7643 expanded compiler flag support]
*  Support for Linux AMD 64 bits builds --[[User:Catherine Pfeffer|Catherine Pfeffer]] 15:10, 13 September 2008 (CEST)

== Python version requirement ==

LL supplied develop.py requires python 2.5 or later, although this wiki says python 2.3 or later works.  --[[User:Alissa Sabre|Alissa Sabre]] 18:31, 21 October 2008 (PDT)