Curious Windows GHCi linker behaviour .o vs. .dll
Herbert Valerio Riedel
hvriedel at gmail.com
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:
> 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