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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
