The process of compiling some code for a different architecture and/or operating system than the compiler is running on.

Example:

   * Run gcc on a Linux/Alpha host and let it generate code for a Windows/Intel machine.

---

(de). Following an advice by Peter Dalgaard at c.l.t I found it quite easy
and painless to cross-compile tcl8.4b1 and tk8.4b1 on linux for w32.

The needed steps are:

Install the mingw cross compiler on linux. I've used the binaries
from the http://www.stats.ox.ac.uk/pub/Rtools/mingw-cross.tar.bz2
and they worked for me. You need a linux with at least gnu libc 2.2
for the cross compiler suite.

Add the bin dir of the mingw cross compiler to your PATH. (You could
also use the mingw32/bin dir, with links with 'standard' names -
gcc, ar, ranlib etc. - to the real program's in bin, but be careful
to not fool yourself with different 'gcc's in your PATH.)

cd into the win dir of the tcl8.4b1 source distribution.

Create a config.site and put this into it:

  CC=mingw32-gcc
  AR=mingw32-ar
  RANLIB=mingw32-ranlib
  RC=mingw32-windres
  

Run 

  CONFIG_SITE=config.site ./configure

This runs without any problem for me.

Do 

  make

It's a real 'noisy' compile. The vast majority of the output are
repeated

  warning: passing arg 2 of `iswctype' with different width due to prototype

plus some warnings about redefinition of CHAR, SHORT and LONG and
warnings about "initializing from incompatible pointer type".

At least for me make completes without error and produces a
tclsh84.exe, some *.dlls and .a files.

Copy the .exe, *.dlls and *.a over to a MS box (I've used a w2k
box).

Don't forget to copy the 8.4b1 tcl and tk script libraries to an
appropriate place on your MS box.
Without them, you get a error message at tclsh and wish startup
about 

  "Can't find a usable init.tcl in the following directories ..."

This error msg is very helpful, because it lists the directories,
that are scanned for the library files. Choose one of them an put
the script library in it.

Ready. Both tclsh84 and wish84 are working (at least for me). I
'source'd tkcon into the wish84 and it work smooth, without any
problem.

Up to know, I haven't a clear result about [load]ing binary
extensions. I was able to load a VC++ 6.0 compiled tdom07.dll and the
extension worked. On the other side, [load]ing a tktable.dll (2.5)
crashed the wish84.exe immediately.

It seems, that the cross-compiled tclsh84.exe works fairly
reliable. At least, it runs the tcl bench suite without any problem:

   TCL_INTERP: 1:8.4b1 2:8.4b1
   STARTED 2002-07-20 23:42:00 (runbench.tcl v1.14)
   Benchmark 1:8.4b1 /local/devel/mwing-tcl/tclsh84.exe
   00:08:03 elapsed
   Benchmark 2:8.4b1 /Programme/Tcl/bin/tclsh84.exe
   00:07:15 elapsed

Both tclsh84.exe in this tclbench run are compiled using an identical
source tree (tcl8.4b1-src.tar.gz).

The first tclsh84 (1) was cross-compiled on a linux box, with mingw32
cross-compiler based on gcc-2.95.3 and version 1.3 of the
mingw-runtime and w32api, as described above and then
copied to the test box, which runs w2k.

The second tclsh84 (2) was compiled on the test box with a VC++ 6.0
Enterprise Edition (ie. optimization avaliable).

It's an almost undoubted fact (at least outside gcc zealot circles)
that VC++ generates more efficient executables than the gcc w32
versions. (Yes, gcc is optimized for portability, I know. Gcc is
really great in that, also undoubted.) Therefor I expected the VC
compiled tclsh to be faster.

I'm a bit pleasant surprised, that the VC compiled executable is
'only' around 10 percent faster over all, than the gcc cross-compiled
executable. Seems, a cross-compiled tclsh84.exe should be fast enough
for most applications.

''[MS] notes: I suppose you can speed up the cross-compiled tclsh about 7% by choosing the compilation flags "-O2 -fomit-frame-pointer" instead of "-O". This is a fearless extrapolation from the measurements in [Optimized compilation of tcl].''

''de: Yes, I could see a small speed up of the cross compiled tclsh, with the flags "-O2 -fomit-frame-pointer" but not 7 percent. It's around 3-4 percent. The tcl bench method of speed measurement (using  wall clock, not process time) clearly has some measure noise (running the tclbench suite several times with the same executables will give slightly different results). But after a few runs of the tclbench suite it seems to be a somewhat clear result, that the effect of the "-O2 -fomit-frame-pointer" doesn't makes that big of a difference for the cross-compiled tclsh, as you found it for the compilation on linux.''