[sldev] [VWR] Linux 64bit llmozlib success!

[Robin Cornelius]

I think I am a trained circus performer now as i have jumped through so
many hoops. But I have finally got llmozlib going on 64 bit linux in
both the viewer logon screen and using the ubrowser test application.

Compiling llmozlib needs some additional gcc flags, i used

-fno-rtti and -fno-execptions

To prevent a linker time missing symbol due to run-time type information
(and no-exceptions probably does very little but is usualy used with
-fno-rtti)

Firstly there is some fundimental initialisation problem which seems to
stop the viewer from showing pages but causes ubrowser to crash.
Somewhere deep with in the mozilla code the layout/generic/nsFrame.cpp
InitBoxMetrics() function is NOT getting called which results in a crash
when attempting to use a pointer that function should initialise. The
nsFrame::Init() DOES call InitBoxMetrics() if IsBoxWrapped() returns
TRUE. It clearly doesn't and i have not dug that deeply to find out what
goes on there, but JUST calling InitBoxMetrics() in nsFrame::Init()
regardless seems to create a usable llmozlib and mozilla combination. On
the viewer it seems to result in no logon page and just some corrupt
mess for the web profiles.

I am wondering if this is the same issue that left me with a black
screen when i tried to use my system xulrunner etc as that resulted in
crashes and or black screen where html should have been.

The ubroswer test app also has a few issues.
uBrowser::windowPosToTexturePos() does some divide by 0's because
mTextureWidth and mTextureHeight are zero. Setting these to be 1 when
they are initialised and not zero seems to solve this until a real width
and height is loaded.

Now ubroswer will load and display HTML on a openGL shape. But
javascript is broken and displays as in-line text. This does not effect
the sl-viewer which seems to display google home page etc ok in web
profiles just ubroswer does not do this.

And don't forget the viewer will look for the llmozlib code in
linden/libraries/x86_64-linux/lib_release_client during build but still
look for the runtime files in
$viewerdir/app_settings/mozilla-runtime-linux-i686 as its hardcoded.

And watch out if you leave various llmozlib.a or llmozlib.so etc lying
around, that is a cause for very many happy moments.

I am wondering now if we can NOT staticly link llmozlib to the viewer
but instead link libprofdirserviceprovider_a.lib to llmozlib and keep
llmozlib as a shared library separate from the viewer as llmozlib is
developed seperatly there is no need for this hard dependency. In fact
why not have a run time dependency that if it finds llmozlib.so (and
friends) it uses it if not it falls back to what it does now? this may
not be such a good idea depending on your future plans but moving it to
a shared library should have no inpact.


Regards

Robin





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071104/74b87390/signature.pgp