Win-GHC with GnuWin32 toolset--Mingw32 replacement
p.tanski at gmail.com
Mon Jan 8 11:16:41 EST 2007
On Jan 8, 2007, at 10:39 AM, Simon Marlow wrote:
> Peter Tanski wrote:
>> Part of the problem when attempting to use MS tools to build GHC
>> is the difference between Mingw32 library names (lib*.a, .so),
>> which CL, LIB, etc. do not recognise. The other part of the
>> problem is the Mingw toolset, notably AutoConf, AutoMake and
>> Make, which do not understand CL.
> 1. we don't use automake.
> 2. make is independent of the C compiler, except for its default
> suffix rules,
> which we don't use.
> 3. that leaves autoconf. Sure autoconf does a bunch of tests using
> gcc, but
> I guess most of these aren't problematic because we either
> ignore the
> results (using #ifdef mingw instead), or the results will be the
> for both mingw gcc and CL.
Thanks! That's good news!
> So I'm not sure we need a heavyweight solution here. I had
> imagined that we
> would continue to use MSYS or Cygwin as the build platform, but GHC
> itself would
> invoke CL instead of gcc.
We shouldn't. I have been following that strategy, especially since
the alternative seemed to be a hc-build which would require much more
configuration. There are a great many posix-library dependencies in
there I have to work through; profiling may not be available initially.
For the next step, the move to DLLs produced by NativeGen, GHC uses
what Windows calls the __cdecl calling convention (caller performs
stack cleanup, underscore '_' prepended to function name), while to
my knowledge DLLs require the __stdcall calling convention (callee
performs stack cleanup, same '_' prepended and commercial-at '@' and
number of bytes stack space appended).
> Certainly some build system changes are required - as you say, the
> conventions will be different (.o vs. .obj, .lib vs. .a, etc.).
> But if possible
> let's not require a whole new toolset to build GHC. If that
> happens, it's a
> problem because it adds another testing dimension.
I have little desire to write a whole new build toolset, though that
will have to be done eventually, I think. The only other tools
required would be a Windows-native version of Readline--not because
ghci can't be built using the Mingw version but because the GHC
producing the Windows version will be using lib.exe to link. Since
lib.exe can't handle Mingw static (.a) libraries I either need to
find or port those libraries.
More information about the Cvs-ghc