On 29 Aug 2000, Russ Allbery wrote:
> I'm not sure I'm completely following what you're arguing for here, but be
> careful not to go too far down the road of duplicating what the dynamic
> loader already knows how to do. There be dragons; that stuff is seriously
> baroque. You really don't want to reimplement it.
I'd very much like to not do it. It's bad enough to have to do that sort
of thing with perl code we completely control--having to do it portably
for what's essentially native code is more work than I'd really like to
do. Clever People have already provided the capabilities on individual
platforms and that's just fine by me.
> I'd love to see Perl aggressively take advantage of new capabilities in
> dynamic loaders, though. Among other things, I'll point out that symbol
> versioning is the way that things like libc manage to be backward
> compatible while still changing things, and we should probably seriously
> consider using symbol versioning in a shared libperl.so as a means to
> provide that much desired and extremely difficult to implement stable API
> for modules and the XS-equivalent.
This is where my lack of strange Unix knowledge comes to the fore. Is this
really a problem? It seems to me to be a standard sort of thing to be
dealing with. (OTOH, my platform of choice has 20-year-old executables as
part of its test suite and a strong engineering bent, so I may be coming
at things from a different direction than most folks)
I've been working on a spec for the API that'll hopefully isolate
extensions enough that we can yank the guts around at will without
affecting them. I'm really hoping that an extension built against perl
6.0.1 (presumably the first stable release... :) will work against perl
6.12.4. That's the plan, at least.
Dan
