On 19-Dec-06, at 9:10 PM, Peter Tanski wrote:
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.
Well, whenever there is "mingw32" in CLabel.hs or
PositionIndependentCode.hs, what is really meant is "windows". If
there is any HOST conditional there, then that's probably a bug.
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?
It will probably cause problems for foreign functions that are *not*
imported from a DLL. It should cause linker errors involving
undefined __imp__foo symbols (is that the kind of breakage that
occurs in the cygwin build?).
Windows tolerates false negatives for imported functions (and even
for imported data with recent GNU linker versions), and I think that
"d" flag in the ForeignLabel is never set correctly by other code, so
it is probably always False.
Cheers,
Wolfgang
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
