See https://wiki.tcl-lang.org/page/Tcl+9+functions+using+Tcl%5FSize

That page lists the functions, which use Tcl_Size either as return value or as parameter type.
It may help C/C++ extension developers to port their code to Tcl 9.

Regards,
Paul

* Paul Obermeier <obermeier@poSoft.de>
| See https://wiki.tcl-lang.org/page/Tcl+9+functions+using+Tcl%5FSize
>
| That page lists the functions, which use Tcl_Size either as return
| value or as parameter type. It may help C/C++ extension developers to
| port their code to Tcl 9.

How does the compiler 'know' whether Tcl_Size is a defined type?
It would be nice if the above page either contained directly or via link
the preferred way to use Tcl_Size in code which should compile on both
tcl 8.[67] and tcl 9.x.

R'

Am 23.08.2023 um 10:50 schrieb Ralf Fassel:
> * Paul Obermeier <obermeier@poSoft.de>
> | See https://wiki.tcl-lang.org/page/Tcl+9+functions+using+Tcl%5FSize
>>
> | That page lists the functions, which use Tcl_Size either as return
> | value or as parameter type. It may help C/C++ extension developers to
> | port their code to Tcl 9.
>
> How does the compiler 'know' whether Tcl_Size is a defined type?
> It would be nice if the above page either contained directly or via link
> the preferred way to use Tcl_Size in code which should compile on both
> tcl 8.[67] and tcl 9.x.
>
> R'

I currently use the following approach to make my extensions compile with 8.6, 8.7 and 9.0:

Change all appropriate variables or return values from int to Tcl_Size
and add the following typedef in an extension header file:

#if TCL_MAJOR_VERSION < 9
typedef int Tcl_Size;
#endif

And as an optional short-cut for often used statements:
#define TCL_NULL (Tcl_Size *)NULL

Ex: Tcl_GetStringFromObj(obj, TCL_NULL) instead of Tcl_GetStringFromObj(obj, (Tcl_Size *)NULL);

If anybody has a better solution, feel free to speak up.

Paul

Am 23.08.2023 um 11:49 schrieb Paul Obermeier:
> Am 23.08.2023 um 10:50 schrieb Ralf Fassel:
>> * Paul Obermeier <obermeier@poSoft.de>
>> | See https://wiki.tcl-lang.org/page/Tcl+9+functions+using+Tcl%5FSize
>>>
>> | That page lists the functions, which use Tcl_Size either as return
>> | value or as parameter type.  It may help C/C++ extension developers to
>> | port their code to Tcl 9.
>>
>> How does the compiler 'know' whether Tcl_Size is a defined type?
>> It would be nice if the above page either contained directly or via link
>> the preferred way to use Tcl_Size in code which should compile on both
>> tcl 8.[67] and tcl 9.x.
>>
>> R'
>
> I currently use the following approach to make my extensions compile
> with 8.6, 8.7 and 9.0:
>
> Change all appropriate variables or return values from int to Tcl_Size
> and add the following typedef in an extension header file:
>
> #if TCL_MAJOR_VERSION < 9
>     typedef int Tcl_Size;
> #endif
>
> And as an optional short-cut for often used statements:
> #define TCL_NULL (Tcl_Size *)NULL
>
> Ex: Tcl_GetStringFromObj(obj, TCL_NULL) instead of
> Tcl_GetStringFromObj(obj, (Tcl_Size *)NULL);
>
> If anybody has a better solution, feel free to speak up.
>
> Paul

To my knowledge, it is planned that TCL 8.6 and 7 tcl.h header contain:
typedef int Tcl_Size;
so, one may always use TCL_SIZE as data type.

Nevertheless, the explanation by Paul is valuable.

TCL 8.7 will go one step further and also name the parameters TCL_SIZE
instead int:
See here:
https://core.tcl-lang.org/tcl/info/74d5501caf2f690a

Take care,
Harald

Am 23.08.2023 um 14:02 schrieb Harald Oehlmann:
> Am 23.08.2023 um 11:49 schrieb Paul Obermeier:
>> Am 23.08.2023 um 10:50 schrieb Ralf Fassel:
>>> * Paul Obermeier <obermeier@poSoft.de>
>>> | See https://wiki.tcl-lang.org/page/Tcl+9+functions+using+Tcl%5FSize
>>>>
>>> | That page lists the functions, which use Tcl_Size either as return
>>> | value or as parameter type.  It may help C/C++ extension developers to
>>> | port their code to Tcl 9.
>>>
>>> How does the compiler 'know' whether Tcl_Size is a defined type?
>>> It would be nice if the above page either contained directly or via link
>>> the preferred way to use Tcl_Size in code which should compile on both
>>> tcl 8.[67] and tcl 9.x.
>>>
>>> R'
>>
>> I currently use the following approach to make my extensions compile
>> with 8.6, 8.7 and 9.0:
>>
>> Change all appropriate variables or return values from int to Tcl_Size
>> and add the following typedef in an extension header file:
>>
>> #if TCL_MAJOR_VERSION < 9
>>      typedef int Tcl_Size;
>> #endif
>>
>> And as an optional short-cut for often used statements:
>> #define TCL_NULL (Tcl_Size *)NULL
>>
>> Ex: Tcl_GetStringFromObj(obj, TCL_NULL) instead of
>> Tcl_GetStringFromObj(obj, (Tcl_Size *)NULL);
>>
>> If anybody has a better solution, feel free to speak up.
>>
>> Paul
>
> To my knowledge, it is planned that TCL 8.6 and 7 tcl.h header contain:
>     typedef int Tcl_Size;
> so, one may always use TCL_SIZE as data type.
>
> Nevertheless, the explanation by Paul is valuable.
>
> TCL 8.7 will go one step further and also name the parameters TCL_SIZE
> instead int:
> See here:
> https://core.tcl-lang.org/tcl/info/74d5501caf2f690a
>
> Take care,
> Harald
>

See here for the future TCL.h content:

https://core.tcl-lang.org/tcl/file?name=generic/tcl.h&ci=tip&ln=418-426

* Harald Oehlmann <wortkarg3@yahoo.com>
| > Am 23.08.2023 um 10:50 schrieb Ralf Fassel:
| >> * Paul Obermeier <obermeier@poSoft.de>
| >> | See https://wiki.tcl-lang.org/page/Tcl+9+functions+using+Tcl%5FSize
| >>>
| >> | That page lists the functions, which use Tcl_Size either as return
| >> | value or as parameter type.  It may help C/C++ extension developers to
| >> | port their code to Tcl 9.
| >>
| >> How does the compiler 'know' whether Tcl_Size is a defined type?
| >> It would be nice if the above page either contained directly or via link
| >> the preferred way to use Tcl_Size in code which should compile on both
| >> tcl 8.[67] and tcl 9.x.
| >>
--<snip-snip>--
| To my knowledge, it is planned that TCL 8.6 and 7 tcl.h header contain:
| typedef int Tcl_Size;
| so, one may always use TCL_SIZE as data type.

That's good news. I'd rather have something in tcl.h than every
developer rolling their own logic.

R'

Am 23.08.2023 um 19:07 schrieb Ralf Fassel:
> * Harald Oehlmann <wortkarg3@yahoo.com>
> | > Am 23.08.2023 um 10:50 schrieb Ralf Fassel:
> | >> * Paul Obermeier <obermeier@poSoft.de>
> | >> | See https://wiki.tcl-lang.org/page/Tcl+9+functions+using+Tcl%5FSize
> | >>>
> | >> | That page lists the functions, which use Tcl_Size either as return
> | >> | value or as parameter type.  It may help C/C++ extension developers to
> | >> | port their code to Tcl 9.
> | >>
> | >> How does the compiler 'know' whether Tcl_Size is a defined type?
> | >> It would be nice if the above page either contained directly or via link
> | >> the preferred way to use Tcl_Size in code which should compile on both
> | >> tcl 8.[67] and tcl 9.x.
> | >>
> --<snip-snip>--
> | To my knowledge, it is planned that TCL 8.6 and 7 tcl.h header contain:
> | typedef int Tcl_Size;
> | so, one may always use TCL_SIZE as data type.
>
> That's good news. I'd rather have something in tcl.h than every
> developer rolling their own logic.
>
> R'

That's fine and easy, if you want to support 9.0, 8.7 and 8.6.14 only.

But what about supporting older 8.6.X or even 8.5.X versions?
Then you have to add a more complex macro statement to either define the missing typedef
and to avoid warnings regarding duplicate typedefs.

Something like this:

#if TCL_MAJOR_VERSION == 8
#if TCL_MINOR_VERSION < 6 || ( TCL_MINOR_VERSION == 6 && TCL_PATCH_VERSION < 14 )
typedef int Tcl_Size;
#endif
#endif

I do not know of a mechanism in C/C++ to detect already defined typedefs,
similar to #ifdef.

Paul

On 23/08/2023 20:18, Paul Obermeier wrote:
> I do not know of a mechanism in C/C++ to detect already defined typedefs,
> similar to #ifdef.

I observed that TCL_SIZE_MAX is introduced along with Tcl_Size, so for
my dbus extension is was thinking of doing:

#ifndef TCL_SIZE_MAX
typedef int Tcl_Size;
#endif

Schelte.

Paul Obermeier <obermeier@poSoft.de> writes:
> I currently use the following approach to make my extensions compile with 8.6, 8.7 and 9.0:
>
> [good advice]
>
> And as an optional short-cut for often used statements:
> #define TCL_NULL (Tcl_Size *)NULL
>
> Ex: Tcl_GetStringFromObj(obj, TCL_NULL) instead of Tcl_GetStringFromObj(obj, (Tcl_Size *)NULL);
>
> If anybody has a better solution, feel free to speak up.

For this one: remove the compatibility macros and this one is gone ...

rolf

Am 24.08.2023 um 00:05 schrieb Schelte:
> On 23/08/2023 20:18, Paul Obermeier wrote:
>> I do not know of a mechanism in C/C++ to detect already defined typedefs,
>> similar to #ifdef.
>
> I observed that TCL_SIZE_MAX is introduced along with Tcl_Size, so for my dbus extension is was thinking of doing:
>
> #ifndef TCL_SIZE_MAX
> typedef int Tcl_Size;
> #endif
>
>
> Schelte.
>

This approach seems better than looking at the Tcl version numbers.
What about introducing a separate macro in tcl.h?, ex.
#define HAVE_TCL_SIZE

Paul

Il giorno sabato 26 agosto 2023 alle 17:22:06 UTC+2 Paul Obermeier ha scritto:
> Am 24.08.2023 um 00:05 schrieb Schelte:
> > On 23/08/2023 20:18, Paul Obermeier wrote:
> >> I do not know of a mechanism in C/C++ to detect already defined typedefs,
> >> similar to #ifdef.
> >
> > I observed that TCL_SIZE_MAX is introduced along with Tcl_Size, so for my dbus extension is was thinking of doing:
> >
> > #ifndef TCL_SIZE_MAX
> > typedef int Tcl_Size;
> > #endif
> >
> >
> > Schelte.
> >
> This approach seems better than looking at the Tcl version numbers.
> What about introducing a separate macro in tcl.h?, ex.
> #define HAVE_TCL_SIZE
>
> Paul

Can you suggest me a link for downloading TCL9.0 binaries ? github ?
Thank you

Am 22.11.2023 um 12:55 schrieb Aldo Buratti:
> Il giorno sabato 26 agosto 2023 alle 17:22:06 UTC+2 Paul Obermeier ha scritto:
>> Am 24.08.2023 um 00:05 schrieb Schelte:
>>> On 23/08/2023 20:18, Paul Obermeier wrote:
>>>> I do not know of a mechanism in C/C++ to detect already defined typedefs,
>>>> similar to #ifdef.
>>>
>>> I observed that TCL_SIZE_MAX is introduced along with Tcl_Size, so for my dbus extension is was thinking of doing:
>>>
>>> #ifndef TCL_SIZE_MAX
>>> typedef int Tcl_Size;
>>> #endif
>>>
>>>
>>> Schelte.
>>>
>> This approach seems better than looking at the Tcl version numbers.
>> What about introducing a separate macro in tcl.h?, ex.
>> #define HAVE_TCL_SIZE
>>
>> Paul
>
> Can you suggest me a link for downloading TCL9.0 binaries ? github ?
> Thank you

Dear Aldo,
thanks, that you want to test TCL9, currently in Beta 1 rc0.

Currently, we are in build testing, so it is supposed, that you build on
your own from the source.

But the sourceforge project also gives you compiled binaries.

Look here and find a workflow, which succeeded and is for your platform.

https://github.com/tcltk/tcl/actions

- Choose the workflow
- Scroll down to show the Artefacts. Those are build versions.

Take care,
Harald

Am 22.11.23 um 17:19 schrieb Harald Oehlmann:
> Look here and find a workflow, which succeeded and is for your platform.
>
> https://github.com/tcltk/tcl/actions
>
> - Choose the workflow
> - Scroll down to show the Artefacts. Those are build versions.

Additionally, you must be logged in to github in order to access this
page. If you aren't logged in, you'll see nothing.

Christian

On 11/22/2023 2:34 PM, Christian Gollwitzer wrote:
> Am 22.11.23 um 17:19 schrieb Harald Oehlmann:
>> Look here and find a workflow, which succeeded and is for your platform.
>>
>> https://github.com/tcltk/tcl/actions
>>
>> - Choose the workflow
>> - Scroll down to show the Artefacts. Those are build versions.
>
> Additionally, you must be logged in to github in order to access this page. If you aren't logged in, you'll see nothing.
>
>        Christian
>
And, if I hadn't seen the above "scroll down" I wouldn't have found it either. In FF, with the mouse pointer in the blue area where it lists the 3 systems, the mousewheel won't scroll and so I never found the artifacts section until I stumbled onto that gotcha lol :)

Eventually, I downloaded a 9.0 windows wish, and it just crashed silently - a system monitor showed that a program werfault.exe was run as it's child process (description: windows problem reporting); however, an 8.7a6 would run.

A linux 9.0 wish did run, but I wanted to test some thread stuff and it doesn't have the thread package built in. I tried pointing auto_path to the directory where an installed 8.6.9 libthread2.8.4.so lives but it said it couldn't find the package, and when I tried to just load it, it said:

$ rlwrap ./wish9.0a4_snapshot
% load /home/et/test/libthread2.8.4.so
interpreter uses an incompatible stubs mechanism

So, while useful to try some new built in stuff, like lseq, it's not of much help to me.

Il giorno giovedì 23 novembre 2023 alle 00:46:14 UTC+1 et99 ha scritto:
> On 11/22/2023 2:34 PM, Christian Gollwitzer wrote:
> > Am 22.11.23 um 17:19 schrieb Harald Oehlmann:
> >> Look here and find a workflow, which succeeded and is for your platform.
> >>
> >> https://github.com/tcltk/tcl/actions
> >>
> >> - Choose the workflow
> >> - Scroll down to show the Artefacts. Those are build versions.
> >
> > Additionally, you must be logged in to github in order to access this page. If you aren't logged in, you'll see nothing.
> >
> > Christian
> >
> And, if I hadn't seen the above "scroll down" I wouldn't have found it either. In FF, with the mouse pointer in the blue area where it lists the 3 systems, the mousewheel won't scroll and so I never found the artifacts section until I stumbled onto that gotcha lol :)
>
> Eventually, I downloaded a 9.0 windows wish, and it just crashed silently - a system monitor showed that a program werfault.exe was run as it's child process (description: windows problem reporting); however, an 8.7a6 would run.
>
> A linux 9.0 wish did run, but I wanted to test some thread stuff and it doesn't have the thread package built in. I tried pointing auto_path to the directory where an installed 8.6.9 libthread2.8.4.so lives but it said it couldn't find the package, and when I tried to just load it, it said:
>
> $ rlwrap ./wish9.0a4_snapshot
> % load /home/et/test/libthread2.8.4.so
> interpreter uses an incompatible stubs mechanism
>
> So, while useful to try some new built in stuff, like lseq, it's not of much help to me.
Im' logged in GitHub.
I can see a lot of actions with 0 artifacts, and the this one
https://github.com/tcltk/tcl/actions/runs/6940949916
with 3 artifacts.
... downloaded the Linux artifact .. it just contains the "tcl_library" directory. Where are the binaries ?
I'm new with these actions/build on GitHub, but I cann find anything useful, or maybe I'm doing a wrong search ..
Can you give me a more precise link to these Linux builds ?

On 11/23/2023 5:21 AM, Aldo Buratti wrote:
> Can you give me a more precise link to these Linux builds ?

Can you try the ones at
https://sourceforge.net/projects/magicsplat/files/barebones-tcl/tcl9.0-dev/

I've verified windows and linux but do not have a mac to verify macos.

Not "official" beta rc's but very close.

These are single file executables, so no extensions etc.

Iirc the next RC should have the "bundled" extensions (thread, sqlite etc.)

/Ashok

Am 23.11.2023 um 06:00 schrieb Ashok:
> On 11/23/2023 5:21 AM, Aldo Buratti wrote:
>> Can you give me a more precise link to these Linux builds ?
>
> Can you try the ones at
> https://sourceforge.net/projects/magicsplat/files/barebones-tcl/tcl9.0-dev/
>
> I've verified windows and linux but do not have a mac to verify macos.
>
> Not "official" beta rc's but very close.
>
> These are single file executables, so no extensions etc.
>
> Iirc the next RC should have the "bundled" extensions (thread, sqlite etc.)
>
> /Ashok

Thank you, Ashok.

May I reference this page and your action on:

https://core.tcl-lang.org/tcl/wiki?name=Tcl_9.0_Release_Items

Take care,
Harald

Il giorno giovedì 23 novembre 2023 alle 08:45:11 UTC+1 Harald Oehlmann ha scritto:
> Am 23.11.2023 um 06:00 schrieb Ashok:
> > On 11/23/2023 5:21 AM, Aldo Buratti wrote:
> >> Can you give me a more precise link to these Linux builds ?
> >
> > Can you try the ones at
> > https://sourceforge.net/projects/magicsplat/files/barebones-tcl/tcl9.0-dev/
> >
> > I've verified windows and linux but do not have a mac to verify macos.
> >
> > Not "official" beta rc's but very close.
> >
> > These are single file executables, so no extensions etc.
> >
> > Iirc the next RC should have the "bundled" extensions (thread, sqlite etc.)
> >
> > /Ashok
> Thank you, Ashok.
>
> May I reference this page and your action on:
>
> https://core.tcl-lang.org/tcl/wiki?name=Tcl_9.0_Release_Items
>
> Take care,
> Harald
Thank you Ashok.
Just one question: is there a way to extract the stub-files "libtclstub.a" , "litbkstub.a" from these Linux single-executables ?
Alternatively, could you upload them on sourceforge ?

Am 23.11.2023 um 11:14 schrieb Aldo Buratti:
> Il giorno giovedì 23 novembre 2023 alle 08:45:11 UTC+1 Harald Oehlmann ha scritto:
>> Am 23.11.2023 um 06:00 schrieb Ashok:
>>> On 11/23/2023 5:21 AM, Aldo Buratti wrote:
>>>> Can you give me a more precise link to these Linux builds ?
>>>
>>> Can you try the ones at
>>> https://sourceforge.net/projects/magicsplat/files/barebones-tcl/tcl9.0-dev/
>>>
>>> I've verified windows and linux but do not have a mac to verify macos.
>>>
>>> Not "official" beta rc's but very close.
>>>
>>> These are single file executables, so no extensions etc.
>>>
>>> Iirc the next RC should have the "bundled" extensions (thread, sqlite etc.)
>>>
>>> /Ashok
>> Thank you, Ashok.
>>
>> May I reference this page and your action on:
>>
>> https://core.tcl-lang.org/tcl/wiki?name=Tcl_9.0_Release_Items
>>
>> Take care,
>> Harald
> Thank you Ashok.
> Just one question: is there a way to extract the stub-files "libtclstub.a" , "litbkstub.a" from these Linux single-executables ?
> Alternatively, could you upload them on sourceforge ?

The exe is a zip file. Rename it to ".zip" and use your favorite tool to
explore...

Take care,
Harald

On 11/23/2023 4:33 AM, Harald Oehlmann wrote:
> Am 23.11.2023 um 11:14 schrieb Aldo Buratti:
>> Il giorno giovedì 23 novembre 2023 alle 08:45:11 UTC+1 Harald Oehlmann ha scritto:
>>> Am 23.11.2023 um 06:00 schrieb Ashok:
>>>> On 11/23/2023 5:21 AM, Aldo Buratti wrote:
>>>>> Can you give me a more precise link to these Linux builds ?
>>>>
>>>> Can you try the ones at
>>>> https://sourceforge.net/projects/magicsplat/files/barebones-tcl/tcl9.0-dev/
>>>>
>>>> I've verified windows and linux but do not have a mac to verify macos.
>>>>
>>>> Not "official" beta rc's but very close.
>>>>
>>>> These are single file executables, so no extensions etc.
>>>>
>>>> Iirc the next RC should have the "bundled" extensions (thread, sqlite etc.)
>>>>
>>>> /Ashok
>>> Thank you, Ashok.
>>>
>>> May I reference this page and your action on:
>>>
>>> https://core.tcl-lang.org/tcl/wiki?name=Tcl_9.0_Release_Items
>>>
>>> Take care,
>>> Harald
>> Thank you Ashok.
>> Just one question: is there a way to extract the stub-files   "libtclstub.a" , "litbkstub.a"  from these Linux single-executables ?
>> Alternatively, could you upload them on sourceforge ?
>
> The exe is a zip file. Rename it to ".zip" and use your favorite tool to explore...
>
> Take care,
> Harald

Thanks so much Ashok, I got one of your wish90prebeta's for windows and it is working great for me on win10.

BTW, 7-zip.exe can directly read the .exe and found tcl_library and tk_library.

I was able to get BWidgets to load after fixing a few [Package require Tk 8.1.1] cases; changed it to 8.1.1- which allowed for the major version above 8.

However, I couldn't get BLT to load. It said it couldn't find Blt_Init, although I do see it in the BLT24.dll file. I'm guessing that 9 has changed something with C extensions.

I'm looking forward to a wonderful xmas present with the Thread extension in an upcoming release :)

Thanks again for the great work you do!

Am 24.11.2023 um 06:23 schrieb et99:
> On 11/23/2023 4:33 AM, Harald Oehlmann wrote:
>> Am 23.11.2023 um 11:14 schrieb Aldo Buratti:
>>> Il giorno giovedì 23 novembre 2023 alle 08:45:11 UTC+1 Harald
>>> Oehlmann ha scritto:
>>>> Am 23.11.2023 um 06:00 schrieb Ashok:
>>>>> On 11/23/2023 5:21 AM, Aldo Buratti wrote:
>>>>>> Can you give me a more precise link to these Linux builds ?
>>>>>
>>>>> Can you try the ones at
>>>>> https://sourceforge.net/projects/magicsplat/files/barebones-tcl/tcl9.0-dev/
>>>>>
>>>>> I've verified windows and linux but do not have a mac to verify macos.
>>>>>
>>>>> Not "official" beta rc's but very close.
>>>>>
>>>>> These are single file executables, so no extensions etc.
>>>>>
>>>>> Iirc the next RC should have the "bundled" extensions (thread,
>>>>> sqlite etc.)
>>>>>
>>>>> /Ashok
>>>> Thank you, Ashok.
>>>>
>>>> May I reference this page and your action on:
>>>>
>>>> https://core.tcl-lang.org/tcl/wiki?name=Tcl_9.0_Release_Items
>>>>
>>>> Take care,
>>>> Harald
>>> Thank you Ashok.
>>> Just one question: is there a way to extract the stub-files
>>> "libtclstub.a" , "litbkstub.a"  from these Linux single-executables ?
>>> Alternatively, could you upload them on sourceforge ?
>>
>> The exe is a zip file. Rename it to ".zip" and use your favorite tool
>> to explore...
>>
>> Take care,
>> Harald
>
>
> Thanks so much Ashok, I got one of your wish90prebeta's for windows and
> it is working great for me on win10.
>
> BTW, 7-zip.exe can directly read the .exe and found tcl_library and
> tk_library.
>
> I was able to get BWidgets to load after fixing a few [Package require
> Tk 8.1.1] cases; changed it to 8.1.1- which allowed for the major
> version above 8.
>
> However, I couldn't get BLT to load. It said it couldn't find Blt_Init,
> although I do see it in the BLT24.dll file. I'm guessing that 9 has
> changed something with C extensions.
>
> I'm looking forward to a wonderful xmas present with the Thread
> extension in an upcoming release :)
>
> Thanks again for the great work you do!
>

Hi ET!

I will fix BWidget soon, probably today with a new release.
You may get packages fixed for TCL 9 from Pauls work.
Klick on the package name in the table to download.

https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9

There is also a patched BWidget there I will just import, probobly..

Take care,
Harald

On 11/23/2023 3:44 PM, Aldo Buratti wrote:
> Just one question: is there a way to extract the stub-files "libtclstub.a" , "litbkstub.a" from these Linux single-executables ?
> Alternatively, could you upload them on sourceforge ?

Hmm, the SFE's do not seem to contain the stub libraries and the github
artifacts (where the Linux builds came from) don't either. So also the
include directories.

Seems like something that needs to be enhanced as other extension
writers may also want to develop against the SFE version of Tcl. I'll
log a RFE ticket for this.

/Ashok