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.
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