Re: Dynamic loading progress

[Eli Zaretskii]

> Date: Thu, 12 Feb 2015 22:51:22 +0100
> From: Aurélien Aptel <address@hidden>
> Cc: Stephen Leake <address@hidden>, 
>       Emacs development discussions <address@hidden>
> 
> On Thu, Feb 12, 2015 at 9:34 PM, Eli Zaretskii <address@hidden> wrote:
> > Sorry, I don't understand: the Emacs configure script already adds
> > that directory to the include path.  So what's wrong?
> 
> He's talking about the module Makefile, which is very basic and
> standalone (no includes or preprocessing).

I don't really understand what that means, but I hope you will be able
to help him.

> > The unresolved externals that are defined by Emacs are expected: you
> > need to link against an import library produced as part of building
> > emacs.exe.  Otherwise all this stuff will not work on Windows, because
> > the Windows port of the linker must see the import library at link
> > time.
> >
> > The flag to produce the import library should be something like this:
> >
> >    -Wl,--out-implib=libemacs.dll.a
> >
> > Then you need to link the shared library against -lemacs.
> 
> The configure script adds this to Emacs LD flags when modules are enabled:
> 
>     -lltdl -Wl,--export-dynamic
> 
> What does that do on Windows?

Nothing useful in this case, AFAIK.  Reverse dynamic linking doesn't
work on Windows.

On Windows, when you link a shared library, the linker must be
presented with either all the dependency object files, or with
their import libraries.  That's because the linker records inside the
shared library data about the dependent object files and their names.

In this case, we need to provide this information about Emacs, since
(AFAIU) the module has unresolved externals that need to be
dynamically linked to the corresponding Emacs symbols.  So we need
either to link the module against emacs.exe, or against an import
library generated when Emacs is built.  The latter is accomplished by
using the --out-implib= option to the linker.

Btw, when using the -Wl,--out-implib=libemacs.dll.a switch on the link
command line, we will be by default exporting _all_ the externally
visible symbols.  That doesn't sound right (think DSO), and is even a
source of possible problems, since Emacs on Windows redirects quite a
few C library functions to its own implementations, and also adds some
C library functions unavailable in the MS runtime.  Making them
visible to modules might mean trouble for those modules, if they rely
on the standard or different implementations of those functions.  So
we should really have the emacs.h header file with only the functions
and variables we want to export, and on Windows we should mark those
exported functions and variables with dllexport attribute, so that
only they are exported.  (It is possible that we should also use some
visibility attributes on ELF platforms, for similar reasons.)

One other potential issue is with passing file names to modules.
Emacs on Windows pretends that file-name-coding-system is UTF-8, so
using ENCODE_FILE will produce a UTF-8 encoded file name that Windows
runtime cannot grok.  Therefore, the glue code, either in Lisp or in
C, between Emacs and the module will have to convert the file name to
the current system codepage (because most libraries only support
that on Windows).

> Is there an up-to-date guide to setup a simple build environment
> (libs and all) for Emacs on Windows?

Yes, see nt/INSTALL.