Dear Haskell maintainers,
I've progressed a little and found that the problem is down to
accessing global variables that are declared in dynamic libraries. In
a nutshell, this doesn't as the addresses of these global variables
are all wrong when ghci is executing the code. So, I think I
On 16/07/2010 12:36, Axel Simon wrote:
Dear Haskell maintainers,
I've progressed a little and found that the problem is down to
accessing global variables that are declared in dynamic libraries. In
a nutshell, this doesn't as the addresses of these global variables
are all wrong when ghci is
Hi Simon,
On 16.07.2010, at 14:29, Simon Marlow wrote:
On 16/07/2010 12:36, Axel Simon wrote:
Dear Haskell maintainers,
I've progressed a little and found that the problem is down to
accessing global variables that are declared in dynamic libraries. In
a nutshell, this doesn't as the
On 16/07/2010 14:04, Axel Simon wrote:
Hi Simon,
On 16.07.2010, at 14:29, Simon Marlow wrote:
On 16/07/2010 12:36, Axel Simon wrote:
Dear Haskell maintainers,
I've progressed a little and found that the problem is down to
accessing global variables that are declared in dynamic libraries. In
Hi all,
I'm trying to debug a segfault relating to the memory management in
Gtk2Hs. Rather than make you read the ticket http://hackage.haskell.org/trac/gtk2hs/ticket/1183
, I'll describe the problem:
- compiler 6.12.1 or 6.12.3
- darcs head of Gtk2Hs with #define DEBUG instead of #undef
Greetings fellow Haskellers and other readers,
During my ongoing research on doing whatever I feel like, I
discovered that using C++ libaries in GHCi (no problems with GHC)
wasn't as pleasant as I had hoped.
Apparently C++ sources requires to be linked with crtbegin.o and
crtend.o (and others
On Fri, 2005-02-25 at 19:05 +0100, Lemmih wrote:
Greetings fellow Haskellers and other readers,
During my ongoing research on doing whatever I feel like, I
discovered that using C++ libaries in GHCi (no problems with GHC)
wasn't as pleasant as I had hoped.
Apparently C++ sources requires
During my ongoing research on doing whatever I feel like, I
discovered that using C++ libaries in GHCi (no problems with GHC)
wasn't as pleasant as I had hoped.
Apparently C++ sources requires to be linked with crtbegin.o and
crtend.o (and others?) and I was wondering how to solve this nicely.
Any
On Fri, 25 Feb 2005 18:27:03 +, Duncan Coutts
[EMAIL PROTECTED] wrote:
On Fri, 2005-02-25 at 19:05 +0100, Lemmih wrote:
Greetings fellow Haskellers and other readers,
During my ongoing research on doing whatever I feel like, I
discovered that using C++ libaries in GHCi (no problems
On Fri, 25 Feb 2005 13:58:52 -0500, Wolfgang Thaller
[EMAIL PROTECTED] wrote:
During my ongoing research on doing whatever I feel like, I
discovered that using C++ libaries in GHCi (no problems with GHC)
wasn't as pleasant as I had hoped.
Apparently C++ sources requires to be linked
, that should hide all the C++ stuff
from GHCi.
Cheers,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Wolfgang Thaller wrote:
[...] *) static constructors/destructors
Sometimes there are pieces of code that expect to be called before
main() or at program termination. The GHCi Linker doesn't support this,
so some code may crash because things haven't been initialised properly.
This will
12 matches
Mail list logo
