Curious Windows GHCi linker behaviour .o vs. .dll

Herbert Valerio Riedel hvriedel at
Sat Oct 11 15:44:12 UTC 2014

On 2014-10-11 at 17:04:57 +0200, cg wrote:
> [...]
>>      ByteCodeLink: can't find label
>>      During interactive linking, GHCi couldn't find the following symbol:
>>        tzset
> Strange, I tried it under HaskellPlatform-2014.2, it works, I didn't
> see the
> failure. And I tried it in both Windows cmd and msys2 shell.

Well, I basically used a MSYS2 environment setup according to

>> However, when I prefix a `_` to the symbol-name in the FFI import, i.e.
>>      foreign import ccall unsafe "time.h tzset" c_tzset :: IO ()
> I guess it should read:
> foreign import ccall unsafe "time.h _tzset" c_tzset :: IO ()
> It works too.

Yes, sorry, I forgot to add that leading underscore :-/

> 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?

Note also that I reduced the original problem to a much smaller
repro-case here, the time-library actually has an additional
redirection: The `tzset()` call is made inside a C function in
`cbits/HsTime.c` which in turn is then foreign-imported. So in this
case, the GHCi linker fails to resolve the correctly referenced
`tzset()`. To me this sounds more and more like a serious bug in GHCi's

PS: If I run ./validate on GHC HEAD, several of the GHCi testcases such

   ghci/prog001              prog001 [bad stderr] (ghci)
   ghci/prog002              prog002 [bad stderr] (ghci)
   ghci/prog003              prog003 [bad stderr] (ghci)
   ghci/prog012              prog012 [bad stderr] (ghci)
   ghci/prog013              prog013 [bad stderr] (ghci)

fail for me due to not being able to load the `time` package (due to


More information about the ghc-devs mailing list