Den 2008-08-29 13:27, skrev Duft Markus:
what if you do "./configure --host=i586-pc-winnt-msvc" and have a link
called i586-pc-winnt-msvc-cl to cl.exe? that would make configure select
that compiler automatically.
Nope, doesn't work (after adjusting to i686-pc-winnt, since config.sub
complains with i686-pc-winnt-msvc, you have to teach it that winnt-msvc*
is a "valid KERNEL-OS combination").
checking build system type... i686-pc-winnt
checking host system type... i686-pc-winnt
checking target system type... i686-pc-winnt
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for i686-pc-winnt-gcc... no
checking for gcc... gcc
You'd have to deliberately hide the MinGW compiler (or not install it).
Parity is my wrapper, and - thats one oft he cool points - it teaches
any binary it compiles to handle three different possible types of paths
correctly: native win32 (C:\...), interix through psxdll.dll
(/dev/fs/C/..., or /usr/local/...) and cygwin through cygwin1.dll
(/cygdrive/..., /usr/local/....). this happenes completely in the
background, no additional work to be done by the package. Of course I
know that this is not possible with plain cl.exe
So for what I do, I don't feel it's a cross compile, as you can see...
Interesting, but semi-alarming as well. That means that the binary
is not as "pure" as you have previously stated. It leaves room
for ambiguity (== security issues), as e.g. /etc/passwd is a valid
win32 path. How do you tell if I wanted C:\etc\passwd (with C: being
the current drive) or the /etc/passwd as seen by cygwin? Can this be
turned off? And especially cygwin1.dll has license implications that
should be considered...
Is the cygwin path translation enabled even if you build on Interix?
Just curious, where and how do you hook this functionality into
the binary and what happens when you are using a "parity dll"
with something not using parity? And the other way around?
And besides, it's fun fun fun to add windows*, win32*, winnt*,
winxp*, win* or whatever it ends up being called, to those
case $host_os statements. Pick your poison.
Hmm... why not look for mingw, and add winnt-msvc? It wasn't so much of
a pain for me...
I know it's not that painful, the question is how to /minimize/ the
pain.
Also, remember that MSVC with cccl have not used a different $host,
at least not to my knowledge? But how you are supposed to use cccl
with libtool is beyond me...
Cheers,
Peter
