Re: bignum branch

[Eli Zaretskii]

> From: Andy Moreton <address@hidden>
> Date: Fri, 10 Aug 2018 15:05:19 +0100
> 
> |   | __GMP_LIBGMP_DLL | libgmp.dll.a | dependencies  | data-tests |
> |---+------------------+--------------+---------------+------------|
> | 1 |                0 | libgmp.dll.a | libgmp-10.dll | crash      |
> |---+------------------+--------------+---------------+------------|
> | 2 |                0 | (removed)    | (none)        | pass       |
> |---+------------------+--------------+---------------+------------|
> | 3 |                1 | libgmp.dll.a | libgmp-10.dll | pass       |
> |---+------------------+--------------+---------------+------------|
> | 4 |                1 | (removed)    | (link fails)  | n/a        |
> |---+------------------+--------------+---------------+------------|
> 
> Row (1) is the original bignum build with the problem.

Can you show a C backtrace from the crash?

I'm asking because there's something weird about this crash.  What row
(1) does is use gmp.h where exported functions are not declared
__declspec(dllexport).  But that shouldn't prevent a valid dynamic
link against the DLL; in fact, you should see that most other DLLs we
use in Emacs don't have __declspec(dllexport) in their header files,
because that's the old MS convention that at least GNU tools tossed a
long time ago (although they still support it for backward
compatibility).

And since your problem AFAIU is with a single GMP function, I think
there's something special in that single function or maybe in the way
it is declared in gmp.h.  Or something similarly unique.

> Row (4) shows that asking for dllimport APIs without the import library
> fails to link:
> 
>   CCLD     temacs.exe
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>  frame.o: in function `XFLOATINT':
> C:/emacs/git/emacs/bignum/src/lisp.h:2923: undefined reference to
> `__imp___gmpz_get_d'
> [many similar lines omitted]

That's expected, if gmp.h uses __declspec(dllexport) for function
prototypes.

> I think this clearly shows that the problem is nmismatched calling
> convention and library usage.

See above: there's still some mystery here.