Difference between revisions of "Talk:Compiling the viewer (Mac OS X)"

From Second Life Wiki
Jump to navigation Jump to search
 
(12 intermediate revisions by 5 users not shown)
Line 13: Line 13:


Thank you for your attention!  [[User:Hunting Hare|Hunting Hare]] 12:06, 9 April 2007 (PDT)
Thank you for your attention!  [[User:Hunting Hare|Hunting Hare]] 12:06, 9 April 2007 (PDT)
==Trying newer versions of tools==
The latest version of the tools:  XCode 3.2.4, CMake 2.8.4, etc., seem to work fine.  Still using gcc 4.0, though.  Set the platform to 10.5.  106 does not seem to work.
As a side note, Xcode 4.0 is coming soon.  It includes a totally new compile/link architecture.  Possibly using LLVM will be faster, and produce faster code.
onward [[User:Lee Ponzu|Lee Ponzu]] 16:00, 23 September 2010 (UTC)


==Ordering of main and proprietary material installs ==
==Ordering of main and proprietary material installs ==
Line 48: Line 56:
Open for suggestion, I'm not a C++ person, but want to learn with SL Viewer --[[User:Mokelembembe Mokeev|Mokelembembe Mokeev]] 22:03, 7 April 2007 (PDT)
Open for suggestion, I'm not a C++ person, but want to learn with SL Viewer --[[User:Mokelembembe Mokeev|Mokelembembe Mokeev]] 22:03, 7 April 2007 (PDT)


''To fix the depcomp not found problem, try '''automake -a -c'''''


- After typing make, a Warning shows up but keeps compiling, not sure if causing the libexpat not found. PPC 10.4.9, Xcode 2.44.1  using the beta-1.14.1.1 code --[[User:Mokelembembe Mokeev|Mokelembembe Mokeev]] 11:45, 7 April 2007 (PDT)
- After typing make, a Warning shows up but keeps compiling, not sure if causing the libexpat not found. PPC 10.4.9, Xcode 2.44.1  using the beta-1.14.1.1 code --[[User:Mokelembembe Mokeev|Mokelembembe Mokeev]] 11:45, 7 April 2007 (PDT)
Line 148: Line 157:
:How does it run compared to the Linden Labs' release? [[User:David Frantisek|David Frantisek]] 00:22, 12 January 2007 (PST)
:How does it run compared to the Linden Labs' release? [[User:David Frantisek|David Frantisek]] 00:22, 12 January 2007 (PST)
:: Even slower. I'll pop in some more memory and see if that helps. [[User:Phineas Pegler|Phineas Pegler]] 10:06, 12 January 2007 (EST)
:: Even slower. I'll pop in some more memory and see if that helps. [[User:Phineas Pegler|Phineas Pegler]] 10:06, 12 January 2007 (EST)
== Compiling/Running on X64_64 Linux ==
The alpha release runs, but building it is a whole different story.  I'll update this section as I progress.  My distro is Ubuntu Edgy 6.10.
- Linden build
- Library build
'''xmlrpc-epi'''
after patching, and 'automake -a -c' to fix depcomp problem, Im getting:
libtool: unrecognized option `--tag=CC'


== build the project w/ gcc 3.3 or 4.0? ==
== build the project w/ gcc 3.3 or 4.0? ==
Line 175: Line 196:
Quick fix, Xcode - resources - languages.txt delete the japanes, german and korean languages.txt in there. put a blanco languages.txt in the english.lproj subfolder, this works, deleting all four won't.
Quick fix, Xcode - resources - languages.txt delete the japanes, german and korean languages.txt in there. put a blanco languages.txt in the english.lproj subfolder, this works, deleting all four won't.


== Running the Viewer ==
 
It runs!! but when I log in it forces me to download a newer client, so i can't try my new features. any suggestions to bypass this? [[User:Eelke Forder|Eelke Forder]] 18:52, 14 April 2007 (PDT)
 
== Compiling the WindLight Branch ==
 
Please bear with me if some of the "obvious" things are not related to the WindLight branch at all, but to my own inexperience in getting such a complex application to compile under XCode; my own programming experience under Xcode has been very limited and some things should be obvious to expert developers on XCode, specially to the ones who compile SL every day :)
 
The [[Version_control_repository|WindLight source code]] can be gotten through <tt>svn co http://svn.secondlife.com/svn/linden/branches/2007/windlight_1-17-0</tt>. Since I was not sure about naming conventions, in my case I got it under the <tt>windlight_1-XX-X</tt> directory and just symlink'ed <tt>linden</tt> to it. Not feeling too bold about recompiling all libraries manually, I simply got the pre-compiled ones from LL directly; they do the job (I mean, I've compiled <tt>zlib</tt> a million times under a few architectures, there is no more thrill in compiling it one more time :) ).
 
Now the tweaks. In my system at least, XCode (2.4 and not 2.4.1; GCC is 4.0.1 build 5363) cannot find the header files for OpenGL. I've added <tt>/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include</tt> manually to <tt>SCM > Build > Header Search Paths</tt> and that fixed one issue.
 
The next is getting the source to find the appropriate "glh" header files. Bad news; this seems to be some specific Nvidia <-> GL helper library, and although LL gently included two files (<tt>glh_linear.h</tt> and <tt>glh_genext.h</tt>), the rest of the header files (and there are a lot of them) are sadly missing. Fortunately, after some searching, I found these are in a package called <tt>nvparse</tt> which is downloadable from http://developer.nvidia.com/attach/8196. Then you just have to make sure the many files using the GLH library can find those header files; as the source moves from the original place to the <tt>build</tt> directory, it means that you'll have to put at least two symlinks for those. Possibly a better approach is to place these under <tt>/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include</tt> as well and let SL find them there. ''''Important:'''' LL's has his ''own'' <tt>glh_linear.h</tt> and <tt>glh_genext.h</tt>, so make sure you don't overwrite them!
 
To make matters worse, LL's own header files override the equality/inequality operator on line 179/180 of <tt>glh_linear.h</tt>. Tsk. GCC 4.0.1 doesn't like it, so commenting it out will give you a clean compile, but who knows what this will break further on.
 
<tt>viewer_manifest.py</tt> complains that it cannot create the <tt>~/linden/indra/newview/build/Deployment/Second Life.app</tt> directory; this might be simply a permissions problem, but after creating it manually, the rest worked flawlessly towards a build. It took about an hour or so on my iMac with 2 GHz Intel Core 2 Duo and 1 GB of RAM.
 
When running the recently compiled version of Second Life, it complained that it couldn't open <tt>Contents/Resources/app_settings/windlight/clouds2.jpg</tt> and crashed-on-login. Sure thing, that file is not there; fortunately, I could easily copy it from my previous installation of WindLight. For the ones who have deleted it by mistake, I've uploaded it here: [[Image:Clouds2.jpg|thumbnail|clouds.jpg needed for a WindLight build]]
 
Performance is obviously terrible, less than half of the regular viewer, and perhaps 30-50% worse than the official (previous) WindLight version, very likely because of using the open source JPEG2000 decoder and not the commercial one that LL uses but cannot distribute. But... I got nice-looking weather back for machinimas, and that makes me happy! :)
 
[[User:Gwyneth Llewelyn|Gwyneth Llewelyn]] 04:32, 16 June 2007 (PDT)
 
I should just add that the icon for the SL logo that appears on the application on the Dock is not there either. Simply get <tt>secondlife.icns</tt> from any of your SL installations and drop it under <tt>Contents/Resources</tt>
 
[[User:Gwyneth Llewelyn|Gwyneth Llewelyn]] 16:55, 16 June 2007 (PDT)
 
== Fmod ==
 
Of course the cp instructions for the fmod libs will not work, as the target directories are not yet created at that stage and cp will not create them. [[User:Lanita Wingtips|Lanita Wingtips]] 16:24, 12 November 2008 (UTC)
 
And there is also the fact that CMake does not find Fmod files at the suggested folders, so the instructions should look more like this:
 
$ mkdir -p linden/libraries/universal-darwin/lib_release
$ mkdir linden/libraries/universal-darwin/lib_debug
$ mkdir linden/libraries/include
$ cp -p ../fmodapi375mac/api/inc/*.h linden/libraries/include
$ lipo -create fmodapi375mac/api/lib/libfmod.a fmodapi375mac/api/lib/libfmodx86.a -output linden/libraries/universal-darwin/lib_release/libfmod.a
$ cp -p linden/libraries/universal-darwin/lib_release/libfmod.a linden/libraries/universal-darwin/lib_debug/libfmod.a
 
[[User:Lanita Wingtips|Lanita Wingtips]] 15:27, 13 November 2008 (UTC)
 
== slplugin ==
In slplugin.cpp there are commented out instructions that once uncommented print an slplugin.log.
The location of the log is at (kokua viewer example):
/Users/<username>/kokua(could be viewer-release)/build-darwin-i386/newview/RelWithDebInfo/
At this point right click on the application. My case Kokua (could be Second Life). Show package contents.
Contents/Resources/llplugin
The file slplugin.log resides here. [[User:Nicky Perian|Nicky Perian]] 15:43, 7 February 2014 (PST)

Latest revision as of 15:43, 7 February 2014

This is a talk page associated with the Open Source Portal. Changes to all pages like this one can be tracked by watching the "Related Changes" for "Category:Open Source Talk Page"
Please sign comments you leave here by putting four tildes (~~~~) at the end of your comment. For more guidelines, see Talk Page Guidelines


PLEASE NOTE

When you report any problem, PLEASE post your OS version and version of Xcode. This will help identify the environments that have issues, and allow the creation of workarounds specific to those environments. Thank you! Hunting Hare 01:36, 15 January 2007 (PST)

In addition, please post the name and version number of what you're compiling. This helps us figure out if there are problems introduced from an older version to a newer version.

GCC 3.3 DOES NOT TARGET INTEL-BASED MACS. If you are targeting an Intel-based Mac, you MUST use GCC 4.0. There are known incompatibilities between gcc 3.3 and gcc 4.0 (some code that compiles on 3.3 won't compile under 4.0). Apple recommends that all projects migrate to gcc 4.0 as soon as practical, for PPC as well as Intel architectures.

At this time, if you use the precompiled libraries package, the macview source can compile and be linked using gcc 4.0. I have not verified the build processes for all of the dependent libraries yet.

Thank you for your attention! Hunting Hare 12:06, 9 April 2007 (PDT)

Trying newer versions of tools

The latest version of the tools: XCode 3.2.4, CMake 2.8.4, etc., seem to work fine. Still using gcc 4.0, though. Set the platform to 10.5. 106 does not seem to work.

As a side note, Xcode 4.0 is coming soon. It includes a totally new compile/link architecture. Possibly using LLVM will be faster, and produce faster code.


onward Lee Ponzu 16:00, 23 September 2010 (UTC)

Ordering of main and proprietary material installs

I suggest the section "Installing Proprietary Libraries" should come after the sections "Installing Libraries" and "Installing Libraries From Scratch", as the instructions on fmod installation require that the main directory structure has been established. I'm just looking at the material for the first time, so I won't do the move myself in case I'm missing something. --Bram Nogah 15:59, 17 February 2007 (PST)

I thought the same thing also, I left the "Installing Proprietary Libraries" before "Installing Libraries as like an intro, then I moved the "Fmod" section after the section "Installing Libraries From Scratch" and before the "Boost" section --Mokelembembe Mokeev 04:53, 7 April 2007 (PDT)

Mozilla

I'm a bit confused about the Mozilla lib dependency--perhaps if someone knew what was actually required to be compiled (even if it would be somewhat difficult) we could at least try. :-) Thanks. David Frantisek 19:55, 8 January 2007 (PST)

In the third step i'm getting a "checking for C compiler default output file name... configure: error: C compiler cannot create executables". I found out that is because i'm using an intel mac. Switching to GCC 4.0.1 does the trick Eelke Folmer

Problems with directions

It seems like there are a couple places here where problems are created because of the use of "../.." I'm not all that familiar with use of the terminal, but I think this puts you in your home directory, which is okay as long as that's the top-level of your project, but not if the top-level is ~/Desktop or somewhere else entirely. David Frantisek 19:55, 8 January 2007 (PST)

../.. refers to the parent of the parent folder -- from /Users/yourusername/ , ../.. would refer to the root directory that contains the Users folder. Remember, Mac OS X has the technological underpinning of BSD UNIX. If you're not familiar with the use of the Terminal, then you will likely find a book on using UNIX very helpful. For reference, the single character ~ refers to your home directory but only if it's used as the first element of a path specification -- ~/Desktop refers to your Desktop folder. ~username/ refers to the home directory of username. Hunting Hare 01:36, 15 January 2007 (PST)


XMLRPC

- Applied patches as prescribed but after doing the final make I get: "configure: error: libexpat not found make: *** [config.status] Error 1" I can't compile using GCC 3.3 Eelke Folmer GCC 4.0.0 / OSX 10.4.9 - When I apply patch 3 i get: Hunk #1 succeeded at 120 (offset -1 lines).

- I get same error using gcc 3.3, OS X 10.4.9 PowerPC using the beta-1.14.1.1 code:

configure: error: libexpat not found
make: *** [config.status] Error 1

Looks like the libexpat* in /tmp/expat/lib need to be copied somewhere but not sure where. I tried copying /tmp/expat/lib/* into /usr/local/lib which seems to get pass the missing libexpat error, but the comes up with error:

src/Makefile.am: required file `./depcomp' not found
make[1]: *** [Makefile.in] Error 1
make: *** [all-recursive] Error 1

Open for suggestion, I'm not a C++ person, but want to learn with SL Viewer --Mokelembembe Mokeev 22:03, 7 April 2007 (PDT)

To fix the depcomp not found problem, try automake -a -c

- After typing make, a Warning shows up but keeps compiling, not sure if causing the libexpat not found. PPC 10.4.9, Xcode 2.44.1 using the beta-1.14.1.1 code --Mokelembembe Mokeev 11:45, 7 April 2007 (PDT)

$make
cd . && aclocal
cd . && automake --gnu Makefile
cd . && autoconf
/bin/sh ./config.status --recheck
running /bin/sh ./configure  --disable-shared --prefix=/tmp/xmlrpc-epi  --no-create --no-recursion
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/Users/mokele/documents/second_life/Viewer_Code/lindenlib/xmlrpc-epi-0.51/missing: Unknown `--run' option
Try `/Users/mokele/documents/second_life/Viewer_Code/lindenlib/xmlrpc-epi-0.51/missing --help' for more information
configure: WARNING: `missing' script is too old or missing

Curl

In the download of the SL libs, header files for Curl are included. Is this something that should is also required for a succesful build? Thanks. David Frantisek 19:57, 8 January 2007 (PST)

Can't get CURL to compile, code below of what happens, gcc 3.3, OS X 10.4.9, PPC --Mokelembembe Mokeev 23:56, 7 April 2007 (PDT)

checking whether to enable maintainer-specific portions of Makefiles... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... 
configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** No rule to make target `clean'.  Stop. 
make: *** No targets specified and no makefile found.  Stop.
make: *** No rule to make target `install'.  Stop.
checking whether to enable maintainer-specific portions of Makefiles... no
checking for sed... /usr/bin/sed
checking for ar... ar
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking curl version... 7.16.1
checking build system type... powerpc-apple-darwin8.9.0
checking host system type... powerpc-apple-darwin8.9.0
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... 
configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** No rule to make target `clean'.  Stop.
./configure
checking whether to enable maintainer-specific portions of Makefiles... no
checking for sed... /usr/bin/sed
checking for ar... ar
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking curl version... 7.16.1
checking build system type... powerpc-apple-darwin8.9.0
checking host system type... powerpc-apple-darwin8.9.0
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... 
configure: error: C compiler cannot create executables
See `config.log' for more details. 
make: *** [all] Error 77 
make: *** No rule to make target `install'.
cp: /Users/mokele/documents/second_life/viewer_code/lindenlib/curl/build-c-ares/lib/libcares.a: No such file or directory
cp: /Users/mokele/documents/second_life/viewer_code/lindenlib/curl/build-curl/lib/libcurl.a: No such file or directory
tar: libcares.a: Cannot stat: No such file or directory
tar: libllcurl.a: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors

OpenJPEG

At least on my Macbook Pro, the latest (1.1) version of OpenJPEG would not compile, giving the error "make: *** No rule to make target `libopenjpeg/fix.o', needed by `libopenjpeg.a'. Stop.". Downloading the 1.0 version and following the instructions worked fine. Phineas Pegler 22:48, 8 January 2007 (EST)

I had the same experience, although I didn't try the 1.0 version - thanks for the suggestion :-) David Frantisek 00:21, 12 January 2007 (PST)

- Can't get OpenJPEG to compile, get the error message:

make -f Makefile-i386.ppc libopenjpeg.a
gcc -isysroot /Developer/SDKs/MacOSX10.3.9.sdk -O3 -arch ppc -Ilibopenjpeg -c libopenjpeg/bio.c -o libopenjpeg/bio.o
gcc: cannot specify -o with -c or -S and multiple compilations
make: *** [libopenjpeg/bio.o] Error 1

gcc 3.3, Mac OS X 10.4.9 PPC --Mokelembembe Mokeev 23:45, 7 April 2007 (PDT)

Compiling/Running on OS X

I have the client successfully built and running on my Macbook Pro running 10.4.8 and XCode 2.2.1, using the linden library tarball. The only stumbling block is that it would not run using the "Development" build configuration, only under the "Deployment" config. Running under "Development" crashed on startup within Freetype, with a EXC_BAD_ACCESS. Phineas Pegler 15:48, 11 January 2007 (EST)

How does it run compared to the Linden Labs' release? David Frantisek 00:22, 12 January 2007 (PST)
Even slower. I'll pop in some more memory and see if that helps. Phineas Pegler 10:06, 12 January 2007 (EST)

Compiling/Running on X64_64 Linux

The alpha release runs, but building it is a whole different story. I'll update this section as I progress. My distro is Ubuntu Edgy 6.10.

- Linden build

- Library build xmlrpc-epi after patching, and 'automake -a -c' to fix depcomp problem, Im getting:

libtool: unrecognized option `--tag=CC'

build the project w/ gcc 3.3 or 4.0?

In the section "Building the Viewer", it describes setting up and building, then changing your gcc back to 4.0. When I tried building with gcc set to 3.3, I got lots of errors about std::isfinite not defined (sorry I did not copy the exact error).

When I set gcc to 4.0 first, then built, I was able to build the client a-ok. I was thinking of reversing the two paragraphs (gcc 4.0 first, then build project) -- but I don't have any knowledge of the gcc, so figured I'd ask here.

none of any of the external libraries I could build with GCC 3.3, did some research and gcc 3.3 does not work correctly on intel macs Eelke Folmer

Changes to Boost instructions?

I downloaded the Boost libraries, and noticed that the instructions for may need to be changed. Boost extracts to "<working directory>/boost_1_33_0" rather than "<working directory>/boost-1.33.0". Note underscores in place of hyphens and dots. As hinted by the instructions, I was able to build boost, but none of the files to be copied in the "Copy the Libraries" section appeared to have been built. Should this section of the instructions be updated? Simon Nolan 20:07, 2 April 2007 (PDT)

Aparently copying the header files is enough to get it running Eelke Folmer OS 10.4.9

I updated the section to reflect that the name uses underscores and not dash and periods. --Mokelembembe Mokeev 04:56, 7 April 2007 (PDT)


Building the Viewer

I skipped building the libraries myself because of the numerous errors I get so Instead i tried to build the client. I get 4 errors all related to missing language text files eg. "copying german.lproj/language.txt (1 error)" "pbxcp:language.txt no such file or directory"

I get the same errors for the english, korean and japanese languages. does anyone have any idea what causes this?Eelke Forder 16:14, 14 April 2007 (PDT)

Quick fix, Xcode - resources - languages.txt delete the japanes, german and korean languages.txt in there. put a blanco languages.txt in the english.lproj subfolder, this works, deleting all four won't.


Compiling the WindLight Branch

Please bear with me if some of the "obvious" things are not related to the WindLight branch at all, but to my own inexperience in getting such a complex application to compile under XCode; my own programming experience under Xcode has been very limited and some things should be obvious to expert developers on XCode, specially to the ones who compile SL every day :)

The WindLight source code can be gotten through svn co http://svn.secondlife.com/svn/linden/branches/2007/windlight_1-17-0. Since I was not sure about naming conventions, in my case I got it under the windlight_1-XX-X directory and just symlink'ed linden to it. Not feeling too bold about recompiling all libraries manually, I simply got the pre-compiled ones from LL directly; they do the job (I mean, I've compiled zlib a million times under a few architectures, there is no more thrill in compiling it one more time :) ).

Now the tweaks. In my system at least, XCode (2.4 and not 2.4.1; GCC is 4.0.1 build 5363) cannot find the header files for OpenGL. I've added /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include manually to SCM > Build > Header Search Paths and that fixed one issue.

The next is getting the source to find the appropriate "glh" header files. Bad news; this seems to be some specific Nvidia <-> GL helper library, and although LL gently included two files (glh_linear.h and glh_genext.h), the rest of the header files (and there are a lot of them) are sadly missing. Fortunately, after some searching, I found these are in a package called nvparse which is downloadable from http://developer.nvidia.com/attach/8196. Then you just have to make sure the many files using the GLH library can find those header files; as the source moves from the original place to the build directory, it means that you'll have to put at least two symlinks for those. Possibly a better approach is to place these under /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include as well and let SL find them there. 'Important:' LL's has his own glh_linear.h and glh_genext.h, so make sure you don't overwrite them!

To make matters worse, LL's own header files override the equality/inequality operator on line 179/180 of glh_linear.h. Tsk. GCC 4.0.1 doesn't like it, so commenting it out will give you a clean compile, but who knows what this will break further on.

viewer_manifest.py complains that it cannot create the ~/linden/indra/newview/build/Deployment/Second Life.app directory; this might be simply a permissions problem, but after creating it manually, the rest worked flawlessly towards a build. It took about an hour or so on my iMac with 2 GHz Intel Core 2 Duo and 1 GB of RAM.

When running the recently compiled version of Second Life, it complained that it couldn't open Contents/Resources/app_settings/windlight/clouds2.jpg and crashed-on-login. Sure thing, that file is not there; fortunately, I could easily copy it from my previous installation of WindLight. For the ones who have deleted it by mistake, I've uploaded it here:

clouds.jpg needed for a WindLight build

Performance is obviously terrible, less than half of the regular viewer, and perhaps 30-50% worse than the official (previous) WindLight version, very likely because of using the open source JPEG2000 decoder and not the commercial one that LL uses but cannot distribute. But... I got nice-looking weather back for machinimas, and that makes me happy! :)

Gwyneth Llewelyn 04:32, 16 June 2007 (PDT)

I should just add that the icon for the SL logo that appears on the application on the Dock is not there either. Simply get secondlife.icns from any of your SL installations and drop it under Contents/Resources

Gwyneth Llewelyn 16:55, 16 June 2007 (PDT)

Fmod

Of course the cp instructions for the fmod libs will not work, as the target directories are not yet created at that stage and cp will not create them. Lanita Wingtips 16:24, 12 November 2008 (UTC)

And there is also the fact that CMake does not find Fmod files at the suggested folders, so the instructions should look more like this:

$ mkdir -p linden/libraries/universal-darwin/lib_release
$ mkdir linden/libraries/universal-darwin/lib_debug
$ mkdir linden/libraries/include
$ cp -p ../fmodapi375mac/api/inc/*.h linden/libraries/include
$ lipo -create fmodapi375mac/api/lib/libfmod.a fmodapi375mac/api/lib/libfmodx86.a -output linden/libraries/universal-darwin/lib_release/libfmod.a
$ cp -p linden/libraries/universal-darwin/lib_release/libfmod.a linden/libraries/universal-darwin/lib_debug/libfmod.a

Lanita Wingtips 15:27, 13 November 2008 (UTC)

slplugin

In slplugin.cpp there are commented out instructions that once uncommented print an slplugin.log. The location of the log is at (kokua viewer example): /Users/<username>/kokua(could be viewer-release)/build-darwin-i386/newview/RelWithDebInfo/ At this point right click on the application. My case Kokua (could be Second Life). Show package contents. Contents/Resources/llplugin The file slplugin.log resides here. Nicky Perian 15:43, 7 February 2014 (PST)