Last month, Mark Murray <[EMAIL PROTECTED]> wrote:

> > > In ports/lang/gcl, a program is "undumped", and the resultant binary
> > > dumps core _very_ early in the startup. I can't get debugging info,
> > > because the undumping also seems to strip the program.
> > 
> > I've also have had that same problem when I tried to build the port,
> > but was never able to find the reason for the program to segfault, I
> > even opened a PR on that. The program seems to work on NetBSD btw.=20
> PR ports/34661 :-)

     Has anyone gotten any further on this?  I took a look at
ports/34661, but nothing new has been added to it.

     Using 4-STABLE (sorry, I'm not using -current), I took a quick stab
at the problem (having dealt with XEmacs undump issues in a past life),
but I haven't gotten anywhere, yet:

        XEmacs uses unexelf.c, whereas gcl uses unexec.c.  Changing gcl
        to use unexelf.c didn't change anything, but the next step is to
        compare the two unexelf.c's (they are different).  The core
        stack trace seems to imply that there's some constructor
        initialization issue that undump isn't handling properly.

        Darryl Okahata

DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to