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? ;)

The results follow:

The mystery deepens. Why that scan check fails there, but on no other system i've tried (some 6 different Unixen flavors, counting, Cygwin, and msys2). i will certainly try figure that out this weekend.

It's probably an artifact of my ignorance but I am confused about the config.log that is output during the configure process!

That's output from the configure script's feature checks, written there by the underlying configure script framework (not by us). It's normally not useful until, e.g., debugging why the search for -lfoo, or linking a configure-generated dummy app to it, mysteriously doesn't work.

As shown in my previous reply it contains a couple of instances of failed code. Are they expected or irrelevant? ;)

Completely expected - those were configure-time checks which failed.

`package vsatisfies [ package provide Tcl ] 8.6-.

One more test for you, please:

$ echo "puts [package vsatisfies [ package provide Tcl ] 8.6-]" | tclsh
1
$ echo $?
0

That is essentially what the failing test is doing, but i'm just spitballing here - the problem is still a mystery.

bchapman@DESKTOP-3Q38QFQ:~$ echo "puts [package vsatisfies [ package provide Tcl ] 8.6-]"
DESKTOP-3Q38QFQ bchapman % puts [package vsatisfies [ package provide Tcl ] 8.6-]
1
DESKTOP-3Q38QFQ bchapman %
bchapman@DESKTOP-3Q38QFQ:~$ echo $?
0

This shows the test as run on my WSL Debian including the full bash prompts. I have no idea why DESKTOP-3Q38QFQ bchapman leads the output of the echo command on the second line and hope that it doesn't invalidate the results! ;o

~/builds/sqlite-autoconf-3500100$ cd tea/
~/builds/sqlite-autoconf-3500100/tea$ ./configure
Configuring build of Tcl extension sqlite 3.50.1 ...
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.
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
ICU support is disabled.
Feature flags...
  + fts3
  + fts4
  + fts5
  + geopoly
  + rtree
  - 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-

Sigh! ;(

/usr/bin/tclsh8.6 check failed: package vsatisfies [ package provide Tcl ] 8.6-

We don't yet have a fix for that and still don't know why that specific environment breaks there when the same thing works when invoked from the CLI.

This is still on my to-fix list, but it's not at slot #1 and won't make any progress until the reason for the discrepancy is understood (or, barring that, blind luck).

We don't yet have a fix for that and . . . .

No whining here! LOL I fully accept your priorities and am grateful to you and the whole team for the time and expertise you all contribute.

In the interim I expect no problem with using the preferred method for building the SQLite Extension for Tcl as shown below:

~$ sqlite3 --version
3.50.1 2025-06-06 14:52:32 b77dc5e0f596d2140d9ac682b2893ff65d3a4140aa86067a3efebe29dc914c95 (64-bit)
~$ tclsh
% package require sqlite3
3.50.1

In the interim I expect no problem with using the preferred method for building the SQLite Extension for Tcl as shown below:

:-D

The part of the tea configuration which tells it to enforce the "vsatisfies" check has been removed for the time being, until this is figured out. This unfortunately also means that it will configure on systems with tcl 8.5, and avoiding that was the whole point of the vsatisfies check: we know that it will build just fine with Tcl 8.5 but it won't pass the test suite.

As you may be aware, Debian 13 Trixie which will probably become the stable version sometime this year contains Tcl 8.6.16 and currently lists TCL 8.6 as the default version so it seems likely that an eventual solution would be welcomed by the Debian user base. :)