Building Tcl and Tk with Cygwin can be approached from various angles.
One way to build Tcl with Cygwin as host, build, and target, is to use PYK's tcl-8.6.4-1.cygport and associated patches. Once downloaded, build with a command something like this:
cygport tcl-8.6.4-1.cygport all
The cygport program can be installed via Cygwin's setup.exe.
The Tcl core build normally detects a Cygwin build and enables Windows-only features in the build. This cygport version of Tcl currently has most of that hybridization commented out. PYK has since warmed up to the idea of such hybridization, and will probably be making attempts to include more of it in the cygport build. Comments about the wisdom of such hybridization, particularly where it concerns potential pitfalls of dragging in differing libc libraries and mixing libraries created by differing C compilers, would be most welcome.
PYK's collection of cygport scripts , which represent a superset of the Tcl packages provided by ActiveTcl, provide a sort of batteries included Tcl distribution for Cygwin, except that for the time being, you have to compile everything yourself. It is designed to co-exist more or less peacefully with the Tcl provided via Cygwin's setup.exe, but it does overwrite /usr/bin/tclsh with a symlink to its own tclsh.
PYK 2015-11-21: This recipe uses a native Windowws Mingw-64 compiler, not the Mingw compiler available through the Cygwin setup.exe system. Perhaps it could be called partial cross-compilation. The advantage of this approach is that apart from the compiler, the build environment is a nice Unix-like environment that an autoconf-generated configure script and traditional Unix Make system can operate in to drive a native compiler.
In order for this to work, configure and Makefile scripts must take care to translate paths into the form expected by the native compiler. Thanks to the efforts of Jan Nijtmans and (ahem) PYK, the upcoming 8.6.5 release of Tcl includes the machinery to enable this approach, but the current release, Tcl-8.6.4, needs a little help to build under Windows. Here is the recipe:
George Peter Staplin 2004-09-02: The official Tcl 8.4.x has had the Cygwin build support removed, because it was in need of someone to maintain it, and no one came forward. Users looking for the most simple way to build Tcl/Tk under Windows should take a look at Building Tcl/Tk with Mingw. Building Tcl and Tk inside Cygwin is a little more complex, but it is also possible. The following instructions detail how to build Tcl and Tk in a Cygwin environment using the Mingw compiler support in Cygwin. To do so you will need to do:
export CC="gcc -mno-cygwin"; ./configure --prefix=/some/place/that/won't/conflict && make install
You will not be able to use the Cygwin XFree86 server for Tk, unless you patch Tk.
Pity.
TV: Maybe this page is informative though, it is possible, I made a windows build of a not so old tcl/tk which I use myself which has an X window interface on top of XP, using cygwin: Tcl/Tk on Xwindows emulation on XP using Cygwin. Assuming I can indeed get there maybe a good lecture/workshop subject for the next Fosdem 2004.
LES, who is totally ignorant of C, always wonders and finally picks up the courage to ask WHY in the world Tcl/Tk have to be made, distributed and compiled with Visual C, a proprietary environment, instead of GCC, MingW and/or other free environments.
RM Both tcl and tk 8.4.9 build just fine on cygwin 1.5.12 (hosted by Windows XP Home SP2) using gcc 3.3.3.
For tcl, generic/tclClock.c needed a small tweak to make it cope with cygwin's handling of timezone.
25 tests fail (most of them, unicode related) and io.test (io-53.4) hangs (or takes an awful lot of time - I got bored after 15 minutes).
Also, I noticed that "make install" tries to create man files with names like "pkg::create.n". Windows doesn't allow colons (and some other "special characters") in file names. I don't think cygwin can go around that.
Tk was built with Cygwin XFree86. generic/default.h had to be convinced to use unix/tkUnixDefault.h and not win/tkWinDefault.h
"wish" and "widget" run just fine.
Great job guys!
What was the tweak to tclClock.c so we can replicate it? What steps/commands to make with unix/tkUnixDefault.h and not win/tkWinDefault.h? Thanks in advance.
NJS Adding #define HAVE_TM_ZONE to the top of l/generic/TclClock.c allows compilation under Cygwin. The tcl tests show proper operation of TclClock.
To force building with the 'unix' directories, in files /tcl/configure.in, /tk/configure.in, /tix/configure.in, remove the text '*cygwin* | ', which forces CONFIGDIR = unix (instead of win).
EWW 2006-04-17 Make the following changes to unix/configure to allow shared libraries to be built for tcl.
around configure:2502 add
case $system in
CYGWIN*)
;;
*)
LIBS="-ldl $LIBS"
;;
esacafter
ac_save_LIBS="$LIBS"
around configure:3121 add
CYGWIN*)
SHLIB_CFLAGS=""
SHLIB_LD_LIBS='${LIBS}'
SHLIB_SUFFIX=".dll"
if test "$have_dl" = yes; then
SHLIB_LD="${CC} -shared"
DL_OBJS="tclLoadDl.o"
DL_LIBS=""
LDFLAGS="$LDFLAGS -Wl,--export-dynamic"
CC_SEARCH_FLAGS='-Wl,-rpath,${LIB_RUNTIME_DIR}'
LD_SEARCH_FLAGS=${CC_SEARCH_FLAGS}
fi
;;before
GNU*)
Do the same (different offsets) for tk.
JMN 2005-09-09:
Note that if the cygwin utility 'cygpath.exe' exists on your path at the time you run 'configure' in MSYS - then the generated Makefile will try to use cygpath. The makefile will then include the line:
CYGPATH = cygpath -w
This appears to be a 'bad thing' because in some cases you end up with trailing slashes stuffing up the gcc commandlines.
e.g gcc -c -O -Wall -Wconversion -I"./../generic" -I".\" etc
The trailing backslash above causes the '"' to be escaped and you end up with an error such as:
/bin/sh: -c: line 1: unexpected EOF while looking for matching `"' /bin/sh: -c: line 2: syntax error: unexpected end of file
To fix this, either change the line in the Makefile to read: CYGPATH = echo Or move your cygpath.exe aside during the whole build process.
From what I can determine from the MSYS readme - the cygpath utility shouldn't be required at all when building using MSYS/MinGW:
"Msys will convert POSIX paths that are used as arguments to Win32 paths.
This is done for any executable not in /bin and /usr/bin. If the executable is dependant on the msys-1.0.dll then it must be located in the /bin or /usr/bin directory. This means that you now have a POSIX environment that will automagically do the right thing w.r.t. changing the paths passed as arguments."
This issue appears to have been catching people out since at least Oct 2004 : http://groups.google.com.au/group/comp.lang.tcl/browse_frm/thread/7fc961790b53209e/adf411798d9f71c0?lnk=st&q=22cygpath+-w22+makefile&rnum=10&hl=en#adf411798d9f71c0