At 07:37 PM 8/29/00 -0700, Russ Allbery wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> > On 29 Aug 2000, Russ Allbery wrote:
>
> >> 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)
>
>Well, it depends on what your goals are, basically. For most shared
>libraries, people don't take the trouble.
That's OK--we will. :)
>Basically, no matter how well you design the API up front, if it's at all
>complex you'll discover that down the road you really want to *change*
>something, not just add something new (maybe just add a new parameter to a
>function). At that point, the standard Perl thing up until now to do is
>to just change it in a major release and require people to relink their
>modules against the newer version. And relink their applications that
>embed Perl.
It's just hit me why VMS' system service interface has managed to handle
this as well as it has over the years. Unfortunately one of the things that
helped it's longevity is rather inconvenient for the average C programmer.
I'll write up something more concrete once I've batted it around some in my
brain, and we can see if I'm off-base or, if not, whether it's worth it.
>Not a big deal, and that's certainly doable. But it's possible to do more
>than that if you really want to. The glibc folks have decided to comment
>to nearly full binary compatibility for essentially forever; the theory is
>that upgrading libc should never break a working application even if the
>ABI changes. I'm not familiar with the exact details of how symbol
>versioning works, but as I understand it, this is what it lets you do.
>Both the old and the new symbol are available, and newly built
>applications use the new one while older applications continue to use the
>previous symbol. That means that all your older binary modules keep
>working, and if your applications that embed Perl are linked dynamically,
>you can even upgrade Perl underneath them without having to rebuild them.
>
>I'm not sure it's worth the trouble, but it's something to consider.
I'm sure it is. I really, *really* want long-term binary compatibility.
Luckily for us, perl may end up with a reasonably small external API,
which'll make life easier.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
