[sldev] [VIEWER] 64 bit status and open source components

[Robin Cornelius]

On 9/16/07, David Fries <david at fries.net> wrote:

> > Its pretty much a swap a few #include "foo.h" to #include <foo.h> and
> > fiddle with the scons file slightly.  Oh and debian has libapr in
> > "apr-1.0/" not "apr-1/" and openjpeg and libxml-rpc got dropped into
> > /usr/include and not /usr/include/<subdir>/ so i patched the includes
> > as it was quick and easy.
>
> I looked into the apr-1.0 vs apr-1 and the apr source installs to
> apr-1 but the Debian package build process overrides that to set it to
> apr-1.0 on compile.  I submitted a bug report noting it.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=442375

Ah cool, that explains that one, I'm going back through the build
process to see what the minimum number of changes necessary is to get
a complete build. I think i am now down to some tweaking in the
SConstruct file so perhapses the time has come to look at the preview
release and see what has changed there as it may have sorted some of
these issues out.

> Bring up the texture decode debug information, control-shift-3, that
> might give a clue if a texture is getting stuck.  Edit an object
> (doesn't have to be yours) and go to the texture tab, that will give
> that texture priority for decoding.  But you say that the UI textures
> are fine?  They are also compressed textures, so OpenJPEG must be
> working for them.
>
> That's just for information.  Try clearing your cache (or move the
> directory out of the way) and see if things work.
>

I hosed the entire .secondlife directory, and it cleared the fault. I
had not does this before as this is a new install of debian on a clean
system and the first time I have been able to run secondlife on this
system was with my 64bit build. But i assume one of the failed
attempts to run a 32bit version or the rpm packaged 64bit version
caused upset somewhere and left some crud!

Many thanks

Robin