Re: Problem with exception handling: WAS: no thread-safe +initialize in old gnustep runtime?

[Sebastian Reitenbach]

On Wednesday, June 15, 2011 08:59 CEST, Riccardo Mottola 
<riccardo.mottola@libero.it> wrote: 
 
> Hi,
> > Hi,
> >
> > On Tuesday, June 14, 2011 23:50 CEST, Riccardo 
> > Mottola<riccardo.mottola@libero.it>  wrote:
> >
> >> Hi
> >>> My feeling is that first priority ought to be to figure out why the 
> >>> signal handling code is not working ... I know it can't be 100% reliable 
> >>> (after all signal handling is not really thread safe), but it ought to be 
> >>> catching any problem in the stack trace normally, and recovering.  
> >>> Writing an alternative signal handling implementation using the latest 
> >>> BSD APIs rather than the original signal() system call, would seem to 
> >>> make sense here.
> >>>
> >> I wonder why it should not work. I can run Sudoku on OpenBSD using gcc
> >> and its runtime just fine.
> > on what platform is it working for you, I'm on i386, and IIRC also have 
> > seen it on sparc? Do you link against libffi or ffcall?
> I tested on OpenBSD (latest I think) on x86-32 with libffi. I had no 
> possibility yet to test on sparc. perhaps I was using ffcall there, 
> actually I think it is the last platform where I use it (well on windows 
> too, but there libffi should work fine too, I just do it because I'm lazy).
OK, I reinstalled gnustep-base, now linking against ffcall, but the problem 
persists. Afterwards I removed the patch to NSObject.m from the ports tree, and 
still, no change. I also tried with backend xlib, instead of cairo what I 
normally use. I did not expected a difference, and there also was no 
difference, but just wanted to make sure it work.

What configure parameter do you use to install make/base/gui/back?
I'll go reinstall my notebook, not taking the gnustep ports from the ports 
tree, but just install from source.

Sebastian

> 
> I shall test sudoku on windows.
> 
> Riccardo