Re: GNUstep apps segfault on AMD64 (solved!)

[Tim Schmielau]

On 22 Jun 2008, at 20:03, Richard Frith-Macdonald wrote:
> On 20 Jun 2008, at 23:50, Gregory John Casamento wrote:
>
> > I used SuSE for a while and had a similar issue.  I thought that,  
> > by now, SuSE would have resolved it's 64 bit issues, but I see  
> > that's not the case.  *sighs*
> >
> > GNUstep works fine on Debian when compiled 64-bit, so this is  
> > definitely something that is distro-specific.   I'll see what I can  
> > do to test this and determine what can be done.
>
> On my Debian 64bit intel ffcall works fine but ffi does not.
> I'm not sure that libffi works correctly on 64bit intel for anyone.


Thanks a lot for today's svn commit 26723! It's log message got my  
attention, and indeed a 64 bit  installation from SVN using libffi  
solved my problem. Gorm as well as a program written by myself now run  
on both machines without problems.

On 26 Jun 2008, at 16:32, Manuel Guesdon wrote:
> On Thu, 19 Jun 2008 11:47:02 +0100 "Schmielau, Tim" <address@hidden 
> > wrote:
>
> > | I have two quad core 64 bit Xeon machines with SLES 10 sharing  
> > the same home directory where a fresh GNUstep installation (startup  
> > 0.20.0), gcc-4.2.4 and ffcall libraries reside. On one of the  
> > machines, GNUstep runs fine, on the other one every GNUstep  
> > application I've tried so far segfaults.
>
> I've got a problem with nx flagged Xeons.
> See http://article.gmane.org/gmane.comp.lib.gnustep.devel/6334
> Problem was occuring when configuring ffcal under a normal (not  
> root) user.

That sounds very similar to my problem. I had indeed seen your posting  
when searching the web for solutions, but not fully understood it. I  
have no root access on those machines, thus indeed had to configure  
ffcal as normal user. Still I got the same config.h settings as you  
described.

For comparison, I tried a home dir installation on one of the other  
machines that had always worked, using no root access at all (of  
course having removed the original /usr/GNUstep dir). This one also  
worked.

Anyways, as the problem is solved now, I'm not going to investigate  
further. Thanks to anybody who contributed, and especially to Richard  
Frith-Macdonald for the fix in svn!

Tim