Re: bignum branch

[Andy Moreton]

On Fri 10 Aug 2018, Eli Zaretskii wrote:

>> From: Andy Moreton <address@hidden>
>> Date: Fri, 10 Aug 2018 08:43:38 +0100
>> 
>> Building the GMP library builds *different* gmp.h headers when building
>> for static library vs. a shared library.
>> 
>> The only difference in the headers preduced by the static libary and
>> shared libary builds is the hunk shown above. The shared library version
>> (the second hunk above) ensures that APIs get a __dllimport__
>> decoration for APIs on Windows, for linking to the shared library.
>> 
>> The MSYS2 GMP package includes a single gmp.h header for the static
>> library build, installed as "c:/msys64/mingw64/include/gmp.h".
>
> Yes, I know.  I would like to try to use the gmp.h header without
> changes, if possible, since that makes it easier for others to build
> Emacs.

Agreed - modifying the header is about problem diagnosis, not a long
term solution.

>> Emacs currently links against the shared library on MSYS2 64bit, and has
>> a dependency on "c:/msys64/mingw64/bin/libgmp-10.dll".
>
> You mean, on the bignum branch or on master/emacs-26?  If the latter,

This entire thread is about the bignum branch. GMP has never been linked
in on master. Why would you think otherwise ? Of course this is about
the bignum branch.

> is the dependency on libgmp recorded in the binary, or do you see it
> in a running session?  In either case, is the dependency direct in
> Emacs or indirect via some other library, and if so, which library
> causes the dependency?

I used the MSYS2 version of cygcheck to report the dependencies, and
also the Dependency Walker tool. Both show libgmp-10.dll as a direct
dependency of emacs.exe.

>> Using the gmp.h header without __dllimport__ API decorations probably
>> results in incorrect runtime linking to the DLL.
>
> That's what I don't understand, yet.

The only thing I changed was the dllimport decorations, and that changed
the behaviour from a crash to working properly. It is possible that some
other change in output after recompilation fixed the bad behaviour, but
improper runtime linking is a reasonable cause for this problem. Further
diagnosis from someone more expert than me is required to confirm if
that is the cause.

    AndyM