[CCC DEV] Windows build progressing, question
matt at jadud.com
Tue Apr 16 22:48:52 BST 2013
I think, actually, that I need to do a MinGW build.
As I found summed up in a Stack Overflow post:
* Cygwin builds are for Cygwin.
* MinGW builds are for Windows.
The build we've been distributing is a MinGW build. Our Windows TVM wrapper
is written in a way, I think, that assumes it will be built against a
Windows environment/headers/etc. The Cygwin build does not do that---it is
a *NIX build that then requires support DLLs to function in a Windows
world. I suspect this collision/issue does not happen when a MinGW build
I'm going to try again; I may come back to Cygwin, but I think this is why
Christian went down the MinGW path when he did the Windows bundling. It is
certainly the case that I could do a Cygwin build, but I think I'd have to
rewrite the Windows wrapper.
On Tue, Apr 16, 2013 at 5:03 AM, Carl Ritson <C.G.Ritson at kent.ac.uk> wrote:
> Hi Matt,
> > [...snip...]
> > I currently get through the compiler build, and all the way up to the TVM
> > build. I get part way through libtvm, and then hit the build of the POSIX
> > wrapper for Windows.
> > gcc -DHAVE_CONFIG_H -I. -I../../../../../../tvm/posix
> > -I/cygdrive/c/kroc/runtime/libtvm -g -O2 -Wall
> > -MT win32_io.o -MD -MP -MF .deps/win32_io.Tpo -c -o win32_io.o
> > ../../../../../../tvm/posix/win32_io.c
> > ../../../../../../tvm/posix/win32_io.c: In function
> > ‘char_available_console_win32’:
> > ../../../../../../tvm/posix/win32_io.c:34:2: error: ‘DWORD’ undeclared
> > (first use in this function)
> > ../../../../../../tvm/posix/win32_io.c:34:2: note: each undeclared
> > identifier is reported only once for each function it appears in
> > ../../../../../../tvm/posix/win32_io.c:34:8: error: expected ‘;’ before
> > ‘count’
> > The lack of a declaration of DWORD is because "windef.h" or (perhaps)
> > "windows.h" is missing. Including "windef.h" yields conflicts on the
> > definition of WORD, and "windows.h" conflicts with both "WORD" and
> In tvm_posix.h there is a workaround using macros which avoids the
> conflict with Windows types. Do you have WIN32 defined in your
> config? As that would cause the workaround to be activated and
> windows.h to be included? The problem with cygwin might be that WIN32
> is not defined?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the developers