I had no problems building Versions 3.49.1 and 3.49.2 this way.

Those used a completely different build process under the hood (the GNU Autotools), which we no longer support.

What am I missing?

Please show us which configure flags you're using. i've built the tcl extension literally hundreds of times the past couple of months on a handful of different OSes and have not seen that error. It doesn't reproduce for me but you might be using a flag which takes a different code path to trigger it.

Error: can't read "vvcheck": no such variable

i've found the source of the problem (tcl's "scan" command only sets the target vars on success, a detail its docs tactfully sidestep), and can reproduce it "by hand" in tclsh, but still can't trigger it via the configure script.

This trivial patch should get you up and running again:

Index: autosetup/teaish/core.tcl
==================================================================
--- autosetup/teaish/core.tcl
+++ autosetup/teaish/core.tcl
@@ -525,11 +525,11 @@
         set tclsh [get-define TCLSH_CMD]
         set vsat "package vsatisfies \[ package provide $pkg \] $vcheck"
         set vputs "puts \[ $vsat \]"
         #puts "*** vputs = $vputs"
         scan [exec echo $vputs | $tclsh] %d vvcheck
-        if {0 == $vvcheck} {
+        if {![info exists vvcheck] || 0 == $vvcheck} {
           proj-fatal -up $tclsh "check failed:" $vsat
         }
       }
       if {$::teaish__Config(vsatisfies-error)} {
         set vunsat \

That will be checked in after some more testing.

This trivial patch should get you up and running again:

On second thought, no it won't: it will fail fatally because because the vsatisfies check is failing.

Are you running Tcl 8.5 by any chance? If so, that won't work. The extension builds in 8.5 but does not work properly so we dropped support for 8.5.

Please show us which configure flags you're using.

>./configure

Are you running Tcl 8.5 by any chance?

% puts $tcl_patchLevel
8.6.13

As you can see Debian version 12.11 Bookworm [the current stable release] has Tcl 8.6.13.

Those used a completely different build process under the hood (the GNU Autotools), which we no longer support.

Alas, I am a victim of progress! LOL

Alas, I am a victim of progress! LOL

Elimination of the final remnants of the autotools from our build chain was its own progress. We now have a build process we understand, instead of one based on voodoo rituals.

Please note this disclaimer in the TEA README.txt:

If you want to use this TEA builder and it works for you, that's fine. But if you have trouble, the first thing you should do is go back to using the canonical Makefile in the SQLite source tree.

Since the canonical build is used in SQLite's day-to-day maintenance, that's the "supported" build. The TEA build is a historical remnant which we make "an honest effort" to keep running, but make no guarantees for. (Nor do we still document its existence anywhere prominent, AFAIK. The main tclsqlite docs refer only to the canonical build approach.)

Please try the build with the provided patch, but my suspicion is that it will fail, saying:

... /path/to/your/tclsh check failed: package vsatisfies [ package provide Tcl ] 8.6-

because that's the error you were apparently about to receive when it instead crashed while trying to emit that error (the joys of irony!). That check can be bypassed altogether by removing the line from teaish.tcl which says "-vsatisfies 8.6-", and it would be helpful to know if that works (assuming the patch doesn't). On half a dozen environments i've not been able to trigger the code path you're landing in except by intentionally telling it to use a Tcl 8.5 installation.

We now have a build process we understand, instead of one based on voodoo rituals.

So I see! ⍨ I am a little surprised by this problem because Debian is the basis for many other distributions [or so it's said] and is not uncommon. ;)

Please note this disclaimer in the TEA README.txt

Yes thanks, I have resorted to the canonical supported build process in the past but being lazy I am always looking for the easier path! LOL

Please try the build with the provided patch. . . . .

To be sure that I understand, is that the

if {![info exists vvcheck]

0 == $vvcheck} {

replacement line in your reponse 3? If so, I will try later today and let you know! ;)

I am always grateful for the exceptional contributions of the Sqlite Team and really appreciate the time you are spending on my little problem!

To be sure that I understand, is that the

if {![info exists vvcheck] 0 == $vvcheck} {

Correct. That will at least fail with an informative message.

Thank you for reporting this problem and testing a fix!

I think that I have correctly patched core.tcl. Here is the fossil diff:

Index: autosetup/teaish/core.tcl
==================================================================
--- autosetup/teaish/core.tcl
+++ autosetup/teaish/core.tcl
@@ -520,11 +520,11 @@
         set tclsh [get-define TCLSH_CMD]
         set vsat "package vsatisfies \[ package provide $pkg \] $vcheck"
         set vputs "puts \[ $vsat \]"
         #puts "*** vputs = $vputs"
         scan [exec echo $vputs | $tclsh] %d vvcheck
-        if {0 == $vvcheck} {
+        if {![info exists vvcheck] || 0 == $vvcheck} {
           proj-fatal -up $tclsh "check failed:" $vsat
         }
       }
       if {$::teaish__Config(vsatisfies-error)} {
         set vunsat \

Here is the abridged output from the subsequent attempt to configure:

>./configure
Configuring build of Tcl extension sqlite 3.50.0 ...
C compiler... cc
C++ compiler... c++
Build C compiler...cc
Checking for stdlib.h...ok
Checking for a suitable tcl...
Checking for tclsh9.1...no
Checking for tclsh9.0...no
Checking for tclsh8.6.../usr/bin/tclsh8.6
Using Tcl 8.6 from /usr.
. . . .
. . . .
  - session
  - update-limit
  + json
Library feature flags: -DSQLITE_3_SUFFIX_ONLY=1 -DSQLITE_ENABLE_BYTECODE_VTAB=1 -DSQLITE_ENABLE_DBPAGE_VTAB=1 -DSQLITE_ENABLE_DBSTAT_VTAB=1 -DSQLITE_ENABLE_DESERIALIZE=1 -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS5 -DSQLITE_ENABLE_GEOPOLY -DSQLITE_ENABLE_MATH_FUNCTIONS -DSQLITE_ENABLE_RTREE -DSQLITE_OMIT_LOAD_EXTENSION=1 -DSQLITE_THREADSAFE=0
FATAL: [teaish__configure_phase1]:  /usr/bin/tclsh8.6 check failed: package vsatisfies [ package provide Tcl ] 8.6-

And here is the config.log from that attempt:

Invoked as: ./configure --teaish-extension-dir=.
Tclsh: /usr/bin/tclsh
Failed: cc -O2 conftest__.c -o conftest__
/usr/bin/ld: /tmp/ccUbU127.o: in function `main':
conftest__.c:(.text.startup+0x5): undefined reference to `deflate'
collect2: error: ld returned 1 exit status
child process exited abnormally
============
The failed code was:
extern void deflate(void);
int main(void) {
deflate();
return 0;
}
============
Failed: cc -O2 conftest__.c -o conftest__
conftest__.c:1:13: warning: conflicting types for built-in function ‘ceil’; expected ‘double(double)’ [-Wbuiltin-declaration-mismatch]
    1 | extern void ceil(void);
      |             ^~~~
conftest__.c:1:1: note: ‘ceil’ is declared in header ‘<math.h>’
  +++ |+#include <math.h>
    1 | extern void ceil(void);
/usr/bin/ld: /tmp/ccXzPdgx.o: in function `main':
conftest__.c:(.text.startup+0x5): undefined reference to `ceil'
collect2: error: ld returned 1 exit status
child process exited abnormally
============
The failed code was:
extern void ceil(void);
int main(void) {
ceil();
return 0;
}
============

Here is the abridged output from the subsequent attempt to configure:

That is exceptionally curious. Please try this with tclsh:

$ tclsh
% package vsatisfies [ package provide Tcl ] 8.6-

1

The output "should" be 1 for any installation of 8.6 or higher. If it emits any value other than 1 (which yours appears to be doing), please also post the output of:

% package provide Tcl
8.6.14

Please try this with tclsh:

The results follow:

$ tclsh
% package vsatisfies [ package provide Tcl ] 8.6-
1
% package provide Tcl
8.6.13

FWIW 8.6.13 is the version of Tcl included in Bookworm the current stable Debian release.

It's probably an artifact of my ignorance but I am confused about the config.log that is output during the configure process? As shown in my previous reply it contains a couple of instances of failed code. Are they expected or irrelevant?