From: John B. <joh...@ho...> - 2007-10-09 15:02:27
|
Earnie Boyd <earnie@...> writes: > > > Quoting John Brown <johnbrown105@...>: > <cut> > > Options: > 1) Port it to use already available mingw API Could be a lot of work. > 2) Add API to mingw I could probably do this, but this would probably involve peeking in the Platform SDK header files, which is Very Naughty. If the function in question is a C runtime function, I would have to write my own, by peeking at VC++ 2005 Express headers, which is also Very Naughty. Could be a lot of work. > 3) Use the free available but not free distributable SDK from Microsoft > and its headers. [1] > 4) Use the MSYS runtime to do the build > 5) Use the Cygwin runtime to do the build > > [1] If you do this, use a modified build environment so that uname -s > identifies the build system as *-*-windowssdk [2]. Of course you need > to setup a duplicate environment for bin/gcc, etc and putting the > headers and libraries in the appropriate places. > > [2] MSYSTEM=WINDOWSSDK start /msys > > Earnie > I don't really have any intention of doing any of 1 - 5 (as I said, it could be a lot of work), but: a) Are you saying that MinGW can, in fact, use Platform SDK headers and libraries, i.e., the headers don't contain any MS-specific syntax, and the linker understands the current MS .lib format? b) When you say "duplicate environment for bin/gcc", do I need a separate directory like C:/MinGWSDK, where the include/ and lib/ would contain SDK files instead of w32api? Wouldn't it be enough to set CFLAGS and friends when I configure? I always do this, because only MinGW headers and libs are in /mingw; I keep everything else in /usr/local. c) I ran the command in [2] and got: before: uname -s == MINGW32_NT-5.1 after: uname -s == WINDOWSSDK_NT-5.1 Is this what you expect? What effect does this have? |