DBD::SQLite Fails Tests on Perl 5.8

[fsbruva]

Commit f236c5c updated DBD::SQLite to 1.58. However, this caused tests to fail on Perl 5.8, because DBD::SQlite 1.58 uses the functions note() and explain(). These functions first appeared in Test::More 0.82, and shipped with Perl 5.10. The fact that DBD:SQLite misstates its prerequisite version of Test::More is a separate known bug.

This leaves several options:

1. Revert Perl 5.8 to use DBD::SQlite 1.34 (Not recommended - fragments SQLite versions)
2. Disable tests for DBD::SQlite for Perl 5.8 (Not recommended - tests are good)
3. Drop support for Perl 5.8 (Not really an option - listed for completeness)
4. Add correct Test::More version as external dependency via cpan in documentation (Less desirable - we already build all our own dependencies)
5. Add Test::Simple to the build (Recommended - most recent version of Test::Simple is only 283 KB)

What is the requested course of action I should implement and submit a PR for?

[mherger]

TBH I doubt we'll ever build for 5.8 again. We have what we have today. Any forward development can ignore it if needed. I doubt there's still any reasonable system out there using it.

In fact I doubt we'll ever run the full build for any of the existing platforms any more.

[fsbruva]

So - go with option 2 listed above?

Is it worthwhile to display a banner to the user that build support for 5.8 (and maybe some other versions) is slated for deprecation, and will be completely removed in Mar 2020 or something? That might trigger any users out there that need support for 5.8 to come forward.

Are your statistics/metrics able to let you know how many users are running LMS using the various Perl versions?

[mherger]

I don't think it's worthwile, no. 5.8 had its share of known issues with LMS (or the other way around). Feel free to drop 5.8 support if you feel like it.

[fsbruva]

Feel free to drop 5.8 support if you feel like it.
Excellent. I'll do that soonest.

Also - can you help me understand the genesis of the "Perl hunt" section of the script? Why are specific files and locations checked? Is it reasonable that if people are using perlbrew, they would issue the appropriate perlbrew use perl-5.12.4 prior to running the script? Or asked another way: Why doesn't the script assume that the perl found in PATH is the one we want to use?

[mherger]

Also - can you help me understand the genesis of the "Perl hunt" section of the script? Why are specific files and locations checked? Is it reasonable that if people are using perlbrew, they would issue the appropriate perlbrew use perl-5.12.4 prior to running the script? Or asked another way: Why doesn't the script assume that the perl found in PATH is the one we want to use?

TBH: no idea. I can only assume that whoever started this did indeed not perlbrew use .... And there are systems which have multiple Perl versions installed and in the search path (see the comment about 5.14 on macOS).

[pehy59]

OpenSuse Tumbleweed, Perl 5.38.2, buildme.sh aborts
2024-02-10_buildme.log
with
... Running Mkbootstrap for SQLite () chmod 644 "SQLite.bs" "/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- SQLite.bs blib/arch/auto/DBD/SQLite/SQLite.bs 644 cc -c -I. -I/home/pehy/perl/slimserver-vendor-public-8.4/CPAN/build/5.38/lib/perl5/x86_64-linux-thread-multi/auto/DBI -I../build/include -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wl,-Bsymbolic -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -Wall -pipe -DVERSION=\"1.58\" -DXS_VERSION=\"1.58\" -fPIC "-I/usr/lib/perl5/5.38.2/x86_64-linux-thread-multi/CORE" -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS3_PARENTHESIS -DSQLITE_ENABLE_COLUMN_METADATA -DSQLITE_ENABLE_ICU -DNDEBUG=1 -DHAVE_USLEEP=1 SQLite.c cc -c -I. -I/home/pehy/perl/slimserver-vendor-public-8.4/CPAN/build/5.38/lib/perl5/x86_64-linux-thread-multi/auto/DBI -I../build/include -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wl,-Bsymbolic -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -Wall -pipe -DVERSION=\"1.58\" -DXS_VERSION=\"1.58\" -fPIC "-I/usr/lib/perl5/5.38.2/x86_64-linux-thread-multi/CORE" -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS3_PARENTHESIS -DSQLITE_ENABLE_COLUMN_METADATA -DSQLITE_ENABLE_ICU -DNDEBUG=1 -DHAVE_USLEEP=1 dbdimp.c cc -c -I. -I/home/pehy/perl/slimserver-vendor-public-8.4/CPAN/build/5.38/lib/perl5/x86_64-linux-thread-multi/auto/DBI -I../build/include -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wl,-Bsymbolic -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -Wall -pipe -DVERSION=\"1.58\" -DXS_VERSION=\"1.58\" -fPIC "-I/usr/lib/perl5/5.38.2/x86_64-linux-thread-multi/CORE" -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS3_PARENTHESIS -DSQLITE_ENABLE_COLUMN_METADATA -DSQLITE_ENABLE_ICU -DNDEBUG=1 -DHAVE_USLEEP=1 sqlite3.c make test failed, aborting

[pehy59]

Another Problem when compiling Version 8.3, buildme.sh stops with:
`...

In Datei, eingebunden von SQLiteXS.h:17:
dbdimp.h: Auf höchster Ebene:
dbdimp.h:151:1: Warnung: »newUTF8SVpvn« definiert, aber nicht verwendet [-Wunused-function]
151 | newUTF8SVpvn(char *s, STRLEN len) {
| ^~~~~~~~~~~~
dbdimp.h:141:1: Warnung: »newUTF8SVpv« definiert, aber nicht verwendet [-Wunused-function]
141 | newUTF8SVpv(char *s, STRLEN len) {
| ^~~~~~~~~~~
dbdimp_virtual_table.inc: In Funktion »perl_vt_Eof«:
dbdimp_virtual_table.inc:473:12: Warnung: »eof« könnte uninitialisiert verwendet werden [-Wmaybe-uninitialized]
473 | return eof;
| ^~~
dbdimp_virtual_table.inc:449:16: Anmerkung: »eof« wurde hier deklariert
449 | int count, eof;
| ^~~
sqlite3.c: In Funktion »sqlite3DefaultRowEst«:
sqlite3.c:105088:3: Warnung: diese »if«-Klausel beschützt nicht … [-Wmisleading-indentation]
105088 | if( pIdx->pPartIdxWhere!=0 ) a[0] -= 10; assert( 10==sqlite3LogEst(2) );
| ^~
In Datei, eingebunden von sqlite3.c:12706:
sqlite3.c:105088:45: Anmerkung: … diese Anweisung, aber letztere ist verwirrend eingerückt, als wäre sie abhängig von »if«
105088 | if( pIdx->pPartIdxWhere!=0 ) a[0] -= 10; assert( 10==sqlite3LogEst(2) );
| ^~~~~~
sqlite3.c:105089:3: Warnung: diese »if«-Klausel beschützt nicht … [-Wmisleading-indentation]
105089 | if( a[0]<33 ) a[0] = 33; assert( 33==sqlite3LogEst(10) );
| ^~
sqlite3.c:105089:45: Anmerkung: … diese Anweisung, aber letztere ist verwirrend eingerückt, als wäre sie abhängig von »if«
105089 | if( a[0]<33 ) a[0] = 33; assert( 33==sqlite3LogEst(10) );
| ^~~~~~
sqlite3.c: In Funktion »sqlite3SelectNew«:
sqlite3.c:118836:10: Warnung: Funktion liefert möglicherweise Adresse einer lokalen Variablen zurück [-Wreturn-local-addr]
118836 | return pNew;
| ^~~~
sqlite3.c:118798:10: Anmerkung: hier deklariert
118798 | Select standin;
| ^~~~~~~
make: *** Keine Regel vorhanden, um das Ziel „../build/lib/libicuuc.a“, benötigt von „blib/arch/auto/DBD/SQLite/SQLite.so“, zu erstellen. Schluss.
`
the logfile is attached:
2024-02-10_buildme8.3.log

[mherger]

Wouldn't 8.4 work out of the box? At least on x86_64?