bug#27516: 25.2.50; Building master branch on MSW fails because of gnutls and other reasons...

[Vincent Belaïche]

Sorry for the delay in replying, feedback below. I could not get a
running Emacs 26 with GNUTLS working also.

Le 30/06/2017 à 14:36, Eli Zaretskii a écrit :
>> From: vincent.belaiche@gmail.com (Vincent Belaïche)
>> Date: Fri, 30 Jun 2017 12:44:28 +0200
>> Cc: Vincent Belaïche <vincent.belaiche@gmail.com>
>>
>>> ./configure uses pkg-config to test for gnutls, so you need to have
>>> pkg-config as well as the gnutls.pc file in the pkg-config
>>> PKG_CONFIG_PATH. Try running
>>
>> OK, I could get some gnutls.pc file with the gnutls library and I edited
>> it for the content to match my installation, so now it is as follows:
>
> You shouldn't need to edit it, it should work as-is.

It would certainly work as is if the gnutls include files where placed
in guess-estimatable directories relative to pkg-config, but I placed
them in another directory in order not to mix up my mingw directory with
files from another source (namely gnutls.org), so I had to comment out
the prefix setting for the other settings to be taken as edited in
gnutls.pc and not replaced by guess-estimates, and I also edited the
other settings to point at the right place.

I had also to make another hack : when I took the gnutls windows port
from gnutls.org, the include files are in lib/includes, I had to move
this to includes/gnutls because the Emacs source makes some

 #include <gnutls/...>

directive with an explicit gnutls/... superdirectory.

So, OK, it's my fault, I should have taken the EZwinports and placed it
into my mingw.

>
>> --- a/src/w32heap.c
>> +++ b/src/w32heap.c
>> @@ -116,9 +116,9 @@ typedef NTSTATUS (NTAPI *PRTL_HEAP_COMMIT_ROUTINE) (
>>     to build only the first bootstrap-emacs.exe with the large size,
>>     and reset that to a lower value afterwards.  */
>>  #if defined _WIN64 || defined WIDE_EMACS_INT
>> -# define DUMPED_HEAP_SIZE (21*1024*1024)
>> +# define DUMPED_HEAP_SIZE (26*1024*1024)
>>  #else
>> -# define DUMPED_HEAP_SIZE (12*1024*1024)
>> +# define DUMPED_HEAP_SIZE (13*1024*1024)
>>  #endif
>
> It is very strange why you need this increment, while no one else
> does.
>

I can't tell why I need this. But if you explain me how to debug the
compile crash due to lack of memory, then we may know more about it.

Please note that I have been using a 32 bit compilation, while I am on a
64bit machine.

>> I note that that current sizes between narrow and wide are not
>> consistent, as 21 is not the double of 12.
>
> The size in the 64-bit build doesn't need to be a double of the size
> for the 32-bit build, since not every Lisp object is exactly twice
> large in the 64-bit build.  These numbers were found by
> trial-and-error.
>
>> Anyway, now I have a running Emacs 26, however it seems that it does not
>> have any gnutls in it, because when I try a message send, I get the
>> following error message:
>>
>> --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
>> Sending via mail...
>> smtpmail-send-it: Sending failed: Emacs does not support TLS
>> --8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----
>
> Like Noam said: make sure the DLL is where Emacs looks for it.

I could make it work. The issue was that only only you need the
directory (call it dir_1) where the DLL is in the PATH envvar, but also
you need that no other directory (call it dir_2) containing conflicting
DLL be in the PATH envar *before* dir_1.

I had a dir_2 containing other libgmp-10.dll and libp11-kit-0.dll and
that was sufficient to make it fail on execution. This was due to that I
had tried in the first place to use gnutls-cli.exe, so I had a
gnutls-cli.exe installed dir_2 which was using incompatible DLL compared
to that in dir_1.

Once again, OK it's my fault, I should have blindly followed the
instructions in

  (info "(emacs-gnutls) Help For Users")

and placed Eli's EZwinPorts into the same bin directory as emacs.exe,
but instead I took the latest from gnutls.org and placed it in another
directory. Sorry for I am desperately prone not to follow instructions
as-is.

  Vincent.

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus