[sldev] Bugs in the Mac OS X Source tree

[Barney Boomslang]

Oh, I have working versions of both the non-voice and the voice NB
builds. And no, mozilla is not the culprit, it's the way the
executable is linked :)

I have a rough writedown (mostly for myself, to remember for next
build) of what I did here:

http://radio-boomslang.shacknet.nu/~bb/archives/2007/09/16/index.html#e2007-09-16T19_05_06.txt

I have the nagging feeling I forgot one step, so it might need an
adaption later when I find out what that was. If you run along those
things and discover something missing, give me a shout.

I'm currentlyl giving the voice variant a good usage to see what
problems show up (non so far) and a friend runs the non-voice one and
we look into that, too (a few little quirks so far). When all is fine,
I will make some updaters with applescript that can turn an official
RC app into a NB version - I think that's the best way to do the
distribution on the Mac, as only the executable and the llcommon lib
and a few helper files (the ..xml stuff for the voice version) need to
 be distributed and not all the special stuff like libllkdu or the
icons or whatever.

But for now I am just plain happy to enjoy a current viewer with less
bugs and better useability than the official RC ;-P

bye, Barney

On 9/17/07, Trevor Powell <trevor at gridbug.org> wrote:
> I have a working OS X build of Nicholaz's 18g build..  I've worked through
> each of the issues below..
>
> The problem with cursors_mac is just that the directory itself is missing;
>  all the files that should be in it are dumped into the root of the mac
> resources directory, instead of into a 'cursors_mac' directory inside that
> directory.  That one was easy to fix, locally.
>
> The giant executables seem to be caused by linking in the Mozilla library.
>  Or at least, when I removed it from the linking process, it yielded no
> linking errors and the final executable came down from >1gig to the 70ish
> megs that you'd expect.
>
>
> I haven't yet looked at the post-voice source releases on the Mac (except
> to plunder some the pre-built png libraries that they forgot to include in
> the pre-voice source releases)..  I'd release my builds, except that they
> suffer from a weird behaviour;  textures seem to load far, far slower than
> they do in the official Linden version.  Slow enough that it's not at all
> uncommon for me to hang around in a single area and still have blank grey
> textures on many things twenty minutes later.  It's as though it wasn't
> retrying to grab the textures if a packet got lost, or something.  Haven't
> had a chance to delve more deeply into it yet, though.  And in all
> honesty, the solution may come by moving up to a post-voice source
> release;  LL seem to have fixed a bunch of problems in the Mac source
> releases post-voice.
>
>
> Trevor
>
> > Hey Nicholaz,
> >
> > yes, that's exactly what I did. llthread.cpp, changed to
> > APR_THREAD_MUTEX_NESTED and all is golden.
> >
> > bye, Barney
> >
> > On 9/16/07, Nicholaz Beresford <nicholaz at blueflash.cc> wrote:
> >>
> >> I just looked a bit deeper.  I think the issue is to
> >> replace all APR_THREAD_MUTEX_DEFAULT to
> >> APR_THREAD_MUTEX_NESTED.
> >>
> >> Or of course undo my patch with the EasyCacheWriter.
> >>
> >>
> >> Nick
> >>
> >>
> >> Second Life from the inside out:
> >> http://nicholaz-beresford.blogspot.com/
> >>
> >>
> >> Barney Boomslang wrote:
> >> > Hey Mac-heads,
> >> >
> >> > please check the following jira bugs and vote if you think we
> >> > Mac-heads should be able to do a full working build of the client, too
> >> > ;)
> >> >
> >> > This one is critical: the cursors_mac directory is missing and
> >> > viewer_manifest.py willingly ignores that, so we are missing several
> >> > mouse cursors in the build (I wrote about that some time ago):
> >> >
> >> > http://jira.secondlife.com/browse/VWR-2482
> >> >
> >> > The next one is about the giant executables the project file produces
> >> > with Deployment or Universal builds:
> >> >
> >> > http://jira.secondlife.com/browse/VWR-2483
> >> >
> >> > This one is the missing SecondLife icon for the application. This
> >> > might be intentional of LL, but then there should be a word on it.
> >> >
> >> > http://jira.secondlife.com/browse/VWR-2484
> >> >
> >> > Maybe an idea: put a readme in the source tree that actually states
> >> > _why_ stuff is missing? And put comments into viewer_manifest.py about
> >> > why parts of it are commented out, like the kakadu library - that one
> >> > is a no-brainer, since we don't have redistribution rights for that.
> >> > Oh, but you still deliver it (the library) with your libraries
> >> > download ...
> >> >
> >> > bye, Barney
> >> > _______________________________________________
> >> > Click here to unsubscribe or manage your list subscription:
> >> > /index.html
> >>
> > _______________________________________________
> > Click here to unsubscribe or manage your list subscription:
> > /index.html
> >
> >
>
>
>