Scott Snell wrote:
Is that simpler than fixing the MSVCRT headers?
It is not wine-MSVCRT headers fault, these are pure CRT declarations. It is gcc-c++ headers that are heavily dependent on gcc CRT very non-standard headers. So you better go with STLPort.
I have used STLport before so the idea sounds feasable to me. I imagine I have to change the gcc-linux.mak by:
replacing the call to gcc with winegcc, removing references to GLIBC,
Better go with gcc-mingw.mak, as threading and OS is more Windows than Linux. See if they have a -nocygwin variant.
adding a path pointing to /include/wine/MSVCRT.
Yes exactly. You'll see that you end up with a complete xxx-wine set of makefiles and headers.
Anything else?
There are some 1-2 defines in the major ARCH headers that go the windows way. I remember I had to define a __WINE_GCC__ in makefile and in a couple of places where they have this heavy #ifdef this #elseif that - I had to add #ifdef __WINE_GCC__ to point the compiler the windows way. But I guess the compiler will show you soon enough where he took the wrong turn.
I'll try to dig out that HD anyway Just so we can compare notes. But I'm sure you'll manage before I have time to do that.
regards,
Scott.
Free Life Boaz