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 https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
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 linker. PS: If I run ./validate on GHC HEAD, several of the GHCi testcases such as 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 tzset). Cheers, hvr