<div dir="ltr">Hi Carl,<div><br></div><div>Many thanks.</div><div><br></div><div>I think, actually, that I need to do a MinGW build. </div><div style><br></div><div style>As I found summed up in a Stack Overflow post:</div>
<div style><br></div><div>* Cygwin builds are for Cygwin.</div><div>* MinGW builds are for Windows.<br></div><div><br></div><div style>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 happens.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>Cheers,</div><div style>M</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 16, 2013 at 5:03 AM, Carl Ritson <span dir="ltr"><<a href="mailto:C.G.Ritson@kent.ac.uk" target="_blank">C.G.Ritson@kent.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Matt,<br>
<br>
> [...snip...]<br>
<div class="im">><br>
> I currently get through the compiler build, and all the way up to the TVM<br>
> build. I get part way through libtvm, and then hit the build of the POSIX<br>
> wrapper for Windows.<br>
><br>
> gcc -DHAVE_CONFIG_H -I. -I../../../../../../tvm/posix<br>
> -I/cygdrive/c/kroc/distribution/windows/build/kroc-tvm-posix/runtime/libtvm<br>
> -I/cygdrive/c/kroc/runtime/libtvm -g -O2 -Wall<br>
> -DTVM_FIRMWARE_PATH='"/cygdrive/c/kroc/distribution/windows/install/share/tvm/firmware/"'<br>
> -DTVM_LIBRARY_PATH='"/cygdrive/c/kroc/distribution/windows/install/lib/tvm/"'<br>
> -MT win32_io.o -MD -MP -MF .deps/win32_io.Tpo -c -o win32_io.o<br>
> ../../../../../../tvm/posix/win32_io.c<br>
><br>
> ../../../../../../tvm/posix/win32_io.c: In function<br>
> ‘char_available_console_win32’:<br>
><br>
> ../../../../../../tvm/posix/win32_io.c:34:2: error: ‘DWORD’ undeclared<br>
> (first use in this function)<br>
><br>
> ../../../../../../tvm/posix/win32_io.c:34:2: note: each undeclared<br>
> identifier is reported only once for each function it appears in<br>
><br>
> ../../../../../../tvm/posix/win32_io.c:34:8: error: expected ‘;’ before<br>
> ‘count’<br>
><br>
> The lack of a declaration of DWORD is because "windef.h" or (perhaps)<br>
> "windows.h" is missing. Including "windef.h" yields conflicts on the<br>
> definition of WORD, and "windows.h" conflicts with both "WORD" and "UWORD".<br>
<br>
</div>In tvm_posix.h there is a workaround using macros which avoids the<br>
conflict with Windows types. Do you have WIN32 defined in your<br>
config? As that would cause the workaround to be activated and<br>
windows.h to be included? The problem with cygwin might be that WIN32<br>
is not defined?<br>
<br>
Cheers,<br>
<br>
Carl<br>
</blockquote></div><br></div>