The bug in Yasm r1712 was fixed this weekend (a side-effect problem
caused by using a macro as a function). Yasm r1713 tests perfectly.
I started modifying the build settings under configure.ac, etc. and
looking at the mingw32_blah_blah (mingw32_HOST_OS and
mingw32_TARGET_OS) defines in the rest of the system. As you would
expect, there are few areas where mingw32-conditional HOST settings
really overlap the TARGET settings, notably code in /compiler/cmm/
CLabel.hs and compiler/nativeGen/PositionIndependentCode.hs.
Ian: do you think some of the problems with the cygwin build might be
related to this line in compiler/cmm/CLabel.hs:584 (labelDynamic):
#if mingw32_TARGET_OS
ForeignLabel _ _ d -> d
#else
that is, labelDynamic might give false positives for dynamic code on
cygwin?
I honestly don't have enough experience with DLLs and windows-
libraries yet to start that porting task, but it seems like getting
GHC to build a windows-native version means working out the Windows-
compatibility problems at the same time or prior to the build system
settings. If you (or anyone else interested in a Windows-native
port) would have time to take a general look at potential Windows-
compatibility problems, I would be glad for the help.
As for basic modifications to the current build system, in addition
to tracking $TargetPlatform in build.mk, I corrected a few
assumptions (generally $host=$target) in configure.ac, so a user
could call:
./configure --target=i386-unknown-windows
and still get the proper result. I also had to conditionally change
the assumptions that $Target..._CPP = $Host..._CPP.
As a general procedure, I would personally rather solve all Windows-
compatibility problems first, then redo the build system to use SCons
or some other Windows-native system and go from there.
Cheers,
Pete
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
