Basically, I don't see how Firefox2 could possibly be working with sqlite above 3.4.2, since it relies on functions that are, quite simply, gone; Pentium's problem should affect anyone using Nekoware Firefox and the beta sqlite.

It turns out I forgot about that a long time ago, since I have put a wrapper script for the wrapper script earlier in the PATH that just works around this nonsense by forcing firefox to just use the libsqlite3.so that it was compiled against and that was shipped with it.. One should assume that the original wrapper script would have been more than enough, given that a proper RPATH should do the trick.

I did some debugging with this last night. If sqlite's libs are removed from /usr/nekoware/lib, firefox will use its internal lib in /usr/nekoware/lib/firefox*/libsqlite.so. I wasn't able to influence firefox to prefer that lib over the system libs; I suspect there is a stray rpath (which are evil and cause lots of trouble) in a dependent library thats causing this problem as rpaths cause LD_LIBRARY*_PATH to be ignored. I'll trace firefox's excution tomorrow if I can and see if I can find the stray lib ...

This is a version that I believe nekonoko built. Not sure if it's in /current or if it is one in his /contribs section

This firefox does not show any disastrous behavior that can be attributed to sqlite3.

Debugging last night makes me think its not with firefox itself, but another library that links against sqlite3 and then was built against the new one with the silent ABI break. I didn't get very far located which firefox rdepend broke though.

hamei wrote:Did you get all of nekoware installed, like you were trying to do, pent ?

Yeah, I got that done. Sure gives you one hell of a selection.

Yes, it does ... but I've never been a fan of a bunch of stuff that you don't need. In this case, you may have something interfering with your firefox. Tardist testing for nekoware does not have the massive user base that BeOS did .... we're liable to miss a few software incompatibilities..