Tcl - Upgrade from Tcl/Tk8.4 to 8.5a6

Author

Upgrade from Tcl/Tk8.4 to 8.5a6

Len Lawrence

2007-11-24, 7:14 pm

Mandriva in their wisdom have decided to move from version 8.4 to 8.5 in
their 2008 release. I have a dozen or so productivity programs used on a
daily basis. These all break down under the new regime. Tcl scripts per
se work fine but any C/C++ program invoking Tk_Main to run a Tcl script
through Tcl_AppInit aborts immediately (signal 6). This is a bit
alarming. Diagnostic print statements inside Tcl_AppInit are never
executed so there is nothing much to go on. According to information on
the web there are few changes in this area apart from initializing the Tcl
and Tk packages inside Tcl_AppInit. Are there in fact any changes in the
Tk to Tcl interface which could cause core dumps if the code ignores them?
Another worry is that the abort actually occurs well past the initial
printf statements. Please see the extract below...

int Tcl_AppInit ( Tcl_Interp * interp )
{
int i, n;

/* Initialise the interpreter for Tcl/Tk */

printf( "Tcl_AppInit: start : script = %s\n", paddbscript );
if ( Tcl_Init( interp ) == TCL_ERROR )
{
return TCL_ERROR;
}
printf( "Tcl_AppInit: Tcl initialized\n" );
if ( Tk_Init( interp ) == TCL_ERROR )
{
return TCL_ERROR;
}
printf( "Tcl_AppInit: Tk initialized\n\n" );

Tcl_StaticPackage( interp, "Tk", Tk_Init, Tk_SafeInit );
printf( "Tcl_AppInit: Tcl_StaticPackage\n" );

/* Map user functions to Tcl commands. */

n = sizeof(command) / sizeof(Command);
printf( "Tcl_AppInit: %d commands\n", n );
for ( i = 0; i < n; i++ )
{
Tcl_CreateObjCommand( interp, command[i].command, command[i].function,
(ClientData)NULL, (Tcl_CmdDeleteProc *)NULL );
}

/* Register the user interface */

Tcl_SetVar( interp, "tcl_rcFileName", paddbscript, TCL_GLOBAL_ONLY );
return TCL_OK;
}

Len

Donal K. Fellows

2007-11-25, 4:40 am

Len Lawrence wrote:
> Mandriva in their wisdom have decided to move from version 8.4 to 8.5 in
> their 2008 release.

As a side note, I hope that they'll use 8.5.0; that's scheduled to come
out *this* year.

> I have a dozen or so productivity programs used on a
> daily basis. These all break down under the new regime. Tcl scripts per
> se work fine but any C/C++ program invoking Tk_Main to run a Tcl script
> through Tcl_AppInit aborts immediately (signal 6). This is a bit
> alarming. Diagnostic print statements inside Tcl_AppInit are never
> executed so there is nothing much to go on. According to information on
> the web there are few changes in this area apart from initializing the Tcl
> and Tk packages inside Tcl_AppInit. Are there in fact any changes in the
> Tk to Tcl interface which could cause core dumps if the code ignores them?
> Another worry is that the abort actually occurs well past the initial
> printf statements. Please see the extract below...

I can't tell from your code snippet whether you are calling Tcl_Main. (I
suspect you are, but it'd still be good to know.) You'll also need to
report exactly how you are linking your code; there are a few ways of
doing it, some of which are precisely wrong for the "enhanced shell"
method of working which you are using.

An observation though: can your commands work as a dynamic library that
you load? If so, that's actually much easier to make work (and it gives
you access to some

packaging technology if you decide to produce
programs to run on computers other than your own...)

Donal.

Len Lawrence

2007-11-25, 7:18 pm

On Sun, 25 Nov 2007 10:24:21 +0000, Donal K. Fellows wrote:

> Len Lawrence wrote:
>
> As a side note, I hope that they'll use 8.5.0; that's scheduled to come
> out *this* year.
>
That's good. I will install it myself if Mandriva do not build it. I
like the fact that tkimg has been integrated into 8.5 so would prefer to
stick with it.
> I can't tell from your code snippet whether you are calling Tcl_Main. (I
> suspect you are, but it'd still be good to know.) You'll also need to
> report exactly how you are linking your code; there are a few ways of
> doing it, some of which are precisely wrong for the "enhanced shell"
> method of working which you are using.
>
> An observation though: can your commands work as a dynamic library that
> you load? If so, that's actually much easier to make work (and it gives
> you access to some

packaging technology if you decide to produce
> programs to run on computers other than your own...)
At present I include all the command functions in the main program. I
would like to release this particular program into the public domain but
it needs a lot of work before I could do that. It is an address label
database application, much simpler than glabels and lacking the vast
range of label formats which glabels supports but which nevertheless I
have found very useful over the past 23 years.

Thanks for your reply Donal,
and here is a skeleton of the program, similar to all those which I
have been running successfully since 1996. Over 2000 lines removed. This
has been in continuous use since my IBM PPC in 1984, starting life as a
DOS program compiled from Fortran and assembler. Converted to use Tcl/Tk
interface in my GNU/Linux year one. No problems ever until now.

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>
#include <memory.h>
#include <malloc.h>
#include <math.h>
#include <time.h>

#include <tcl.h>
#include <tk.h>

#include "paddb.h"

// Declare Tcl script command functions.

int addLog( );
int getFirstLine( );
int getLine( );
int getNextCategory( );
................
int thisType( );
int thisDate( );
int whichRecord( );

/* ----------------------------------------------------------------- */

char * path;
char paddb[65];
char paddbscript[65];

long maxref = 0;

int nofile;

// Set up Tcl command table.

static Command command[ ] =
{
{ "addLog", addLog },
{ "getCategories", getCategories },
{ "getFirstLine", getFirstLine },
{ "getLine", getLine },
...........................................
{ "thisType", thisType },
{ "thisDate", thisDate },
{ "whichRecord", whichRecord }
};
...................................................
int main ( int argc, char * argv[ ] )
{
int i, k;

char * p;

......................................

/* This supplies a name for the Tcl script which is launched
by Tk_Main. */

printf( "main: about to read data file\n" );
k = read_paddb( paddb, &refList );
printf( "main: read data status = %d\n", k );
if ( k > 0 )
{
/* This starts up the main event loop, which may be terminated
at the user interface, or by control-C.
*/
printf( "main: call Tk_Main\n\n" );
Tk_Main( argc, argv, Tcl_AppInit );
}
.............................................
return EXIT_SUCCESS;
}

And this is the makefile:

INC = -I/usr/include -I/usr/X11R6/include/X11
LIBS = -L/usr/lib64 -ldl -lieee -lm -ltcl8.5 -ltk8.5
DEBUG = -g
CFLAGS = $(DEBUG) $(INC)
CC = gcc

OBJS = paddb.o

paddb: $(OBJS)
$(CC) -o /home/lcl/bin/paddb $(OBJS) $(LIBS)
rm paddb.o

I added the -L/usr/lib64 while testing to make sure the 64bit
libraries would be linked just in case that was the source of the
problem.
Definitely not needed heretofor on 64bit systems.

Len

The printf statements output something right up to the call of
Tk_Main. None of the embedded printfs in Tcl_AppInit are executed, or
at least, their output is never seen. They could have been buffered
before the abort
..

Len Lawrence

2007-11-25, 7:18 pm

Earlier text deleted..... don't know how to mute.

Sorry Donal, I just noticed that you said Tcl_Main. So, I replaced
TK_Main by Tcl_Main and got a bit further. This time the init Tcl
routine failed returning the following message:

application-specific initialization failed: version conflict for
package "Tcl": have 8.5a6, need 8.5a5-8.5a6

Tcl_Init returns 0 rather than TCL_ERROR (1) but I guess that is kosher.

Thes are the RPMs from which Tcl/Tk was installed:

lib64tcl8.5-8.5a6-4mdv2008.0.x86_64.rpm
lib64tk8.5-8.5a6-8mdv2008.0.x86_64.rpm
tcl-8.5a6-4mdv2008.0.x86_64.rpm
tk-8.5a6-8mdv2008.0.x86_64.rpm

The installed libraries are libtcl8.5.so.0 and libtk8.5.so.0.

info patchlevel => 8.5a6

At this point I feel like giving up - unless there is a way to hack
around this it is time to get back to Mandriva with a bug report.

Len

Donal K. Fellows

2007-11-25, 7:18 pm

Len Lawrence wrote:
> The printf statements output something right up to the call of
> Tk_Main. None of the embedded printfs in Tcl_AppInit are executed, or
> at least, their output is never seen. They could have been buffered
> before the abort

That's always possible. When debugging it's better to use:
fprintf(stderr, ...);
as that's unbuffered... :-)

Donal.

Don Porter

2007-11-25, 7:18 pm

Len Lawrence wrote:

> application-specific initialization failed: version conflict for
> package "Tcl": have 8.5a6, need 8.5a5-8.5a6

Issues like this have been corrected. The current testing
releases are Tcl/Tk 8.5b3. Please use them and throw out
any earlier alpha/betas you may have lying around.

DGP

Len Lawrence

2007-11-25, 10:16 pm

On Sun, 25 Nov 2007 18:16:17 +0000, Don Porter wrote:

> Len Lawrence wrote:
>
>
> Issues like this have been corrected. The current testing
> releases are Tcl/Tk 8.5b3. Please use them and throw out
> any earlier alpha/betas you may have lying around.
>
> DGP

Done. No more problems. Thanks lads for your help.

Len

Larry W. Virden

2007-11-26, 8:15 am

On Nov 25, 10:36 am, "Len Lawrence" <l...@tarazed.demon.co.uk> wrote:
> I
> like the fact that tkimg has been integrated into 8.5 so would prefer to
> stick with it.

I'm a bit

/concerned about this comment. Perhaps the confusion
is what you mean by "tkimg".
If you are referring to the code from http://sf.net/projects/tkimg/ ,
I do not believe that tkimg has been integrated into 8.5 . The code
for Tile (found at http://tktable.sf.net/tile/) has been modified/
merged into Tk. But Tile is quite different than Img ...

Sponsored Links