Re: Dynamic loading progress

[Stephen Leake <stephen_leake@stephe-leake.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Date: Thu, 12 Feb 2015 14:09:53 -0600
>>
>> I had to add to options to the 'gcc' line in modules/curl/Makefile:
>>
>>     -std=c99 -I$(ROOT)/nt/inc
>
> Why do you need -std=c99?  What happens if you don't use it?

It complains about the "register" keyword in string.h stpcpy

>GCC
> defaults to -std=gnu99,

Apparently not in Mingw64

> I also don't like the -I$(ROOT)/nt/inc thing, it should only be needed
> for Emacs-specific system-level stuff.  Why was it needed here?

some file included ms-w32.h:

stephe@takver$ make
gcc -std=c99 -ggdb3 -Wall -I../../src -I../../lib `pkg-config libcurl --cflags` -fPIC -c curl.c
curl.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 #include <stdio.h>
 ^
In file included from ../../src/config.h:1866:0,
                 from curl.c:6:
../../src/conf_post.h:32:27: fatal error: ms-w32.h: No such file or directory

>> Normally those would be added by configure. Perhaps they could be set
>> via CFLAGS by the perl script when on mingw64?
>
> Sorry, I don't understand: the Emacs configure script already adds
> that directory to the include path.  So what's wrong?

I'm not running the top level Emacs makefile; I'm running
modules/curl/Makefile, in order to build the curl module.

>> But then I get link errors:
>>
>> <snip>
>
> GNU ld is a one-pass linker, so the libraries should be after the
> object files.

Ah, right; I forgot about link order. That fixes the libcurl problem.
But the original order worked on Debian.

>> The other symbols appear to be Emacs symbols? There was some discussion
>> about a special flag for exporting those on Windows; is that '-Xlinker
>> -E'? I guess that goes in src/Makefile somewhere?
>
> 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.

Right, but I was expecting this makefile to do that. Especially since it
"just works" on Debian.

> Otherwise all this stuff will not work on Windows, because
> the Windows port of the linker must see the import library at link
> time.

Apparently that is not true on Debian.

> The flag to produce the import library should be something like this:
>
>    -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)? And until we write emacs.h, it also needs -Xlinker -E
(or can that be -Wl,-E ?).

That should be added by configure when Windows and --with-ltdl are
specified. 

Hmm. We already have:

LIBLTDL = -lltdl -Wl,--export-dynamic

which is included in LIBES, and thus in the temacs.exe link. However,
that produces a warning:

C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/../../../../x86_64-w64-mingw32/bin/ld.exe:
warning: --export-dynamic is not supported for PE+ targets, did you mean
--export-all-symbols?

So apparently that should be changed to --export-all-symbols? Doing that
produces libemacs.dll.a

"--export-dynamic" is currently set in ./configure.ac line 3266; that
needs to be customized for the OS. Apparently the right way to do that
is with something like:

  if test "${opsys}" = "mingw64" || test "${opsys}" = "mingw32"; then
     #FIXME: should export only symbols defined in emacs.h (which doesn't exist yet)
     LIBLTDL="-lltdl -Wl,--export-all-symbols  -Wl,--out-implib=libemacs.dll.a"
  else
     LIBLTDL="-lltdl -Wl,--export-dynamic"
  fi


> Then you need to link the shared library against -lemacs.
>
> And the link command line should produce curl.dll, not curl.so.

Ok, that produced curl.dll. But doing:

src/emacs.exe -L modules/curl &
(require 'curl)

fails, with "eval: Cannot open load file: No such file or directory,
curl". That same test works on Debian.

Hmm. There is no curl/test.el, so this is _not_ designed to be part of
the test suite. Sigh. I'll work on the other module/* directories, which
do have test.el files.

So one question is how to make this Makefile do the right thing
for the current operating system. The intent is for this Makefile to be
part of the Emacs test suite, so it needs to not require user intervention.

One option is to rename modules/curl/Makefile to
modules/curl/Makefile.in and use configure in the modules directories.
Another is to set flags in modules/tests.py. I would prefer the former,
since that makes each Makefile self-documenting.

--
-- Stephe