On Sat, Feb 22, 2025 at 06:10:08PM +0000, Stuart Henderson wrote: > 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.
Yes it is the case, although the variety of failure modes is quite unexpected. > > > > 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. It is only a minor bump required. About half the packages built in the last 5 hours without fallout. ~55 hours more for the remainder, although at this point I don't expect to see a lot of fallout. > 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. > Great.
