We just released the latest version of the Solaris Crash Analysis Tool. For more information, see the Solaris CAT Blog. Many folks have asked why we are developing and supporting Solaris CAT when Solaris provides mdb. There's several reasons: mdb kind of assumes the user has some knowledge of the Solaris kernel, mdb is more of a debugger than an analysis tool, Solaris CAT provides aggregation features (thread scanners, device aggregaters, streams checkers, etc) that mdb does not provide, and, frankly, Solaris CAT makes analyzing Solaris crashes easier. I look at it like the editor wars for the 80's and 90's - I prefer vi but have no problem with folks using Emacs. Use what you like but don't complain about those who use something different.
Friday Feb 06, 2009
Tuesday Jan 13, 2009
Well I have yet to get a successful build from SL 1.21 or 1.22. I just haven't had the time to dive into the new build environment. Luckily, Linden Lab released a bunch of updates for SL 1.20.17. Therefore, you can download updated packages using the links Solaris 10 and OpenSolaris/Nevada.
I'll try to work on the newer versions of the viewer as soon as I get the next release of Solaris CAT out the door.
Wednesday Oct 15, 2008
Since Linden Lab released security patches for their viewer, Clark has made builds available to everyone. Those URLs are: 1.20.17 for Solaris 10 & 1.20.17 for Nevada/OpenSolaris. Since this is a security-related build, all prior versions have been removed.
I've also seen updates on all the Solaris related PJira issues saying they are now pending! Sweet! That means that we'll soon have the Solaris patches integrated into the viewer trunk.
Lastly, I have yet to start on the port of 1.21. I just haven't had the time to dive into the cmake changes. If anyone has a set of Viewer related cmake patches for Solaris, please share.
Tuesday Aug 19, 2008
I got a surprise on Saturday. I opened my mailbox and discovered a letter from a patent certificate company congratulating me on my latest patent. What? I submitted that puppy four years ago! Man! that's a long time to wait. What's the patent on? It protects the idea I developed for aggregating devices to find a common cause for hardware problems. It's the method I implemented in the Solaris Crash Analysis Tool's dev busy command and I documented in this article. The patent is available for review on Free Patents Online.
Now to bug the powers that be at Sun for my certificate and $$$ reward 
Since a few people have moved to newer builds of Solaris Nevada they noticed that the locale packages changed. On Solaris, the Second Life viewer requires locale support for ISO 8859-1 and ISO 8859-15. These are the default locales expected by the viewer and in older SL versions, not having them has led to crashes. On Solaris 10, these locales are bundled in SUNWi15cs, SUNWi1cs, & SUNWnamos. Now for the tricky part. Somewhere around Nevada/OpenSolaris build 91, the packages for this locale support changed from those listed above to SUNWlang-common-extra & SUNWlang-en-extra. If you are using a newer build of Nevada, just make sure you have SUNWlang-common-extra & SUNWlang-en-extra installed. I've modified the package dependencies for Nevada/OpenSolaris. The downloads for viewer version 1.20.15 are available for Nevada/OpenSolaris and Solaris 10.
While I have your attention, you may have noticed that the mp3 plugin is missing from builds of Nevada/OpenSolaris on builds after b83. That surprised a lot of us and it was a conscious decision to protect Solaris licensees from litigation. (Since I love my job at Sun, I'll keep my personal feelings about this decision out of this blog.) If you need a mp3 plugin, a free one is available from various sources including this place. You can also build the default plugins yourself. The source is available at the GStreamer Home Page. I advise you to pay special attention to the licenses documented in the packages. In a nutshell, just because something is free to download does not mean it's free to use!
Friday Jul 18, 2008
I've had a few requests for SL 1.20.14.0 since it includes the "skinning project" and of course, Clark was anxious for the patches so here's the packages (thanks Clark!): Solaris 10 and Nevada/OpenSolaris. I've been working hard to free up enough time to update the jira issues with my latest patches and promise I'll get them up there ASAP.
Wednesday Jul 16, 2008
Well it's been five long years since an update of Solaris Crash Analysis Tool (CAT) was released to the public and I'm happy to report that the Solaris CAT Development Team (John, Paul, and I) were finally given the time to work through the red tape and get a new release out. Yes! Solaris CAT 5.0 is available for immediate download from here. This new version not only supports the newer releases of Solaris, namely Solaris 10 and OpenSolaris/Nevada, it also suports both SPARC and x86/x64 architectures and includes commands that support zones, the Solaris Volume Manager, ZFS, Sun Cluster, plus many more features. I'd recommend reading the Release Notes (/opt/SUNWscat/docs/index.html) for both this release and Release 4.2 to get yourself up to date on everything that has been changed, fixed, and added in 5.0. Enjoy and please let the Solaris CAT Team know how you like the tool by commenting on our blog or sending email to SolarisCAT_Feedback@Sun.COM. I'm also happy to report that we'll be trying to release versions once every six months.
What is Solaris CAT? It's a Solaris kernel crash dump (and live kernel) access tool that provides simple intuitive commands which can be used to quickly analyze crash dumps. It's developed by Sun kernel engineers (those who support customers) who analyze kernel core files for a living. It's different from mdb because its geared more towards analysis instead of debugging. It's also different from mdb because it's development is done as a hobby by a handful of people and is officially an "unsupported" tool (though if one finds a bug and let's us know, we likely fix it quickly.) And so you are confident, SolarisCAT is used thousands of times a month here at Sun. Therefore, it gets plenty of testing
As an example of Solaris CAT's power, the following is from a system that was hanging and where the user interrputed the kernel with a "break". As you can see below, the dev busy command not only isolated the devices that were "hanging", it also discovered that an interface card, /SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3, is likely the culprit. Without that analysis, the engineer working on that crash dump may waste time trying to chase "failing" devices before the interface card or lpfc was identified as the culprit.
SolarisCAT(vmcore.1/8U)> dev busy
Scanning for busy devices:
sd321 @ 0x3000537db30(scsi_disk), DEVICE BUSY, un_ncmds: 20
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@0,27
sd322 @ 0x3000537d370(scsi_disk), DEVICE BUSY, un_ncmds: 20
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@0,28
sd323 @ 0x3000537cbb0(scsi_disk), DEVICE BUSY, un_ncmds: 1
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@0,29
sd324 @ 0x3000537c3f0(scsi_disk), DEVICE BUSY, un_ncmds: 1
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@0,2a
sd327 @ 0x3000542cbb8(scsi_disk), DEVICE BUSY, un_ncmds: 20
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@0,26
sd343 @ 0x3000546abd8(scsi_disk), DEVICE BUSY, un_ncmds: 1
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@0,1b
sd347 @ 0x30005456be0(scsi_disk), DEVICE BUSY, un_ncmds: 3
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@0,1f
sd348 @ 0x30005456040(scsi_disk), DEVICE BUSY, un_ncmds: 2
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@0,20
sd349 @ 0x300054493a8(scsi_disk), DEVICE BUSY, un_ncmds: 4
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@0,21
sd351 @ 0x30005436050(scsi_disk), DEVICE BUSY, un_ncmds: 9
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@0,23
sd353 @ 0x300054a8fd8(scsi_disk), DEVICE BUSY, un_ncmds: 5
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@0,3f
sd358 @ 0x30005476450(scsi_disk), DEVICE BUSY, un_ncmds: 3
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@0,40
sd432 @ 0x300054a8818(scsi_disk), DEVICE BUSY, un_ncmds: 9
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@a,5
sd433 @ 0x300054a8058(scsi_disk), DEVICE BUSY, un_ncmds: 1
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@a,6
sd436 @ 0x30005496c00(scsi_disk), DEVICE BUSY, un_ncmds: 1
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@a,9
sd476 @ 0x30005534850(scsi_disk), DEVICE BUSY, un_ncmds: 6
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3/sd@1,5a
By aggregating "busy" device paths, the following devices
should also be investigated:
/SUNW,Sun-Fire/ssm@0,0/pci@1c,700000/lpfc@3
Scanning for threads in biowait:
103 threads in biowait() found.
threads in biowait() by device:
count device (thread: max idle time)
36 32,2570(sd321,2) (0x3001c0a5ba0: 1 hours 35 minutes 13.49 seconds) /dev/dsk/c1t0d39s2(swap)
25 32,2578(sd322,2) (0x2a1002cbd20: 1 hours 35 minutes 13.95 seconds) /dev/dsk/c1t0d40s2(swap)
19 32,2618(sd327,2) (0x300979fa460: 1 hours 35 minutes 13.49 seconds) /dev/dsk/c1t0d38s2(swap)
4 237(vxio),47006 (0x300171d9ca0: 1 hours 35 minutes 13.04 seconds) /play/oradata003
4 237(vxio),47008 (0x30085682e60: 1 hours 35 minutes 13.26 seconds) /play/oradata005
2 32,3812(sd476,4) (0x30015f12600: 1 hours 35 minutes 13.48 seconds) /opt/tools
2 237(vxio),99003 (0x30014a40180: 1 hours 35 minutes 13.47 seconds) /test/archive
2 237(vxio),10000 (0x3001c0a45a0: 1 hours 35 minutes 13.31 seconds) /appl/oradata001
2 237(vxio),47004 (0x30099665b80: 1 hours 35 minutes 11.33 seconds) /play/oradata001
1 237(vxio),10004 (0x3001de53900: 1 hours 35 minutes 13.31 seconds) /appl/oradata005
1 237(vxio),51000 (0x3005c6d83c0: 1 hours 35 minutes 13.49 seconds) /bcv/prod/transfer
1 32,3808(sd476,0) (0x3001a310c00: 49 minutes 16.60 seconds) /crash
1 237(vxio),99001 (0x3009c625bc0: 9 minutes 4.67 seconds) /test/peace
1 237(vxio),99002 (0x30015f36e20: 1 hours 26 minutes 42.69 seconds) /test/oracle
1 237(vxio),8003 (0x30005fa1620: 1 hours 34 minutes 52.51 seconds) /test/redo4
1 237(vxio),10002 (0x3001405ce40: 1 hours 35 minutes 13.31 seconds) /appl/oradata003
Scanning for procs with aio:
proc PID fd dev state count
==== ====== == === ===== =====
0x3001710d520 25667 408 237(vxio),99008 pending 1
SolarisCAT(vmcore.1/8U)>
Wednesday Jun 18, 2008
I thought is was about time to let folks know about the latest Solaris build of the Second Life viewer, version 1.20.10.0. Clark Dastardly has made them available at Package for Solaris 10 and Package for OpenSolaris. Streaming audio support returns in this release but only in Solaris Nevada/OpenSolaris because Solaris 10's GStreamer still needs to be updated. Please let me know if you hit any bugs/problems/issues and please give me some feed back. I would love to know how the Solaris version behaves compared to Linden Lab's official builds - yes, we still need streaming video (waiting on Sun's official AAC decoder) and Voice (waiting on Linden Lab to release a Vivox client for Solaris) so there's no need to tell me about these.
I'll try and get the patches posted to their related Second Life Jira tickets within the next few days.
Tuesday May 06, 2008
I finally had time to work with
VirtualBox (VBox) on my Macbook Pro the other day and since I ran into a couple snags I thought I'd post a short blog entry that provides some of the details. But first here are two other blogs that helped:
- Alan Burlison's Kicking both tyres together - VirtualBox and Indiana
- Rodney Campbell’s OpenSolaris Developer Preview 2 (Indiana) under VirtualBox on MacBook Pro…
I've tested VBox with the newly released OpenSolaris 2008.05 as well as Solaris 10 Update 5 and both run well.
Here are some notes that may help:
- If you read Alan's and Rodney's blog entries first, note that there is no need to install a newer network driver with VirtualBox 1.6. All you need to do is set the network device to "Intel PRO/1000 MT Desktop (NAT)". Also don't be caught by the mistake I made and try using ping to test the network connection. The VBox documentation clearly states that ICMP through the VBox virtual network stack is unreliable.
-
If you want a higher res screen, the default in VBox is 1024x768,
before starting the VirtualBox guest run:
VBoxManage setextradata "Solaris 10" "CustomVideoMode1" "1280x10240x24"
Where "Solaris 10" is the name of VBox vm and I'd recommend bumping the video memory to at least 64MB. I had to do this for each vm I created.
Note that the xorg.conf that Alan provides on his blog currently causes X to crash on the latest Nevada and OpenSolaris. I'm currently trying to figure out why.
- Set the network device emulation to "Intel PRO/1000 MT Desktop (NAT)"
- If you are installing Solaris for the first time, be sure to link or mount the Solaris iso image as the CDROM
- Start the VM and run through the standard Solaris install.
-
On Solaris 10:
- start a terminal session (not CDE or Gnome)
- disable CDE with "/usr/dt/bin/dtconfig -d"
- enable gnome desktop login (this gives you Xorg X11 server) with "svcadm enable gdm2-login"
- if you want a higher resolution desktop, use the VBoxManage command above
and install the attached xorg.conf into /etc/X11/xorg.conf (remember this bombs
terribly on Nevada/OpenSolaris) and log out and back in to restart X
So far I've tested X and networking with OpenSolaris 2008.05 and Solaris 10 U5.
As proof and from the sick puppy category, here is a screen shot off my Macbook Pro 17 with OpenSolaris running in one VBox instance and Solaris 10 U5 installing in another (click the picture for a full sized version):
Wednesday Feb 27, 2008
It's been months since I gave everyone an update on the Second Life viewer on Solaris. So here it is...
First, you need to know that the viewer is now available outside Sun. The pre-built packages are now available off of amazonaws.com, see Jeff Barr's blog entry for the details. I want to thank these folks for putting the effort in and making the viewer available to everyone.
If you want to build the viewer yourself, please refer to my past posts on building the libraries and tweaking SConstruct. As for the patches themselves, I've submitted them under Second Life "jira" issues and, as such, I ask that you download the patches from there. The issue numbers are:
- VWR-4800 - Use Solaris kstats when running on Solaris
- VWR-4802 - add definitions for stricmp and strnicmp
- VWR-4804 - Add necessary includes to llsys.h
- VWR-4805 - add LL_SOLARIS to #if in lltimer.h
- VWR-4806- llvfs changes
- VWR-4807 - add Solaris to #if in llglstubs.h
- VWR-4808 - featuretable_solaris.txt patch
- VWR-4809 - llfloaterreporter.cpp
- VWR-4810 - add Solaris required changes to llappviewer_linux.cpp
- VWR-4811 - add LL_SOLARIS to #if in llfilepicker.cpp
- VWR-4812 - include llstring.h in llfloateranimpreview.cpp
- VWR-4813 - include llstring.h to llfloaterimagepreview.cpp
- VWR-4814 - include llstring.h in llfloaternamedesc.cpp
- VWR-4815 - add Solaris specific platform to llfloaterreporter.cpp
- VWR-4816- include Solaris in llstartup.cpp
- VWR-4817 - don't include gMovieMaker on Solaris builds
- VWR-4818- add LL_SOLARIS to #if in llfilepicker.cpp
- VWR-4819 - add LL_SOLARIS to linux #if in moviemaker.h
- VWR-4820 - add solaris_tools to newview
Seriously, save yourself a bunch of time, and just take the pre-built packages mentioned above. Attempting a SL build can induce sleeplessness, outbursts of frustration, and possible tears.
My plans for the future work on the Second Life viewer depends priorities here at Sun. I have plenty of other work on my to-do list so we'll see. But if I do get the thumbs up, I plan on doing the following:
- Reduce the number of libraries included in the SL package in favor of those bundled with OpenSolaris under the Project Indiana initiative.
- Add patches to the cmake branch of the Second Life build tree. yes, that's right, SCons is no longer going to be used to build SL. I'm not sure I like cmake but it does provide a good cross-platform (Windows, OS X, Linux, and Solaris) build environment.
- See what, if anything, can be done to get the Linux version of the Vivox client working under Solaris. I'm thinking that perhaps Project Indiana may help here.
Wednesday Oct 03, 2007
This entry covers the steps required to build version 1.18.3.5 of the Second Life client on a Solaris 10 x86 and OpenSolaris x86 system.[Read More]
Wednesday Jul 11, 2007
Well folks, it has been a fun couple of months. After getting the SecondLife viewer ported to Solaris x86 I thought the move to SPARC would be a breeze. NOT!!! It turns out there were quite a few CPU alignment assumptions made throughout the code that caused headaches. But before I get into that I need
to put in a plug for
gccfss (gcc for SPARC System) which is a great tool to use if you have a huge application like the SecondLife viewer, have a community of folks who share development duties and therefore tie you to gcc, but want superior performance on SPARC.
gccfss is the gcc 4.0.x front end on top of the Sun Studio 12 backend. You therefore can compile code that assumes gcc-isms while still able to use the SPARC performance tools. I also need to plug Sun Studio 12 which has many gcc compatible features. If you own the application in question I highly advise you to invest the time in getting your code to compile in Sun Studio 12. There are far too many reasons to describe here so look at
the SunStudio overview page for more details. In either case, gccfss and SunStudio 12 are free so you'd be a fool if you didn't invest the time and give them a try. SunStudio is available for Solaris and most Linuxes.
OK, now back to SecondLife. After deciding to go with gccfss, I still had data alignment to deal with. Alexey Starovoytov came to the rescue advising me to add asm("ta\t6"); to SL's main(). This little trick enables a corrective trap handler on SPARC that will fix unaligned references. For those who need a deeper definition, John Harres provided the following:
Since this is a user land trap, it ends up in the user side of the trap table, which effectively adds 0x100 to the trap number. This ends up in:GOTO(.fix_alignment); /* 106 do unaligned references */in the trap table. It ends up setting p_fixalignment in the proc structure, which then is noticed during trap() if you're taking a T_SYS_RTT_ALIGN trap from user land. WIth that flag set this results in the call to do_unaligned(). Therefore, each time the program takes an alignment trap, do_unaligned() is called. One would expect the overhead to be rather minimal unless one is doing a lot of unaligned references.
If you need a source reference, Alexy pointed me to simulator.c as well as a discussion of trap 6 in the Sun Studio Performance Library doc.
I can't thank Alexy and John enough for their help.
Once I got passed the alignment problems I then ran up against Open GL Library issues on SPARC. The SL deveopers assume the GLext, originally called the GL Extensions for Linux Library, exists. Well currently on SPARC GLext does not and at the moment I've #ifdef'ed around these calls to get a clean compile and wound up making the viewer ugly. This is what I'll be attacking next.
Here's a few other things that were done to the Viewer for Solaris compatibility:
-
All the libraries required by the viewer but not bundled with Solaris were built for the SPARC using the same methods described for the x86 port. They were then copied into the
linden/libraries/sparc-sunos5directory for the SCONS build. -
The Lindens have dedicated pages of source to figuring out the type of x86 processor is in use. Instead of using their assembler calls and because said assembler does not apply to SPARC I used
getisax(2)to extract the cpu info. The cpu kstats were used to determine the processor brand and clock rate while on x86/x64, getisax(2) was used to further define which CPU extensions were in use. - The in window color depth was reduced from 32 to 24 bits on SPARC to allow compatibility with more of the frame buffers available on SPARC.
- The Viewer assumes the X.org X-Window System server. It currently references the X.org server logs to determine how much memory is configured on the GPU. A true kludge. On SPARC X.org is not yet supported so this code is useless and it's ignored. According to its documentation the SDL library provides such information but when one inspects the SDL source one finds the variable but discovers it's not ever set. Doh! Therefore for now, the viewer assumes the maximum amount of memory is available, the default action when it can't be determined by any other means.
-
One of the largest stumbling blocks was big endian conversions on SPARC. I spent weeks trying to band-aid my way through fixes. Then last week, as he was adding the Solaris changes to the master repository at Linden Labs, Soft Linden discovered that a header file was missing from one of their message passing sources - a LL bug that I missed. That header was the one that defined
LL_BIG_ENDIAN. Once I added that include everything fell together and I proceeded to rip out my endian changes. Without Soft's help I would have wasted a ton of more time "fixing things". Thanks Soft! - The SL community has offered an openal alternative to the FMOD audio library. Using the patches offered for openal I was able to add audio support to Solaris. There is a rumor that there may be an FMOD available for Solaris in the near future so that option may be viable soon as well.
Lastly, I got approval from Sun Legal to sign the Linden Labs Contributor Agreement and am now officially able to give LL copies of the Solaris patches. I was asked not to distribute any 3rd party libraries outside Sun so I'm hoping someone else will build a version for general distribution. Soft Linden has been working with me to merge those changes into the official SVN repository so they should be available to everyone soon.
If you are interested in building the SL viewer on your own, you should start by reviewing the pages at the SecondLife Open Source Portal.
Monday Apr 30, 2007
Back in the beginning of April I was tasked to get a
Second Life (SL) client running under Solaris. Luckily,
Siva had done some preliminary work so I thought all I had to do was pull the source and start a compile, right? NOT! Second Life is not a trivial build. One problem I ran up against is that
Open Second Life does not stay up to date with the source available from Linden Labs(LL) and earlier this month LL decided they need to ensure clients were current so they imposed a new serial number check during authentication. Hence, I was forced to pull a copy of the latest client source from the
SecondLife wiki page and merge in the changes required to support Solaris. Since then, I also added a bunch of my own changes to better support Solaris.
Before I get into the discussion of how the build went, I should point out that Linden Labs has a detailed discussion of how to build their client on Linux at their Wiki site that one should read carefully before even attempting to do their own SL client build.
Let's first discuss the build environment. The Second Life source is supplied in two pieces: the source itself and the art work. One needs to download both and then inflate them on top of each other. Next, the build does not use make. It uses SCons which is a Python-based script that does essentially what make does. Instead of a Makefile one has to maintain a SConstruct file. It's a fairly easy environment to get used to and like makefiles, one has to be VERY careful about indentation. In the Second Life client, the SConstruct file is in linden/indra.
As discussed in the
Wiki build notes, There are several third party libraries required to build the client. I built these using --prefix=/opt/opensl so that they all got placed in a directory that I could control and so that I knew these libraries would not conflict with anything in /usr/local or the other "freeware" delivered with Solaris in either /usr, /usr/sfw, or /opt/sfw . Here's the notes I took while working with each library:
- curl - you need 7.16.x (SFWcurl from the Companion CD delivers 7.10.3)
-
boost - a C++ library, it's huge
configure --with-python=/usr/sfw/bin/python --prefix=/opt/opensl - Apache2 (for apr, aprutil) - I just built Apache2 from the source and copied the libraries I needed.
-
xmlrpc-epi 0.51
configure --prefix=/opt/opensl
You also need to use gmake.
IMPORTANT:xmlrpc-epi uses an internal data structure called "queue". Unfortunately that structure conflicts with the Solaris STREAM queue so I changed xmlrpc-epi'squeuetoXMLRPCqueue. You won't notice the conflict until you start compiling the SL client. - libjpeg - I used the one bundled with Solaris, see /usr/lib/libjpeg*
-
Vorbis 1.1.2 & Ogg 1.1.3, (SFWvorb is version 1.0 which is too old but SFWoggl looked fine.)
configure --with-ogg=/opt/opensl --prefix=/opt/opensl -
ElfIO 1.0.3
./configure --prefix=/opt/opensl
The make does not build a shared library and LL recommend doing so (I didn't.) -
openjpeg 1.1.1
./configure --prefix=/opt/opensl
LL wiki page recommended patches for openjpeg but the latest source includes these changes. - expat 2.0.0
-
curl 7.16.1
configure -- with-ssl=/usr/sfw --prefix=/opt/opensl - SDL 1.2.11 (SFWsdl = 1.2.5 which is too old.)
-
bison 2.3 (SUNWbison is too old.)
This one I built and installed in /usr/local/bin and I made sure the SConstruct file used this version.
Once I got everything built, I copied the necessary includes and libs into linden/libraries/"platform" where platform is either i686-sunos5 or sparc-sunos5. (I need to note that I've only just started a SPARC build. More on it in a future blog.)
the SCons command line I used was:
TEMP_BUILD_DIR="/tmp/danaf/secondlife-build" scons DISTCC=no BTARGET=client \
BUILD=releasefordownload
When ready to create a "releasable" a copy, the SConstruct uses a packaging script called package_client.sh inside a tools directory under linden/indra/newview. Of course in my case this meant having to create a solaris_tools directory and the files/scripts associated with it. I used the Linux equivalents as a reference and quickly decided that it would be better to create a packaging script that created a Solaris pkg instead of the Linux tarball approach. I also decided to hide the client executable in a separate exec directory so that all people will find in the bin are things that can run as is.
Some folks at Linden Labs have said that they'd be happy to work my changes back into their source tree so I'll be sending them "patches" in a day or so.
Lastly, and as proof, here's a couple images off my Ultra-40. The first is the good ol' SecondLife login screen and the second was taken from within the Sun Pavillion.
| Second Life Login Screen |
|
| Inside the Sun Pavilion @ Second Life |
|