IRIX and Software

Nekoware gdb install problem - Page 2

canavan wrote:
Maybe your skills are superior to mine, so maybe you have a solution to install a nekoware sqlite and still get a functioning nekoware firefox?

i could install sqlite and see what/where is the conflict ...

_________________
r-a-c.de
foetz wrote:
i could install sqlite and see what/where is the conflict ...

While you are rooting around in there, see if you can figure out how to compile Fireflop to use an external sqlite. That would be pretty nifty.

_________________
lemon tree very pretty and the flower very sweet ...
foetz wrote:
canavan wrote:
Maybe your skills are superior to mine, so maybe you have a solution to install a nekoware sqlite and still get a functioning nekoware firefox?

i could install sqlite and see what/where is the conflict ...

yup that's the classic double lib error. firefox does provide its own libsqlite3.so and does obviously not work with the one from nekoware.

as hamei said one way would be to compile firefox using an external sqlite. it'd then however always require that.
excluding /usr/nekoware/lib from the paths does not work if your firefox relies on other nekoware.
renaming the neko sqlite lib before starting firefox and rename it back once firefox is running works but is a bit cumbersome.

so since firefox is obviously much more popular than sqlite best would probably be to install it to an isolated place.

_________________
r-a-c.de
foetz wrote:
yup that's the classic double lib error. firefox does provide its own libsqlite3.so and does obviously not work with the one from nekoware.

renaming the neko sqlite lib before starting firefox and rename it back once firefox is running works but is a bit cumbersome.

How about ditching the fireflop sqlite and replacing it with a link to the nekoware one ?

_________________
lemon tree very pretty and the flower very sweet ...
give it a try :)

_________________
r-a-c.de
foetz wrote:
foetz wrote:
canavan wrote:
Maybe your skills are superior to mine, so maybe you have a solution to install a nekoware sqlite and still get a functioning nekoware firefox?

i could install sqlite and see what/where is the conflict ...

yup that's the classic double lib error. firefox does provide its own libsqlite3.so and does obviously not work with the one from nekoware.

as hamei said one way would be to compile firefox using an external sqlite. it'd then however always require that.
excluding /usr/nekoware/lib from the paths does not work if your firefox relies on other nekoware.
renaming the neko sqlite lib before starting firefox and rename it back once firefox is running works but is a bit cumbersome.

so since firefox is obviously much more popular than sqlite best would probably be to install it to an isolated place.


I'm a little confused as to how this happens in the first place, firefox is launched by a shellscript (shellscripts calling shellscripts in fact) and the final one finds out where the firefox libraries live and prepends its own lib path to the appropriate LD_LIBRARY*_PATH, so the bundled sqlite should always be chosen.

_________________
:Octane: halo , oct ane
N.B.: I tend to talk out of my ass. Do not take it too seriously.
duck wrote:
I'm a little confused as to how this happens in the first place, firefox is launched by a shellscript (shellscripts calling shellscripts in fact) and the final one finds out where the firefox libraries live and prepends its own lib path to the appropriate LD_LIBRARY*_PATH, so the bundled sqlite should always be chosen.

I suspect that it's linked against libraries that have their own -RPATH built in, and that messes with the resolution of libsqlite3.so.1. I thought that there may be a problem during configure/build/link that could cause firefox to pick up /usr/nekoware/lib as an rpath from the link flags from some library's .la file, but the built in RPATH is apparently properly ordered:
Code:
$ elfdump -L -long /usr/nekoware/lib/firefox-3.0.19/firefox-bin |grep PATH
[64]    DT_RPATH                       (4733548) /usr/nekoware/lib/firefox-3.0.19:/usr/nekoware/lib:/opt/build/pango-1.12.4/pango/.libs:/usr/nekoware//lib
/opt/build/pango-1.12.4 shouldn't be there :P

_________________
r-a-c.de
Fools rush in, so I took on the job ...

With older fireflops, an installed sqlite was definitely a problem. Been there, done that.

With the diegel fireflop 3.0.19, I first installed neko sqlite3-3.7.10. Ran FF. FF3 started up fine, did a little bit of bookmark organizing, added one or two, moved one or two, no crash.

Improvement One noted.

Then I renamed the ff3 sqlite libs to junk_1 and junk_2, made links from the neko_sqlite libs instead. That is also working, apparently fine. Not too much testing but added, deleted, and moved a few bookmarks with (so far) no evil results.

Improvement Two noted.

So apparently there is no reason that FF can't use an installed sqlite. Those Mozilla people really need a good slapping.

Code:
urchin 11# ldd firefox-bin
<abbreviated>
libcairo.so.3  =>        /usr/nekoware/lib/firefox-3.0.19/libcairo.so.3
libfreetype.so.7  =>     /usr/nekoware/lib/libfreetype.so.7
<abbreviated>
libintl.so.9  =>         /usr/nekoware/lib/libintl.so.9
libsqlite3.so.1  =>      /usr/nekoware/lib/firefox-3.0.19/libsqlite3.so.1
libfastm.so  =>  /usr/lib32/libfastm.so
< more abbreviated >
libc.so.1  =>    /usr/lib32/libc.so.1
libsqlite3.so  =>        /usr/nekoware/lib/firefox-3.0.19/libsqlite3.so
libpixman-1.so.1  =>     /usr/nekoware/lib/libpixman-1.so.1
libglitz.so.2  =>        /usr/nekoware/lib/libglitz.so.2
libpng12.so.0  =>        /usr/nekoware/lib/libpng12.so.0
<truncated>

Code:
urchin 13# pwd
/usr/nekoware/lib/firefox-3.0.19
urchin 15# ls -l
<abbreviated>
lrwxr-xr-x    1 root     sys            35 Mar 31 10:52 libsqlite3.so -> /usr/nekoware/lib/libsqlite3.so.1.6
lrwxr-xr-x    1 root     sys            35 Mar 31 10:51 libsqlite3.so.1 -> /usr/nekoware/lib/libsqlite3.so.1.6
lrwxr-xr-x    1 root     sys            35 Mar 31 10:51 libsqlite3.so.1.6 -> /usr/nekoware/lib/libsqlite3.so.1.6
<truncated>

More testing would probably be in order but so far ....

edit : while I was rooting around in there, I noticed a libcairo in the fireflop tree. Hmm. Replaced that with a link to the nekoware libcairo as well. It is working but ... maybe a bad idea ? Is this going to get into the gcc-> MIPSPro Incompatibility Syndrome ? If anything, it's (subjectively) a little quicker than before.

edit ii : It is probably not a good idea to link the nekoware libcairo and libsql into their respective homes in firefox, and this is most likely a coincidence, but after three days have not had one crash since I made that change. Normally I'd get one bus error or std:bad alloc per day, even with the new pango (Lots fewer crashes than with the old pango tho.)

Hmmm. Not complaining but strange ...

_________________
lemon tree very pretty and the flower very sweet ...