Curious Windows GHCi linker behaviour .o vs. .dll

[Herbert Valerio Riedel]

Hello!

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 [1],
> then call it 'old'. But it it still usable.
>
> [1] http://msdn.microsoft.com/en-us/library/ms235451.aspx

Ok, thanks for clairification, so I see there are actually two entangled
issues here:

 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
    reason...


 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
    weak symbols.