On Dec 19, 2006, at 6:46 PM, Wolfgang Thaller wrote:
On 19-Dec-06, at 9:10 PM, Peter Tanski wrote:
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.
Thanks! So it would probably be better to test for three alternative
defines: mingw32, cygwin and windows. (The new define for "Windows-
native" is i386_unknown_windows, target: windows_TARGET_OS; dynamic
cross-compilation of x86_64 code might be supported under an -mcpu or
-mtune flag, like gcc's -mcpu=x86_64.)
For CLabel.hs and PositionIndepentCode.hs all the mingw32 defines are
to TARGET_OS, so no bugs :) The problem is where mingw32 and cygwin
differ from Win32 or Win64--I don't know enough of their internals to
tell; so far I am sticking with the PE-COFF spec and haven't yet
learned about any differences in calling conventions between mingw,
cygwin and windows.
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?).
Ian posted problem with cygwin in a message, "Build failure on
Windows," at http://www.haskell.org/pipermail/cvs-all/2006-December/
052191.html . The failures are undefined references to functions in
libHSWin32.a, but I haven't looked at the real symbols to see if they
have the __imp__ prefix--from the linker response, i.e.,
"DeleteObject", they don't seem to.
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.
From my perspective that is good news: no differences, change is
easy :)
Cheers,
Pete
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
