Curious Windows GHCi linker behaviour .o vs. .dll
Herbert Valerio Riedel
hvriedel at gmail.com
Sun Oct 12 10:11:52 UTC 2014
On 2014-10-12 at 04:30:13 +0200, cg wrote:
> Are you using 64-bit ghc? If so, it looks the issue is 64-bit only.
Indeed, I have only set up 64bit CygWin & MSYS2 environments so far.
>>> Actually both _tzset and tzset exist in include/time.h, only tzset is old
>>> style name. They will be linked as the same function __imp__tzset.
>> What do you mean by "old style"? And more importantly, what
>> foreign-import line shall be used that works both on Windows and
>> non-Windows platforms, compiled as well as interpreted in GHCi?
> I meant OLDNAME in MS's jargon, because they deprecate tzset ,
> then call it 'old'. But it it still usable.
>  http://msdn.microsoft.com/en-us/library/ms235451.aspx
Ok, thanks for clairification, so I see there are actually two entangled
1) When coding directly against the MSVCRT, one is supposed to use the
underscore-prefixed POSIX symbols, like e.g `_tzset()`. However,
when targetting CygWin, using the proper `tzset()` POSIX name is the
recommended course of action.
To this end, I've submitted https://github.com/haskell/time/pull/4
(I hope that works for 32bit MSYS2 environments as well)
Personally, I think this was a very questionable decision on
Microsoft's part, as this way you effectively destroy any chance to
simply compile existing POSIX-compatible source code for no good
2) The other issue seems to be that while linking a package using
`tzset()` into a `.exe`, `tzset()` gets resolved just fine, however
as soon as GHCi's linker is used to resolve `tzset()` contained in
that package, it fails. At this point, I still consider this a bug.
It was suggested by Brandon, that GHCi's linker fails to resolve
More information about the ghc-devs