Nekochan Net

Today I uploaded 3 new builds from a current cvs checkout of Mozilla 1.8 source base to incoming and asked nekonoko to put it in beta.

neko_firefox-2.0.0.22pre_mar2012.tardist
neko_seamonkey-1.1.20pre_mar2012.tardist
neko_thunderbird-2.0.0.25pre_mar2012.tardist

The thunderbird version includes a working lightning 0.9 for Irix. I have also build a working sunbird 0.9pre, which will be available, when I have build an icon for it. All builds are -O3 optimized and should bring some performance improvements compared with existing -O2 builds.

The calendar tools had some trouble with the xml module of the javascript code. This is the reason, why the lightning extension will not work with existing neko_thunderbird builds. The workaround was to put this object to the list of -O1 optimized files. If here is an experienced C++ coder, it would be a good idea to look at the javascript engine. If it is possible to build all of it with -O3 optimization, we would have some more performance improvements.

I just made a rsync with nekochan.net, here you go:

ftp://ftp.nekoware.de/beta/neko_firefox ... 12.tardist
ftp://ftp.nekoware.de/beta/neko_seamonk ... 12.tardist
ftp://ftp.nekoware.de/beta/neko_thunder ... 12.tardist

_________________

Nice! Is there a large difference between -O3 and -O2 build in end-user performance?

_________________

On my Tezro it is a noticeable difference. But don't expect too much, just try it.

_________________

Oh-oh. The sqlite problem rears its ugly head

What's your situation with sqlite3 ?

Just for fun, if you're going to play with this, here are the flags neko used to build an r16-optimized firefox ...

I used the libsqlite3 which comes withe the mozilla source. I guess you have neko_slite3 installed. I can build the package with neko_sqlite3, but then we have a new dependency. If you add the firefox directory to your LD_LIBRARYN32_PATH it should work.

Did you checkout this:

viewtopic.php?f=7&t=16726024&start=15&hilit=sqlite

_________________

_________________

That's a no-no. I'm not going to get into it because I'd screw up the reasoning, but check with canavan or bplaa-yai or dexter1. Bad bad idea.


Unfortunately, I have Alzheinmer's It was 2.0.0.22pre but which one, I am not certain. There have been several floating around in nekoware. At the moment I backed up to the 2.0.0.20 optimized version that neko built for r16 and it is working fine with nekoware sqlite3.

The mozilla people had this idea before, I looked at run-mozilla.sh and they exactly do this before they start the binary. We have a -rpath option at some point, I will look after that.

_________________

If it's from Mozilla, you know it's a bad idea !


Ja, that's the approved method of dealing with crap software that needs an LD_LIBRARYN32_PATH setting. At least if you put it in a wrapper script it doesn't mess with everything else. There are programs which get screwed up by a user-wide LD_LIBRARYN32_PATH environment setting. It's not that rare, either.

I'd still like to know what the heck is going on with the sqlite3 thing. I have a 2.0.0.22 fireflop and this 2.0.0.20 optimized fireflop I'm using at the moment that aren't bothered by the sqlite3 which is in /beta. Others have had problems (altho it's Pentium, so we also need to take that into account

Hamei, I think it's really bad style to quote me with words I didn't write and never would write. I have great respect for all people involved in the mozilla project. I am sure we will find a solution for the sqlite3 problem.

_________________

Okay, sorry. I think they are incompetent buffoons but will shut up about it for at least a week since you ask.

About your tardist, I removed the neko_sqlite3 and your firefox works fine. It seems a touch faster but that could be my imagination. More important, if it doesn't crash as often that would be great.

Altho I have javascript turned off so maybe I'm not a great tester of your fix

If you figure out what the other neko 2.0.0.22pre does to avoid the problem, then sqlite3 and fireflop could co-exist ...

Just wondering ... how come you disabled pthreads ?

Diegel, maybe you could patch the firefox shell script in the package to explicitly load the libsqlite3.so from the firefox directories, similar to what I do with an additional wrapper script below. I wouldn't have used this _RLDN32_LIST if I had gotten this to work just with LD_LIBRARY or RUN_PATHS.

Thank's for the hint, this diff for /usr/nekoware/lib/firefox-2.0.0.22pre/run-mozilla.sh will work:

I will build a new packages with this change next week. I have also to fix a problem with extensions in the new seamonkey.

Is there any more general way to prefer a path for rld?

_________________

Update : Used this for a day now and it does seem a little more responsive than the version in nekoware and so far, no crash. One thing I do notice tho is that I am getting those annoying "This script is not responding" popups again. If you have a moment you might ask Pete what he did to disable those .... I don't think it's anything in about:config because that hasn't changed.

Does seem a little better. Thank you. I know this isn't an easy app to get right. If you compile for a broader audience, you might consider dropping back the cpu optimizing flags. Not everyone has an r16k ... (But probably everyone who browses on SGI needs at least that to run Firefox ! )

A lot of it was just cooling off on the optimization - that's why I went back to -O2 (fewer reported problems overall). -O3 is just a bit too aggressive.

_________________
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.