Re: behaviour of ghci on .c modules that are part of a library

2010-07-16 Thread Axel Simon
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

Re: [Gtk2hs-devel] behaviour of ghci on .c modules that are part of a library

2010-07-16 Thread Simon Marlow
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

Re: [Gtk2hs-devel] behaviour of ghci on .c modules that are part of a library

2010-07-16 Thread Axel Simon
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

Re: [Gtk2hs-devel] behaviour of ghci on .c modules that are part of a library

2010-07-16 Thread Simon Marlow
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

behaviour of ghci on .c modules that are part of a library

2010-07-14 Thread Axel Simon
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