Date: Wed, 03 Apr 2002 11:01:50 -0800 From: Darryl Okahata <darrylo@soco.agilent.com> To: Mark Murray <mark@grondar.za> Cc: Miguel Mendez <flynn@energyhq.homeip.net>, current@FreeBSD.ORG Subject: Re: rtld messing up? Message-ID: <200204031901.LAA12554@mina.soco.agilent.com> In-Reply-To: Your message of "Wed, 20 Mar 2002 18:14:55 GMT." <200203201814.g2KIEt4j070444@grimreaper.grondar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Last month, Mark Murray <mark@grondar.za> 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
darrylo@soco.agilent.com
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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204031901.LAA12554>