caml on win64

[skaller <skaller@users.sourceforge.net>]

I'm having a problem using the Windows  native build of Ocaml
in a win64 environment. The error occurs running ocamlopt.opt,
attempting to link an executable: the diagnostic seems to be
from CL.exe (copied by hand looking at screen of windows box):

LIBCMT.lib(access.obj) : fatal error LNK1112: module machine
type 'x64' conflicts with target machine type 'x86'.

The problem seems to be ocaml is building 32 bit code using
the assembler, but it is invoking CL.exe to link, and the 
CL.EXE in the PATH is a 64 bit code generator/linker.

Unfortunately perhaps, Microsoft does not supply a compiler
with target switches. Instead they supply 4 distinct compilers
all named 'CL.EXE' but living in different places, to be used
building host->target with host,target in {x32,x64}.

In the particular script I'm using, we HAVE to have CL.EXE
generating 64 bit code for the C/C++ compilation steps.

However Ocaml is not actually using CL.EXE. It is simply cheating,
using CL.EXE to call LINK.EXE, which I believe does support target
switches. 

I'm not sure diddling the PATH before the link step will
be enough to fix this. Has anyone tried that?

Part of the problem is evident from the message: it's still
going to link the wrong C runtime, again because something
in the environment is telling the linker where to find the
runtime, and it is using the wrong one.

Although my build system has a theoretical workaround -- I could
build with --host=win32 --target=win64 that will fail for the same
reason: there's no way to switch the environment around between
the host and target steps (short of actually running the host
building phase in a win32 environment). The latter does work,
but it prevents full automation of the build process. The problem
is it is almost impossible to manually set up the required environment
to fool the MS toolchain.

It would be nice if there were some way to bind Ocaml to use the right
tools on installation.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net