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.

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.

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.

-- 
Russ Allbery ([EMAIL PROTECTED])             <http://www.eyrie.org/~eagle/>

Reply via email to