Re: Problem building GNUstep on openSUSE 10.2

[Richard Stonehouse]

On Wed, Feb 14, 2007 at 12:19:44PM +0000, Richard Frith-Macdonald wrote:
> 
> On 14 Feb 2007, at 10:22, Fred Kiefer wrote:
> 
> >Richard Stonehouse schrieb:
> >>I'm trying to build GNUstep on openSUSE 10.2 and have hit a problem.
> >>I wonder if anyone can throw light on it - or, alternatively, whether
> >>anyone has successfully built GNUstep on openSUSE 10.2 and, if so,
> >>how?
> >>
> >>The problem is that the plmerge program fails with a buffer overflow
> >>and dumps out a Backtrace and Memory map - sample at:
> >><URL:http://www.rstonehouse.co.uk/testcase/plmerge-results.txt>
> >>
> >>The fault lies in plmerge, as built, and not with the data it is
> >>being given. It is reproducible with a trivial test case.
> >>
> >>In SuSE 9.3, plmerge - built from the same gnustep-base source -
> >>works OK. The main differences between 9.3 and 10.2, that seem to be
> >>potentially relevant, are:
> >>
> >>  - 10.2 has gcc version 4.1.2_20061115 (I think this is a
> >>    pre-release; Novell seem keen on living at the 'bleeding edge'),
> >>    whereas 9.3 used 3.3.5; and
> >>
> >>  - 10.2 has libffi (however the problem occurs irrespective of
> >>    whether I use libffi or ffcall).
> >>
> >>The problem is not the result of building under rpmbuild; it occurs
> >>even if I build by the orthodox configure/make process.
> >>
> >>Any help on this would be very welcome!
> >>
> >
> >I am using GNUstep on OpenSUSE 10.2 and it works fine for me. I know
> >this comment wont help you in any way :-(
> >Form the little information that is in your backtrace I would expect
> >that the problem you are seeing is related to the contents of your
> >GNUstep.conf file. This would mean that any other GNUstep tool or
> >application would fail as well. Could you please confirm this?
> >
> >Next step could be to start anew with a clean build of GNUstep,  
> >deleting
> >everything that was there before.
> 
> It would also be good to know which if you get the same behavior when  
> built with debug.
> Getting a stacktrace with full debug info would be nice ... looking  
> at the stacktrace and comparing with the sourcecode in svn it looks  
> like the problem might be with the parsing code, but it's hard to  
> tell exactly what.  A stacktrace with full debug (giving us the exact  
> line the problem occurred on)  might be the info needed for an  
> instant fix.

Problem solved for me, I think, with the help of Fred's suggestions.
If there is anything needing further investigation, let me know and
I'll be happy to do a debug of the failing build if desired. Thanks
for the suggestions, anyway.

-- 
    Richard Stonehouse