Hi,
Is it possible that this change broke firefox ?
After updating it segfaults at the start.
/1:
open64("/home/alarcher/.mozilla/firefox/cxqk6vqc.default/places.sqlite-journal",
O_RDWR|O_CREAT|O_LARGEFILE|O_CLOEXEC, 0644) = 39
/12: clock_gettime(4, 0xF3FFED28) = 0
/1: fstat64(39, 0x080338D4) = 0
/12: clock_gettime(4, 0xF3FFED78) = 0
/1: getuid() = 101 [101]
/1: fstat64(39, 0x080338D4) = 0
/12: clock_gettime(4, 0xF3FFED28) = 0
/12: clock_gettime(4, 0xF3FFED78) = 0
/1: Incurred fault #6, FLTBOUNDS %pc = 0xFA76B984
/1: siginfo: SIGSEGV SEGV_MAPERR addr=0xFA76B984
/1: Received signal #11, SIGSEGV [caught]
/1: siginfo: SIGSEGV SEGV_MAPERR addr=0xFA76B984
/12: clock_gettime(4, 0xF3FFED28) = 0
/1: lwp_sigmask(SIG_SETMASK, 0xFFBFFEFF, 0xFFFFFFF7, 0x000000FF,
0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
ldd /usr/bin/firefox gives:
libsqlite3.so.0 => /usr/lib/firefox/../libsqlite3.so.0
libsqlite3.so.0 (sqlite_3.7.5) => (version not found)
How could I report in a better way ?
Best regards,
Aurelien
Le 28/08/13 12:42, Alexander Pyhalov a écrit :
Hello.
I'm looking at sqlite update now. Binary incompatibility introduced by
proposed update to 3.7.17 was evident - some API calls were not
present in resulting library. Now I have it seems compatible library
and have a question on symbol versioning. In Oracle JDS
sqlite_3.7.14.1 symbol version is defined to identify latest sqlite.
We update further - to 3.7.17. Does it make sense to introduce separte
symbol version for every API change (sqlite_3.7.15 - include
sqlite3_errstr, sqlite_3.7.17 - include sqlite3_strglob) or just
introduce version including all new symbols?
Personally, I don't see sense in creating separate sqlite_3.7.15 version.
_______________________________________________
oi-dev mailing list
[email protected]
http://openindiana.org/mailman/listinfo/oi-dev
