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