Problem with threads.
Neil Madden
bug. Just want to check whether this is valid before I raise it on sourceforge.
Built tclsh and wish from latest CVS with threads enabled - Win98SE, VC++ 6
Grabbed pre-compiled Thread 2.2 extension from sourceforge.
Tried the example on http://mini.net/tcl/1339.html , but it failed immediately
that I type in the thread::create line with an access violation error.
Is this a bug, or just something I'm doing wrong?
Neil.
--
package r Tkhtml;package r http;pack [scrollbar .v -o v -co {.h yv}] -s right\
-f y;pack [html .h -ys {.v set}] -f both -e 1;bind .h.x <1> {eval g [.h href %x\
%y]};proc g u {set t [http::geturl $u];.h cl;.h p [http::data $t];http::cleanup\
$t;.h co -base $u};g http://mini.net/tcl/976.html;proc bgerror args {};# NEM :-)
Jeffrey Hobbs
...
> Built tclsh and wish from latest CVS with threads enabled - Win98SE, VC++ 6
> Grabbed pre-compiled Thread 2.2 extension from sourceforge.
>
> Tried the example on http://mini.net/tcl/1339.html , but it failed immediately
> that I type in the thread::create line with an access violation error.
I don't think you should get an access violation, but the example on
that page doesn't seem right anyway (the runCommand proc is getting
thread::wait as an extra arg - error).
Perhaps the error in the command for thread::create has a bug?
In general, I've used threaded Tcl and Tk quite a bit on Win2K and
Linux without problems in recent releases.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Zoran Vasiljevic
> Grabbed pre-compiled Thread 2.2 extension from sourceforge.
If you would please checkout the 2.4 version from CVS on the
SourceForge, recompile and try again ?
Cheers,
Zoran
Neil Madden
>
> Neil Madden wrote:
> ...
> > Built tclsh and wish from latest CVS with threads enabled - Win98SE, VC++ 6
> > Grabbed pre-compiled Thread 2.2 extension from sourceforge.
> >
> > Tried the example on http://mini.net/tcl/1339.html , but it failed immediately
> > that I type in the thread::create line with an access violation error.
>
> I don't think you should get an access violation, but the example on
> that page doesn't seem right anyway (the runCommand proc is getting
> thread::wait as an extra arg - error).
>
> Perhaps the error in the command for thread::create has a bug?
The error is a Windows one - like a General Protection Fault, but it just says
"Access Violation".
I tried again, by moving the thread::wait to inside the proc definition. This
doesn't give a fault, but the thread ID returned is reported as invalid by the
thread::send command later on. The thread id is a negative number (like -593681)
- is this correct?
>
> In general, I've used threaded Tcl and Tk quite a bit on Win2K and
> Linux without problems in recent releases.
>
> --
> Jeff Hobbs The Tcl Guy
> Senior Developer http://www.ActiveState.com/
> Tcl Support and Productivity Solutions
Neil Madden
I'd love to, but it won't configure on my system. I changed the CONFIG script to
use --with-tcl=<path to tcl> rather than //z/tcl... and it now seems to pick up
the correct tclConfig.sh, but then it fails to detect mingw or cygwin, and picks
up the wrong header files and the wrong tclsh, and then gives a load of warnings
about invalid compiler flags and incompatible pointer types. Any ideas how to
get this running?
I have also tried using VC++, but I get a similar amount of errors from that
(casting Thead..* to int*, and various others).
>
> Cheers,
> Zoran
Marty Backe
Thread definition. Probably inserted when it was transferred to the Wiki.
At the end of the runCommand proc definition, the
thread::wait command should be on a line by itself. I have fixed the
Wiki page.
However, that being said, that error wouldn't have caused an access violation.
I have run the code verbatim from the Wiki page on my thread enabled
Tcl8.3.4 with Thread 2.1, on Solaris. It works fine. At work, code very
much like this, running on various versions of Solaris with Tcl 8.3.3, has
been in use extensively for 1+ years.
Generally, a flag is immediately raised when I see 'CVS' in the problem
statement. You are much more likely (not just in this case) to be
successful if you use released software instead of CVS snapshots.
In article <3CEC08B3...@cs.nott.ac.uk>, Neil Madden wrote:
> I have just tried my first foray into the world of threads, but I have hit a
> bug. Just want to check whether this is valid before I raise it on sourceforge.
>
> Built tclsh and wish from latest CVS with threads enabled - Win98SE, VC++ 6
> Grabbed pre-compiled Thread 2.2 extension from sourceforge.
>
> Tried the example on http://mini.net/tcl/1339.html , but it failed immediately
> that I type in the thread::create line with an access violation error.
>
> Is this a bug, or just something I'm doing wrong?
>
> Neil.
--
Marty Backe
-------------------------------
http://www.lucidway.org/tclwiki
Zoran Vasiljevic
> I'd love to, but it won't configure on my system. I changed the CONFIG script to
> use --with-tcl=<path to tcl> rather than //z/tcl... and it now seems to pick up
> the correct tclConfig.sh, but then it fails to detect mingw or cygwin, and picks
> up the wrong header files and the wrong tclsh, and then gives a load of warnings
> about invalid compiler flags and incompatible pointer types. Any ideas how to
> get this running?
>
I'm really sorry for that :(
Jeff may help us here, since the configuration stuff has changed
recently and I did not have a chance to test it again on Windows.
The unix build goes fine. AFAIK, it is based on the new TEA definition
with which I have no experience until today. It seems I'd have to
give this a serious try.
Also, David made some support files for VC++ which I also did not
test because I have no access to VC++. I'll try to organize something
here and have a look on that too.
Thanks for trying it out and reporting the problem. And sorry for
the (dissapointing configure) results. I will come back to you
in a day or two with a solution.
Sincerely
Zoran Vasiljevic
Neil Madden
>
> I'm really sorry for that :(
> Jeff may help us here, since the configuration stuff has changed
> recently and I did not have a chance to test it again on Windows.
> The unix build goes fine. AFAIK, it is based on the new TEA definition
> with which I have no experience until today. It seems I'd have to
> give this a serious try.
>
> Also, David made some support files for VC++ which I also did not
> test because I have no access to VC++. I'll try to organize something
> here and have a look on that too.
> Thanks for trying it out and reporting the problem. And sorry for
> the (dissapointing configure) results. I will come back to you
> in a day or two with a solution.
Thank you. I'm always willing to test new stuff. Should this be raised on
sourceforge bug tracker, or are you content as it is?
Zoran Vasiljevic
> I have also tried using VC++, but I get a similar amount of errors from that
> (casting Thead..* to int*, and various others).
This has been fixed now. There were just couple of typecasts missing,
but VC++ build went OK. Nothing really broken.
If you're following the README.txt file in win/vc directory, you should
now be able to build the 2.4 extension cleanly. Just update your local
copy from the SF (or checkout new) and recompile.
The mingw/cygwin builds are still on my TODO list.
Cheers,
Zoran
David Gravereaux
Zoran,
I think I need to have a look at makefile.vc . I've changed the one for
the core considerably since last november and should update that one too,
to follow the style of features, bug fixes, etc..
I'll try to get to that next weekend. There's a bug in tcl.h, at least I
call it a bug, where the typedef for ClientData is set to an int* rather
than a void*. Half the casting would be needed if it was a void* as this
is a feature of ANSI C to which VC++ complies.
--
David Gravereaux <davy...@pobox.com>
[species: human; planet: earth,milkyway,alpha sector]
Please be aware of the 7.5 year ping times when placing a call from alpha centari
Helmut Giese
>call it a bug, where the typedef for ClientData is set to an int* rather
>than a void*. Half the casting would be needed if it was a void* as this
>is a feature of ANSI C to which VC++ complies.
worse, I assume that is no longer necessary at all.
The (historical) problem:
Some pre-ANSI compilers didn't know the 'void' type. So in order to
accomodate those compilers, too, this switch was added.
Question: Is this still an issue today? Are there compilers, which
don't know the 'void' key word?
Solution 1: If no one knows a compiler that doesn't know 'void', then
let's just drop this switch altogether.
Solution 2: To be absolutely on the safe side, let's introduce a
#define for just this particular situation (the typedef for
ClientData)
#define KNOWS_VOID
which will be #defined by default (and probably forever), but can be
undefined if ever the necessity arises.
IMHO, this will make the handling of ClientData *a lot* easier: Not
relying on _STDC_ or some compiler specific #defines (which gives for
a lot of possible combinations), but having *one* switch for *just
this* issue.
Best regards
Helmut
Zoran Vasiljevic
> I'd love to, but it won't configure on my system. I changed the CONFIG script to
> use --with-tcl=<path to tcl> rather than //z/tcl... and it now seems to pick up
> the correct tclConfig.sh, but then it fails to detect mingw or cygwin, and picks
> up the wrong header files and the wrong tclsh, and then gives a load of warnings
> about invalid compiler flags and incompatible pointer types. Any ideas how to
> get this running?
Hi Neil !
This is what I have learned after couple of hours fiddling with
different setups while trying to compile the latest Thread
extension. Please note that the extension is updated lately to
use new "tclconfig" build. Obviously, there are still some
problems there, as you will see later on.
Compiling the extension with VC++ is pretty straigthforward now,
since I've fixed some missing typecasts. I would suggest you
to use VC++ if you have it. Otherwise, you might want to read my
experiences with using Cygwin/Mingw below. Compiling the extension
with those is much more complicated, as you will see shortly.
what did I learn ?
o. It is *not* simple to compile extension with Cygwin/MingW.
You need to have your Tcl core compiled with one or another.
o. Tcl 8.3.4 compiles with latest Cygwin flawlessly.
o. Tcl 8.3.4 *cannot* be compiled with MingW. At least,
I was not able to set it up. I had "make" producing
cores when trying to process the "tclWinConsole.c".
o. Thread extension cannot be compiled with Cygwin's "gcc"
and one has to use the MingW-supplied "gcc".
The configure script of new "tclconfig" is throwing
error, saying that the Cygwin version of "gcc" is not
supported. I have no idea why.
So what did I do then ? Here are the steps with some explanations
what I had to do, to get it working:
o. Downloaded Cygwin from:
http://www.cygwin.com
Installed and configured the Cygwing with supplied setup tool.
I choose the Internet install. It took some time to download
all packages but all went fine so after some time I could
launch the Cygwin shell and perform the installation.
o. Downloaded MingW from:
http://prdownloads.sourceforge.net/mingw/MinGW-1.1.tar.gz
I created a directory C:/mingw and unpacked the distribution
file in this directory.
o. Downloaded Windows source distribution of Tcl8.3.4
from SourceForge:
http://prdownloads.sourceforge.net/tcl/tcl834.zip
I've created a D:\tcl8.3.4 directory and unzipped the
distribution there. I changed to the D:\tcl8.3.4\win
directory and invoked "configure" from Cgywin shell:
$ ./configure --enable-symbols --enable-threads
The configure was satisfied and produced a Makefile so
I ran "make" from the Cygwin shell:
$ make
The "make" did not complain either and after couple of
seconds I had the (thread-enabled) tclsh running:
$ ./tclsh83sd.exe
% array get tcl_platform
osVersion 5.0 byteOrder littleEndian threaded 1 machine intel
platform windows os {Windows NT} user Administrator debug 1
% exit
$
This is nice. So I can use the tclsh shell on Windows.
o. Checked-out the latest thread extension sources from the
SourceForge site (press return when prompted for password):
$ cvs -d :pserver:anon...@cvs.tcl.sourceforge.net:/cvsroot/tcl login
$ cvs -z3 -d :pserver:anon...@cvs.tcl.sourceforge.net:/cvsroot/tcl co thread
o. I had to use the MingW-supplied gcc compiler since the configure
script of the Thread extension throws error if you're using the
Cygwin-supplied gcc. I have no idea why! I think some Tcl people
should take a look on that (Jeff, Mo, Andreas?).
So, what I did was simple:
$ export CC=C:/mingw/bin/gcc.exe
After this, I changed to "win" directory of the thread extension
and invoked configure:
$ ../configure --enable-symbols --enable-threads --with-tcl=D:/tcl8.3.4/win
Configure did not complain so I was able to run the make:
$ make
Make did complain while linking the library with:
Warning: .drectve `%.*s' unrecognized
Warning: .drectve `%.*s' unrecognized
but it produced the "thread24d.dll" library file.
This file I could "load" from the tcl shell:
$ cp thread24d.dll D:/tcl8.3.4/win/thread24d.dll
$ cd D:/tcl8.3.4/win
$ ./tclsh83d.exe
% load ./thread24d.dll
% set tid [thread::create]
% thread::send $tid "set the hallo"
hallo
% thread::release $tid
% exit
$
I will cc: this this experience to some Tcl maintainers
with the hope to get this straightened-out. I would
preffer to have one or the other build system but not both.
It is just too much complicated and error-prone this way.
Maybe somebody can take a look and get the tclconfig do
the right thing with either MingW (preferred) or the Cygwin.
If I'm not mistaken, the whole build process ought to be
just simple: configure/make/install. We're obviously far
from this goal at the moment.
Sincerely,
Zoran Vasiljevic
Neil Madden
>
> Neil Madden <nem...@cs.nott.ac.uk> wrote in message news:<3CECFCA3...@cs.nott.ac.uk>...
>
> > I'd love to, but it won't configure on my system. I changed the CONFIG script to
> > use --with-tcl=<path to tcl> rather than //z/tcl... and it now seems to pick up
> > the correct tclConfig.sh, but then it fails to detect mingw or cygwin, and picks
> > up the wrong header files and the wrong tclsh, and then gives a load of warnings
> > about invalid compiler flags and incompatible pointer types. Any ideas how to
> > get this running?
>
> Hi Neil !
>
> This is what I have learned after couple of hours fiddling with
> different setups while trying to compile the latest Thread
> extension. Please note that the extension is updated lately to
> use new "tclconfig" build. Obviously, there are still some
> problems there, as you will see later on.
>
> Compiling the extension with VC++ is pretty straigthforward now,
> since I've fixed some missing typecasts. I would suggest you
> to use VC++ if you have it. Otherwise, you might want to read my
> experiences with using Cygwin/Mingw below. Compiling the extension
> with those is much more complicated, as you will see shortly.
Different problem now. I managed to compile with VC++ (thank you), there were a
couple of warnings, but it all compiled ok. But now, I can't use thread::send,
it constantly complains about wrong number of args, even when I've made sure
that what I am passing in exactly matches what it asks for. I've tried async and
synchronous, with a variable and without, various qouting of my script with
list, etc, but nothing helps. I'll have a dive into the code and see if I can
fix this.
Neil.
Neil Madden
Got it fixed, the problem is on line 775 of threadCmd.c (ThreadSendObjCmd), it
needs to be changed from:
if (OPT_CMD(arg, "-async")) {
wait = 0;
} else {
...
to
if (OPT_CMD(arg, "-async")) {
wait = 0;
++ii;
break;
} else {
...
otherwise, after it has found the -async flag, it still tries to look for it,
and when it fails it reports a usage error. In fact, the logic is still wrong,
as if you don't input a -async flag at all, it still gets you. So maybe the
condition afterwards:
if (ii >= objc) {
goto usage;
}
should be changed to:
if (ii >= objc) {
// No -async
ii = 1;
}
? I can make this up into a patch, if you would like.
Jeffrey Hobbs
...
> extension. Please note that the extension is updated lately to
> use new "tclconfig" build. Obviously, there are still some
> problems there, as you will see later on.
I'll look into this more, but I have tested it on Windows and Linux
(although not in a few weeks).
> o. It is *not* simple to compile extension with Cygwin/MingW.
> You need to have your Tcl core compiled with one or another.
I believe that is only correct in the same sense that any fully
mingw compiled program requires like, because you are using
emulation libraries - not the full OS libraries of Windows. This
is only due to the use of mingw.
> o. Tcl 8.3.4 *cannot* be compiled with MingW. At least,
> I was not able to set it up. I had "make" producing
> cores when trying to process the "tclWinConsole.c".
I think that the effort has only been put into 8.4 for making things
mingw compatible. The tclconfig extension updates have that, but
as noted above, you can't mix mingw and VC++ compiles AFAIK.
> o. Thread extension cannot be compiled with Cygwin's "gcc"
> and one has to use the MingW-supplied "gcc".
> The configure script of new "tclconfig" is throwing
> error, saying that the Cygwin version of "gcc" is not
> supported. I have no idea why.
Because it is not supported. The reports from those more expert than
me (in the mingw/gcc on Windows crowd), mingw works and cygwin's gcc
is busted in several ways. The Tcl core throws the same objections.
When I hear otherwise, it will no longer throw the error.
So if cygwin gcc not working was your main contention, you now know
why. I always use CC=cl (VC++), and everything works happy (that
happens to be how ActiveTcl is built as well). Otherwise it looks
to me like things worked correctly. BTW, the fact that cygwin gcc
is busted in some way is noted on a regular basis on clt (usually
by Mo or Mumit Khan).
Zoran Vasiljevic
> Different problem now. I managed to compile with VC++ (thank you), there were a
> couple of warnings, but it all compiled ok. But now, I can't use thread::send,
> it constantly complains about wrong number of args, even when I've made sure
> that what I am passing in exactly matches what it asks for. I've tried async and
> synchronous, with a variable and without, various qouting of my script with
> list, etc, but nothing helps. I'll have a dive into the code and see if I can
> fix this.
>
The correct syntax (for until 2.4):
thread::send id ?-async? script
The 2.4 version added one optional argument:
thread::send id ?-async? script ?varname?
to be able to vwait on the "varname" and wait for result
from within the event loop.
The "script" must be one single argument. It is evaluated
in the target thread.
All is described in doc/thread.n.
Dont forget to create the thread properly.
For example:
% set tid [thread::create]
% thread::send $tid "set tcl_platform(threaded)"
1
% thread::send $tid "thread::exit"
Hope this helps.
Cheers
Zoran
Zoran Vasiljevic
> Different problem now. I managed to compile with VC++ (thank you), there were a
> couple of warnings, but it all compiled ok. But now, I can't use thread::send,
> it constantly complains about wrong number of args, even when I've made sure
> that what I am passing in exactly matches what it asks for. I've tried async and
> synchronous, with a variable and without, various qouting of my script with
> list, etc, but nothing helps. I'll have a dive into the code and see if I can
> fix this.
>
Hey, I just posted the answer but can't realy recall if it was ok.
So, let me do it again...
The syntax:
thread::send ?-async? id script ?varName?
And some examples:
% set tid [thread::create]
% thread::send $tid "set foo bar"
bar
% thread::send -async $tid "set foo rab"
% thread::send $tid "set foo"
rab
% thread::send -async $tid "set foo bar" waitOn
% vwait waitOn
% set waitOn
bar
All clear ?
Cheers
Zoran
Neil Madden
>
> Neil Madden <nem...@cs.nott.ac.uk> wrote in message news:<3CF0F132...@cs.nott.ac.uk>...
> > Different problem now. I managed to compile with VC++ (thank you), there were a
> > couple of warnings, but it all compiled ok. But now, I can't use thread::send,
> > it constantly complains about wrong number of args, even when I've made sure
> > that what I am passing in exactly matches what it asks for. I've tried async and
> > synchronous, with a variable and without, various qouting of my script with
> > list, etc, but nothing helps. I'll have a dive into the code and see if I can
> > fix this.
> >
>
> The correct syntax (for until 2.4):
> thread::send id ?-async? script
>
> The 2.4 version added one optional argument:
> thread::send id ?-async? script ?varname?
>
Yes, but for some weird reason, the code I have (checked out of CVS the other
day), doesn't seem to like this (it doesn't work with the examples given). In my
other post, I put a description of a patch which should fix this, but it doesn't
(well, it fixes it for -async, but not for without). I have actually managed to
get it working, by changing the argument checking code to look for -async only
as the first argument, which simplifies everything a bit. Have I got the right
code?
Neil.
PS - my code in ThreadSendObjCmd now looks like:
if (objc < 3 || objc > 5) {
goto usage;
}
arg = Tcl_GetStringFromObj(objv[1], NULL);
// Removed while loop looking for -async, so it can only be
// first argument now.
if ((*arg == '-') && OPT_CMP(arg, "-async")) {
wait = 0;
ii = 2;
} else {
ii = 1;
}
if (Tcl_GetLongFromObj(....
...
Zoran Vasiljevic
> > The correct syntax (for until 2.4):
> > thread::send id ?-async? script
> >
> > The 2.4 version added one optional argument:
> > thread::send id ?-async? script ?varname?
> >
>
> Yes, but for some weird reason, the code I have (checked out of CVS the other
> day), doesn't seem to like this (it doesn't work with the examples given).
You are correct. Sorry for my (misleading) info. I've already corrected
it in a post shortly after.
The correct syntax is:
thread::send ?-async? id script ?varname?
There are no needs of changing the code. Only the docs.
This is already taken care of. The doc/thread.n documents
the correct syntax now.
Cheers
Zoran
Zoran Vasiljevic
> Zoran Vasiljevic wrote:
> So if cygwin gcc not working was your main contention, you now know
> why.
Thanks for clarification, Jeff.
My primary interest is to have it simple. I'm not very good in Windows
so I need simple solutions. The Cygwin seems ok for me. The MingW
even more. Either of them alone, I can live with that. The only problem
I have was the mixture of both needed to compile the extension.
So are there any general guidelines?
Stick with 8.4 (= trash the 8.3 support) and use MingW?
If I take 8.4, can I compile it with MingW alone?
If yes, then we have to make sure TEA (tclconfig) extensions also can be
compiled with MingW (they don't at the moment).
The VC++ alone does seem as a viable solution, but not all people have it
(I do not, for example), so the Cygwin/MingW is very interesting.
What combinations of Tcl core / TEA extensions / Win Builds
are actually working?
I understand that this is not a simple question.
Cheers,
Zoran
Jeff Hobbs
...
> My primary interest is to have it simple. I'm not very good in Windows
> so I need simple solutions. The Cygwin seems ok for me. The MingW
> even more. Either of them alone, I can live with that. The only problem
> I have was the mixture of both needed to compile the extension.
>
> So are there any general guidelines?
>
> Stick with 8.4 (= trash the 8.3 support) and use MingW?
> If I take 8.4, can I compile it with MingW alone?
> If yes, then we have to make sure TEA (tclconfig) extensions also can be
> compiled with MingW (they don't at the moment).
> The VC++ alone does seem as a viable solution, but not all people have it
> (I do not, for example), so the Cygwin/MingW is very interesting.
>
> What combinations of Tcl core / TEA extensions / Win Builds are actually working?
I've changed the subject line to encourage the mingw fans to speak up
about this, because to be honest all my info is second-hand. I only
use VC++ to compile, basically because I have a license for it. If you
do have it, it is a much better compiler (generated code) than gcc or
mingw.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Join us in Sept. for Tcl'2002: http://www.tcl.tk/community/tcl2002/
Jussi Kuosa
was easy (a single package), it extracted fine, requires
only one addition to PATH and could be tested with gcc -v!
Hey, even I could manage that :-) I tried the few Win32
tutorials from the MinGW web page and even compiled some of
my own stuff without problems. If that (together with MSYS)
is all I need for a functional toolcahain under windows (I
don't have a VC++ licence at home) then I'm willing to learn
even autoconf and friends...
As said, for my humble leisure-hacking needs MinGW has been
a perfect fit. If I can also compile Tcl core and extensions
with it (haven't tried yet) on Windows platforms, I really
see no point in paying for a VC++ license (especially with
MSDN on the web for reference). So I vote for MinGW support
due to smaller download size and enough functionality -its a
good (cheap) way to start playing around with Tcl under
Windows.
My 0,02€,
Jussi Kuosa
Andres Garcia
...
> My primary interest is to have it simple. I'm not very good in Windows
> so I need simple solutions. The Cygwin seems ok for me. The MingW
> even more. Either of them alone, I can live with that. The only problem
> I have was the mixture of both needed to compile the extension.
>
> So are there any general guidelines?
>
> Stick with 8.4 (= trash the 8.3 support) and use MingW?
> If I take 8.4, can I compile it with MingW alone?
> If yes, then we have to make sure TEA (tclconfig) extensions also can be
> compiled with MingW (they don't at the moment).
> The VC++ alone does seem as a viable solution, but not all people have it
> (I do not, for example), so the Cygwin/MingW is very interesting.
>
> What combinations of Tcl core / TEA extensions / Win Builds are actually
> working?
You can compile TEA extensions using Mingw, the sample extension has been
recently updated to work with mingw and the configure tools from cygwin,
that's the way I compile TclCurl for Windows. So far though, I have only
managed it with the version you can find at:
ftp://ftp.nanotech.wisc.edu/pub/khan/gnu-win32/mingw32/snapshots/gcc-2.95.2-1/
I have also compiled Tcl 8.3.x using it, not Tk though.
Andres
David Gravereaux
>IMHO, this will make the handling of ClientData *a lot* easier: Not
>relying on _STDC_ or some compiler specific #defines (which gives for
>a lot of possible combinations), but having *one* switch for *just
>this* issue.
It seems MSC and Borland both do it wrong. __STDC__ is only defined for
"strict ansi" mode. gcc always has this on. I'm not sure what's the
right way to handle this.
Please place a comment, Jeff needs convincing that this is really a bug:
https://sourceforge.net/tracker/?func=detail&aid=509340&group_id=10894&atid=310894
S. C. M.
> Zoran Vasiljevic wrote:
> ...
> > My primary interest is to have it simple. I'm not very good in Windows
> > so I need simple solutions. The Cygwin seems ok for me. The MingW
> > even more. Either of them alone, I can live with that. The only problem
> > I have was the mixture of both needed to compile the extension.
> >
> > So are there any general guidelines?
> >
> > Stick with 8.4 (= trash the 8.3 support) and use MingW?
> > If I take 8.4, can I compile it with MingW alone?
> > If yes, then we have to make sure TEA (tclconfig) extensions also can be
> > compiled with MingW (they don't at the moment).
> > The VC++ alone does seem as a viable solution, but not all people have it
> > (I do not, for example), so the Cygwin/MingW is very interesting.
> >
> > What combinations of Tcl core / TEA extensions / Win Builds are actually working?
>
> I've changed the subject line to encourage the mingw fans to speak up
> about this, because to be honest all my info is second-hand. I only
> use VC++ to compile, basically because I have a license for it. If you
> do have it, it is a much better compiler (generated code) than gcc or
> mingw.
Probably VC is very good, but it is not free. The only thing about
TCL/TK that I don't like is that I have to use a proprietary compiler
to create extensions/compile. It does not make sense, at all. But if
to compile with VC is the only way I understand. It is preferable a
rock solid compiled code than any thing that doesn't work.
Best regards
Roger Oberholtzer
those pesky WIN32 binaries on Linux. (Testing still happens on a real
box.) Has anyone tried this? I have most of our own code (not all...)
working this way. My next step will be the Tcl/Tk/Tix/Blt that we use.
Just curious if anyone else is doing this.
David Gravereaux
>The only thing about
>TCL/TK that I don't like is that I have to use a proprietary compiler
>to create extensions/compile. It does not make sense, at all.
The Tcl core is written in Ansi C with a mixture of old K&R in there, too.
Many companies make compilers for this language. Looking just at windows,
and just the free ones, here's a list:
http://www.mingw.org
http://www.watcom.org
http://www.q-software-solutions.com/lccwin32/
http://www.borland.com/bcppbuilder/freecompiler/
Just because a makefile (or project file, whatever) doesn't exist for your
flavor of tool, doesn't mean Tcl is unfriendly to it. Please contribute.
David Gravereaux
>The only thing about
>TCL/TK that I don't like is that I have to use a proprietary compiler
>to create extensions/compile. It does not make sense, at all.
The Tcl core is written in Ansi C with a mixture of old K&R in there, too.
Helmut Giese
<davy...@pobox.com> wrote:
>hgi...@ratiosoft.com (Helmut Giese) wrote:
>
>>IMHO, this will make the handling of ClientData *a lot* easier: Not
>>relying on _STDC_ or some compiler specific #defines (which gives for
>>a lot of possible combinations), but having *one* switch for *just
>>this* issue.
>
>It seems MSC and Borland both do it wrong. __STDC__ is only defined for
>"strict ansi" mode. gcc always has this on. I'm not sure what's the
>right way to handle this.
>
>Please place a comment, Jeff needs convincing that this is really a bug:
>https://sourceforge.net/tracker/?func=detail&aid=509340&group_id=10894&atid=310894
Just did, but I got back some sort of error message. Therefore I add
it here, too. If it doesn't show up on Sourceforge, feel free to
re-enter it, mail it to Jeff, or whatever.
Best regards
Helmut
--------------
Currently ClientData is defined as follows (from tcl.h)
# if defined(__STDC__) || defined(__cplusplus)
typedef void *ClientData;
# else
typedef int *ClientData;
# endif /* __STDC__ */
With the Borland compiler (and apparently with VC++, too) this will
result in" typedef int *ClientData", leading to a lot of otherwise
unnecessary typecasts.
Explanation:
For the Borland compiler __STDC__ means *strict* compliance to ANSI C
(you can set this mode with the -A flag). With this flag turned on,
however, Tcl won't compile - some Windows header files containing C++
style (//) comments. I tend to think that this is a sensible thing to
do (you want ANSI C, you get - strict - ANSI C), but this is just
opinion - we got a problem to solve.
The criterion used above
# if defined(__STDC__) || defined(__cplusplus)
assumes this scenario:
- pre-ANSI C
- ANSI C or
- C++
However this does not describe the actual situation, where we have
sort of a post-ANSI period: C compilers adhering to the standard but
allowing extensions, too (like C++ comments). (And differing of course
in whether they #define __STDC__ for these extensions or not.).
I would therefore suggest that we change the criterion. After all, all
we want to know is whether the compiler knows the 'void' key word. We
don't really care (at this point) whether its internal logic defines
__STDC__. So my suggestion is to add a
#define KNOWS_VOID
and use this for the typedef of ClientData
# ifdef KNOWS_VOID
typedef void *ClientData;
# else
typedef int *ClientData;
# endif /* KNOWS_VOID */
I assume that all current compilers support 'void', so we probably
don't even need this check. If, however, it turns out that there is a
compiler which barks on 'void', we could add stuff to handle just this
compiler.
#define KNOWS_VOID
#if defined SomeWeirdCompiler
#undef KNOWS_VOID
#endif
In any case, we should change the criterion in some way, because it
doesn't handle the actual situation.
Just my 0.02
Helmut Giese
Mo
>
> I have been playing with the Linux MingW cross-compiler so I can compile
> those pesky WIN32 binaries on Linux. (Testing still happens on a real
> box.) Has anyone tried this? I have most of our own code (not all...)
> working this way. My next step will be the Tcl/Tk/Tix/Blt that we use.
> Just curious if anyone else is doing this.
Yes, you can compile Tcl/Tk with a Mingw cross compiler under Linux.
You will have to make a small modification before it will work.
This patch should do the trick for you.
cheers
Mo
Index: configure.in
===================================================================
RCS file: /cvsroot/tcl/tcl/win/configure.in,v
retrieving revision 1.45
diff -u -r1.45 configure.in
--- configure.in 2001/11/08 03:07:21 1.45
+++ configure.in 2001/11/25 02:58:11
@@ -54,32 +54,21 @@
# autoconf 2.50. You can also just set
# the CC, AR, RANLIB, and RC environment
# variables if you want to cross compile.
-dnl AC_CHECK_TOOL(AR, ar, :)
-dnl AC_CHECK_TOOL(RANLIB, ranlib, :)
-dnl AC_CHECK_TOOL(RC, windres, :)
+AC_CHECK_TOOL(AR, ar, :)
+AC_CHECK_TOOL(RANLIB, ranlib, :)
+AC_CHECK_TOOL(RC, windres, :)
+
+dnl if test "${GCC}" = "yes" ; then
+ dnl AC_CHECK_PROG(AR, ar, ar)
+ dnl AC_CHECK_PROG(RANLIB, ranlib, ranlib)
+ dnl AC_CHECK_PROG(RC, windres, windres)
+dnl fi
-if test "${GCC}" = "yes" ; then
- AC_CHECK_PROG(AR, ar, ar)
- AC_CHECK_PROG(RANLIB, ranlib, ranlib)
- AC_CHECK_PROG(RC, windres, windres)
-fi
-
#--------------------------------------------------------------------
# Checks to see if the make progeam sets the $MAKE variable.
#--------------------------------------------------------------------
AC_PROG_MAKE_SET
-
-#--------------------------------------------------------------------
-# Perform additinal compiler tests.
-#--------------------------------------------------------------------
-
-AC_CYGWIN
-
-if test "$ac_cv_cygwin" = "yes" ; then
- AC_MSG_ERROR([Compiling with the Cygwin version of gcc is not supported.
- Use the Mingw version of gcc from www.mingw.org instead.])
-fi
#--------------------------------------------------------------------
# Determines the correct binary file extension (.o, .obj, .exe etc.)
Phil Ehrens
only OS with a working thread implementation!
Steve Blinkhorn
: I've changed the subject line to encourage the mingw fans to speak up
: about this, because to be honest all my info is second-hand. I only
: use VC++ to compile, basically because I have a license for it. If you
: do have it, it is a much better compiler (generated code) than gcc or
: mingw.
The particular value of mingw is that (at least in my experience) the
same source code will compile across multiple platforms including
Win32 and myriad Unices. I too have a licence for VC++, but I really
don't use it because it means carrying in my head two or more different lists
of tweaks. That may be fine if computing is your principal focus,
but for me it's just an enabling technology, and just as Tcl/Tk is
great because it's cross-platform, mingw has a similar simplifying
potential. When I was running a major project on both SPARCs and
Win32, I junked Sun's compiler for the same reason. It's as if
(well, actually it's not `as if', it is the case I think) that vendors
of compilers and operating systems have an interest in locking you in
to their products by giving them features that conflict, so it's hard
to remember how to do things by other means.
I thought that one of the driving ideas behind POSIX was to hide OS
and hardware differences to make life easier. GNU's compiler may not
be perfect, but to avoid mental clutter it's a winner. And I can
cross-compile for practically any OS I'm likely to have to deal with
on my desktop workstation. Seems to me that what's sauce for
scripting languages ought to be sauce for compilers, i.e.
cross-platform.
Let me voice a prejudice here. The Tcl/Tk community bemoans the
apparently less than universal current takeup of Tcl/Tk, outside a
band of grey-haired enthusiasts (I am at least grey-haired). Could
this in part be because people who are interested in it as a platform
for providing products and services see it as too much of a hassle?
In its standard form, it has to be installed: customers don't like you
installing files (apparently) all over the place. Those of us who
come from a computing background don't, can't or won't see that this
is an obstacle to widespread adoption. It's irrational to care about
having to install a language to run an application. But it's an
obstacle to adoption because we can't force customers to be rational,
or to be as well-informed as we would like. They see a red mist,
they see security problems, they see a maintenance problem, so they
see Tcl/Tk as a PROBLEM (my news reader doesn't do boldface).
This is something I come across all the time with major corporate
clients and government departments. My way round it is to use the
tclkit + scripted document means of delivery, which involves at most
two files, typically around 1 megabyte in total. I can deliver on
Win32, several Unices and Linux, and now Mac OSx. But I'm denied
easy access to some C-coded extensions unless I spend the time
wrestling with the TEA and multiple compilers.
So, since we're an open source interest group, doesn't it make sense
to have gcc/mingw compatibility as a standard? There's no point
asking me to volunteer to do this: as I've said a hundred times on
clt, I'm one of those elusive mythical beasts, a computer literate
user who delivers working applications in my real field of expertise.
I come across customer resistance all the time: they don't think the
way you and I do, so we have to pander to their addle-headed
misconceptions.
--
Steve Blinkhorn <st...@prd.co.uk>
Mo
>
> Jeff Hobbs (Je...@ActiveState.com) wrote:
>
> : I've changed the subject line to encourage the mingw fans to speak up
...
> So, since we're an open source interest group, doesn't it make sense
> to have gcc/mingw compatibility as a standard?
As far as I know Tcl/Tk compiles with mingw just fine. We do
need to make it easier to build C extensions, but that is a
*really* hard problem (you can tell because it is not solved yet).
Mo
Phil Ehrens
than gcc does? Funny thing.
Steve Blinkhorn wrote:
> Jeff Hobbs (Je...@ActiveState.com) wrote:
>
>: I've changed the subject line to encourage the mingw fans to speak up
>: about this, because to be honest all my info is second-hand. I only
>: use VC++ to compile, basically because I have a license for it. If you
>: do have it, it is a much better compiler (generated code) than gcc or
>: mingw.
>
> ... since we're an open source interest group, doesn't it make sense
Andres Garcia
> Steve Blinkhorn wrote:
>>
>> Jeff Hobbs (Je...@ActiveState.com) wrote:
>>
>> : I've changed the subject line to encourage the mingw fans to speak up
>> : about this ...
>
> ...
>
>> So, since we're an open source interest group, doesn't it make sense
>> to have gcc/mingw compatibility as a standard?
>
> As far as I know Tcl/Tk compiles with mingw just fine.
Could you please tell me what version of mingw are you using?
> We do
> need to make it easier to build C extensions, but that is a
> *really* hard problem (you can tell because it is not solved yet).
What do you mean? The sample extension compiles just fine.
Andres
Mo
> > As far as I know Tcl/Tk compiles with mingw just fine.
>
> Could you please tell me what version of mingw are you using?
This is from the tcl/win/README file:
http://prdownloads.sourceforge.net/tcl/msys_mingw1.zip
It is based on Mingw 1.1.
Mo
Peter Dalgaard BSA
> As far as I know Tcl/Tk compiles with mingw just fine. We do
> need to make it easier to build C extensions, but that is a
> *really* hard problem (you can tell because it is not solved yet).
Actually, this got solved fairly well for the R project (wasn't by me
so I can say so...). You do need to install Perl and a rather
substantial bundle of ported unix tools, but with those in place,
things are as simple as
Rcmd SHLIB X.c
for building DLLs and
Rcmd build mypkg
if mypkg is a directory containing and R package (which needs to
follow some rather rigid structuring conventions, but those are common
to all platforms).
There are also cross-building tools in place.
Have a look if you care at
http://cran.r-project.org/doc/manuals/R-exts.pdf
--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dal...@biostat.ku.dk) FAX: (+45) 35327907
Andres Garcia
I am afraid it isn't that simple, I had tried it before to
compile version 8.3.4 and it doesn't because of '__try'.
Today I tried with the current cvs files and once I
saved the configure in Unix format it did compile even
though it there was something wrong in the test about whether
make sets the MAKE variable.
But when I tried to compile Tk, it hang in the command:
windres -o tk.res.o --include "./../generic" --include
"/home/Andres/tcl/generic" --include "./rc" "./rc/tk.c"
And unfortunately, while the sample extension compiles
with the mingw patched by Khan in a cygwin enviroment,
it failed to compile with msys_mingw, I don't know yet
why.
<rant>Some days I hate programming.</rant>
Andres
Roger Oberholtzer
various libs that need to be linked with when creating the libtcl.dll
are specified. I can sort this out, but I don't see it here.
I don't really care if it is done via config.
lvi...@yahoo.com
According to Phil Ehrens <-@->:
:You are being disingenuous. You KNOW that Solaris is the
:only OS with a working thread implementation!
:
:Marty Backe wrote:
Hmm - I know for certain that _I_ didn't know this ; I myself don't know
what Marty knows...
--
Support Internet Radio <URL: http://saveinternetradio.org/ >
Join Tcl'2002 in Vancouver http://www.tcl.tk/community/tcl2002/
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Mo
>
> Did I miss more here. For example, I see nothing in this where the
> various libs that need to be linked with when creating the libtcl.dll
> are specified. I can sort this out, but I don't see it here.
The point of the patch was to enable cross compile support so you
could create Windows binaries under Linux. The regular build system
already supports mingw in native mode, so it knows what libs to link with.
Mo