Re: Dynamic loading progress

[Eli Zaretskii]

> From: Stephen Leake <address@hidden>
> Date: Sat, 14 Feb 2015 09:13:03 -0600
> 
> > So the question now becomes: what happens if you _remove_ the
> > "-I../../lib" option from the GCC command line?
> 
> gcc -std=gnu99 -ggdb3 -Wall -I../../src `pkg-config libcurl --cflags` -c 
> curl.c
> In file included from curl.c:8:0:
> ../../src/lisp.h:32:22: fatal error: intprops.h: No such file or directory
>  #include <intprops.h>
>                       ^
> compilation terminated.
> 
> 
> intprops.h is in lib; that explains why -I../../lib is needed.

No, it means including lisp.h without any changes will get you in
trouble.

> > If that doesn't work, then we really need an emacs.h file ASAP, and
> > the module should include only that file, without including <config.h>
> > inside that file.
> 
> Nor <lisp.h>. And probably not lots of other things.

None of the Emacs header files in src/ include config.h.  But they
might include other headers not appropriate for modules, like
intprops.h above.

This really is something that needs to be figured out and fixed before
the modules are announced operational, at least on MS-Windows.

> >> >    -Wl,--out-implib=libemacs.dll.a
> >> 
> >> And that goes in src/Makefile somewhere? Not on the "emacs$(EXEEXT)"
> >> line, since that doesn't run gcc. So it must go on the temacs$(EXEEXT)
> >> line (line 693)?
> >
> > Yes, it should be part of the temacs link command.
> >
> >> And until we write emacs.h, it also needs -Xlinker -E (or can that
> >> be -Wl,-E ?).
> >
> > I don't see what does a header file have to do with linking.  
> 
> -Wl,-E is short for -Wl,--export-all-symbols; that makes all symbols
> declared in Emacs visible to the module. (Similarly, --export-dynamic
> makes all symbols visible on Debian).
> 
> I'm assuming emacs.h will include some annotation to make the symbols
> declared in that file visible, so we won't need --export-all-symbols
> (but more below).

As soon as some symbols are declared for export, -Wl,--out-implib=
takes care to export only them, whereas -E will still export everything.

> > No, using --export-all-symbols is wrong.  See my other message in this
> > thread.  We don't want to export all the Emacs symbols to the outside
> > world.  Please use -Wl,--out-implib= instead.
> 
> How does that know which symbols to export? The help for Gnu ld
> --out-implib doesn't say.
> 
> Testing; apparently it exports all symbols - emacs.dll.a did not change
> size. So --export-all-symbols is redundant

Yes, that's why I said --export-all-symbols should not be used.  You
don't need it.

> but I don't see how we are going to restrict what symbols are
> available to the module.

The way to restrict the export is to declare the symbols you want to
export with __declspec(dllexport).  Then only those symbols will be
exported.

Note that, since emacs.h will be included by modules as well, we will
need something like

  #ifdef WINDOWS
  # ifdef emacs
  #  define EMACS_EXPORT  __declspec(dllexport)
  # else
  #  define EMACS_EXPORT  __declspec(dllimport)
  # endif
  # else
  #  define EMACS_EXPORT
  #endif

That's because they should be exported by Emacs, but imported by
modules.

> Is there an acceptable (ie portable and reliable) way to determine the
> OS in a Makefile? I'm not aware of one (short of Gnu config.guess).

Windows can be detected by looking at environment variables.  Since
Make converts them to Make variables, they are easily accessed.

Another possibility is to invoke "gcc -dumpmachine" via the $shell
function.  We could also invoke uname in a similar manner, but that
requires MSYS or Coreutils to be installed.  We could even invoke Make
itself with the --version option, and see what follows the "Built for"
header.

So ways to do that exist, we just need to decide whether we want to go
that way.