[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem building GNUstep on openSUSE 10.2

From: Richard Frith-Macdonald
Subject: Re: Problem building GNUstep on openSUSE 10.2
Date: Wed, 14 Feb 2007 12:19:44 +0000

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,

The problem is that the plmerge program fails with a buffer overflow
and dumps out a Backtrace and Memory map - sample at:

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]