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