Re: emacs-dynamic-module in Emacs Git?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 1 Dec 2014 14:59:00 +0100
> From: Aurélien Aptel <aurelien.aptel+emacs@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
> 
> On Sat, Nov 29, 2014 at 6:05 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > I have a few more, specific to the Windows build:
> >
> >   . As with other optional libraries, using libltdl should detect its
> >     availability at run time, and load it dynamically, instead of
> >     passing -ltdl switch to the linker when Emacs is built.  See
> >     examples of how to do that in image.c and gnutls.c.
> 
> What's the point of doing it this way? Honest question.

Honest answer: to allow users to download and install Emacs binaries
and run Emacs without also installing the optional libraries, which
are available as separate DLLs.  If we link Emacs against those DLLs,
it will refuse to start when those DLLs are not present on the
end-user's machine.

> >   . It seems to me that the modules call functions implemented by
> >     Emacs, like make_number and Fmember, on the assumption that
> >     calling any Emacs function will "just work".  This is false for
> 
> I had to add a linker flag to expose every symbol of Emacs. See the
> relevant commit:
> 
> http://git.savannah.gnu.org/cgit/emacs.git/commit/configure.ac?h=dynamic-modules&id=5c710fba15e0a3a2ae5d831e5cdb555332238752

I don't think this is correct: we don't really want to export all the
symbols.

> >     Windows (the link command that produces the shared object will
> >     fail), unless we mark such exportable functions and build an
> >     import library that will be passed to the linker when the module's
> >     shared object is built.  Likewise with global variables defined by
> >     Emacs.
> 
> I've never used Windows much for developement. Isn't there a similar
> flag we can use on mingw?

The same flag will also work with MinGW, but it is not the problem I
was talking about.  The problem is that on Windows, when you link the
modules themselves into shared libraries, the linker must be presented
with information about symbols exported by Emacs.  You could use the
Emacs binary, of course, but that's cumbersome.  The usual technique
is to generate a special import library as side effect of building
Emacs, and then submit that import library to the linker when you
create the module's shared library.

The import library is by convention called libFOO-NN.dll.a (where
"FOO" in this case will probably be "emacs", and NN will probably be
the Emacs version).  It is automatically created by the linker if you
pass the "-Wl,--out-implib=libFOO-NN.dll.a" switch to the compiler on
the link command line.

All this is pretty standard practice on Windows and works well, the
only issue for us is to decide which functions to export (unless we
really want to export all of them, in which case the --export-dynamic
linker switch is all that's needed).