On 2025/02/22 18:46, Volker Schlecht wrote: > On 2025-02-22 15:25, Stuart Henderson wrote: > > > > > # XXX needs bumps every time :- > > > > > -SHARED_LIBS += sqlite3 37.30 # 8.6 > > > > > +SHARED_LIBS += sqlite3 38.00 # 8.6 > > > > Should be 38.0 not 38.00. > > That explains the problems with finding it, I suppose?
I haven't tested, but I do think this is likely. > > > To 37.31, at least the handful of builds in your list that I tested, > > > works again. > > > I noticed that when updateing, libsqlite3.so.38.00 did not replace > > > libsqlite3.so.37.30, but libsqlite3.so.37.31 did. > > > > Updates keep a version around that's compatible with existing programs > > built against the old library version. > > > > 37.31 is supposed to be compatible with programs built against 37.30 > > so no need to keep 37.30. > > So I guess, 37.31 would have been the right choice anyway... fingers crossed > that the bulk build goes through. > > Thanks for the explanations! Yes, I think so. The lib versions are a bit of a nuisance in this port. We bump them because of checks recommended in https://sqlite.org/c3ref/libversion.html which some downstram users do: "Cautious programmers might include assert() statements in their application to verify that values returned by these interfaces match the macros in the header, and thus ensure that the application is compiled with matching library and header files" https://sqlite.org/src/forumpost/5a3b44f510df8ded suggests that the ABI is generally compatible across sqlite v3: "Ideally, the soname stays stable for so long as a library retains a compatible ABI. In this project, the ABI has never(?), within the v3 lifetime, introduced an incompatible ABI, and so its historical soname of libsqlite3.so.0 is still legitimate" but when someone makes that suggested check (e.g. as done by subversion), there is indeed an ABI compatibility change with *every* sqlite release.
