Hello *,
I assume this is a well known issue to MSYS2/Windows developers, so I
hope somebody may be able to provide more insight for me to better
understand the underlying problem of
https://github.com/haskell/time/issues/2
So the prototype for tzset() is simply
void tzset(void);
and
On Sat, Oct 11, 2014 at 1:07 AM, Ben Gamari bgamari.f...@gmail.com wrote:
Thanks for your quick reply!
Andreas Voellmy andreas.voel...@gmail.com writes:
On Sat, Oct 11, 2014 at 12:17 AM, Ben Gamari bgamari.f...@gmail.com
wrote:
I'm a bit perplexed as to why the change was made in the
On Sat, Oct 11, 2014 at 9:24 AM, Herbert Valerio Riedel hvrie...@gmail.com
wrote:
Moreover, compiling and running the program still works, and the
additional underscore is visible in `nm` as well:
Sounds like ghci's linker doesn't resolve weak symbols?
--
brandon s allbery kf8nh
Another way to fix usb would be to re-register the callback after a
previously registered callback is fired. Of course it is cheaper not to
have to re-register, but re-registration in the latest IO manager should be
fairly cheap, so this may not be a performance problem for usb. Would this
work
On 10/11/2014 9:24 PM, Herbert Valerio Riedel wrote:
Consider the following trivial program:
module Main where
foreign import ccall unsafe time.h tzset c_tzset :: IO ()
main :: IO()
main = c_tzset
[...]
However, when loaded into GHCi, the RTS linker fails to find
Andreas Voellmy andreas.voel...@gmail.com writes:
Another way to fix usb would be to re-register the callback after a
previously registered callback is fired. Of course it is cheaper not to
have to re-register, but re-registration in the latest IO manager should be
fairly cheap, so this may
Andreas Voellmy andreas.voel...@gmail.com writes:
On Sat, Oct 11, 2014 at 1:07 AM, Ben Gamari bgamari.f...@gmail.com wrote:
Thanks for your quick reply!
What I'm wondering is what the extra complexity bought us. It seems like
the same thing could have been achieved with less breakage by
On Sat, Oct 11, 2014 at 12:17 PM, Ben Gamari bgamari.f...@gmail.com wrote:
Andreas Voellmy andreas.voel...@gmail.com writes:
On Sat, Oct 11, 2014 at 1:07 AM, Ben Gamari bgamari.f...@gmail.com
wrote:
Thanks for your quick reply!
What I'm wondering is what the extra complexity bought
Andreas Voellmy andreas.voel...@gmail.com writes:
On Sat, Oct 11, 2014 at 12:17 PM, Ben Gamari bgamari.f...@gmail.com wrote:
Yes, but it will be invoked by GHC.Thread and any other callers of it will
simply block indefinitely waiting for the thread that is running loop to
give it up - which
On 10/11/2014 11:44 PM, Herbert Valerio Riedel wrote:
Well, I basically used a MSYS2 environment setup according to
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
I reproduced the issue with ghc-7.8.3-x86_64.
Are you using 64-bit ghc? If so, it looks the issue is 64-bit
On 10/10/2014 9:40 PM, Páli Gábor János wrote:
2014-10-10 13:30 GMT+02:00 cg chengan...@gmail.com:
How can I configure to build x86_64?
When I build GHC (with msys2), it always builds i386 and I haven't spotted
the option in ./configure to choose a x86_64 release.
This is implicitly
11 matches
Mail list logo
