[oi-dev] sqlite update

[Aurélien Larcher]

  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.