Re: Dynamic loading progress

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 2445 bytes --]

On 02/13/2015 08:10 AM, Eli Zaretskii wrote:
>> Date: Fri, 13 Feb 2015 07:58:12 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: eggert@cs.ucla.edu, emacs-devel@gnu.org
>>
>> 1) Shared libraries traditionally expose stable ABIs; when ABIs change
>> incompatibly, libraries change sonames. Shared libraries need stable
>> ABIs whether or not Emacs loads them: they're linked into other programs
>> and aren't necessarily rebuilt at the same time as their dependencies.
>> The Emacs core has never had a stable ABI, and creating one would
>> constrain our optimization opportunities.
>>
>> (That is, libpng.so's ABI ought to change a lot less often than
>> /usr/bin/emacs's: the former promises to provide a stable ABI and the
>> latter never has.)
> 
> Sorry, I don't share your optimism about the stability of their ABI.

My optimism is rooted in reality. Most shared library interfaces are
stable the vast majority of the time. If ABIs were generally unstable,
we'd have to rebuild programs constantly, yet I can run very old
binaries (especially on Windows) without trouble.

> In particular, image libraries are a bad example on which to build
> your point: look at the versonitis we need to employ in w32-win.el to
> support all their different ABIs.  Each new revision there breaks
> Emacs build with them.

w32-win.el isn't that bad, especially for a module that loads quite a
few different image libraries.

Besides: using modules tightly coupled to the Emacs core doesn't
actually help. Instead of elisp coupled to one module's stable ABI, you
have a piece of native code tightly coupled not only to that module's
stable ABI, but _also_ to the volatile Emacs internal ABI. As jwz would
say, now you have two problems.

Using a CFFI-like approach both reduces the volatility of the interface
(since now there's a strong boundary in only one direction) and makes it
easier to fix problems when they do come up.

> And we didn't yet start talking about problems with passing FILE
> pointers and malloc'ed buffers between Emacs and the modules.

You have that problem anyway: a tightly-bound Emacs module for bridging
the Emacs core and some third-party library would have to link against
_some_ libc, and unless both the Emacs core and the third-party library
used the same libc, you'd lose. A better idea is not to pass C runtime
objects between dynamically loaded components.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]