On Thu, Sep 13, 2001 at 08:25:46AM +0100, Simon Cozens wrote:
> On Thu, Sep 13, 2001 at 12:29:18AM -0700, Damien Neil wrote:
> > CVS changes over the past couple of days mean this patch will no
> > longer cleanly apply. I'd be happy to update it to patch cleanly
> > against the current CVS code, but I'd like to know first if the
> > approach it takes is on the right track.
>
> I like it, if only because reduction of common code is always good,
> and reduction of common code while everything's in a lot of flux
> is even better.
OK, I'll go through and update it again. This patch takes out the
parsing of interp_guts.h, which I think is good for a variety of
reasons. (Summary: it makes things simpler, and I don't think
parsing it will buy us anything at this point in time.) Is this
OK, or should I put it back in?
> Urgh, urgh, urgh. I don't *like* the idea of munging opcode function
> names, but I equally don't like coredumps. Isn't there a way of
> telling the linker to use our own symbols?
Actually, the problem is that the linker IS using our symbols. :>
There appears to be an "end" symbol somewhere in libc that is getting
munged by the Parrot symbol. I think. I didn't look deeply enough to
see exactly how things were going wrong, once I traced the core to a
symbol clash.
I *really* think we need to munge the names, though. "end" is just
far too common a symbol for us to be able to pollute it. Let's
learn the lesson from Perl 5: All symbols exported by the Parrot
code need a prefix.
- Damien
