From: Gerhard R. <ger...@go...> - 2011-08-24 20:59:19
|
> If your environment is correct, msys-gcc is responsible for it. I'm > putting my money on the probability that you do not have an MSYS > environment but a MINGW32 environment. Pass msys.bat an argument of > MSYS like so ``start /msys.bat MSYS''. The ``uname -s'' should tout > something like ``MSYS_NT-5.1''. No, I was using the MSYS environment. However, the Parrot codebase makes use of some headers (in particular tchar.h and direct.h), which aren't part of the msys-w32api package. I didn't want to make changes to the Parrot code yet, just trying to get it to build and thus added the MinGW include directory to the search path (after the MSYS directory, of course). This, however, messed up the startup code, probably by pulling in _mingw.h. I've made appropriate changes to the Parrot codebase and actually got it to compile. What still needs to be done is adding code for path translations to the Win32 platform files, but I don't expect any major problems - in fact, I'm mostly there already, just blocking on some spare time... Btw, MSYS makes use of the deprecated cygwin_conv_to_win32_path(), which doesn't know how to deal with unicode, instead of the more recent cygwin_conv_path(). Are there plans to update MSYS to a more recent version of Cygwin? As a workaround, I'm converting the paths to UTF-8 and just use the legacy function - don't know if it actually works yet, but I don't see a reason why it shouldn't... Gerhard R. |