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

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

[Vincent Belaïche]

Please ignore the Emacs instance from which I am making this report, the
report concerns building a new instance.

When trying to build the latest on master branch, I get this error:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
configure: error: The following required libraries were not found:
     gnutls
Maybe some development libraries/packages are missing?
If you don't want to link with them give
     --with-gnutls=no
as options to configure
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

I am using configure with the following command line:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
  ./configure --prefix=c:/Nos_Programmes/GNU/Emacs \
			  --without-jpeg \
			  --without-tiff \
			  --without-gif \
			  --without-png \
			  --with-gnutls=no
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

So I am surprised. Also without `--with-gnutls=no' I get the same error
message, although I have put under my mingw directory the gnutls binary
from sourceforge EZWinPorts, but configure does not detect its presence.

Having or not --with-gnutls=no does not change the outcome as far as
error message is concerned. I am a bit confused because in the configure
--help, `--without-gnutls' is mentioned instead of `--with-gnutls=no'. I
tried `--without-gnutls' and the compilation went through. So this is an error in the message given by configure.


Well, when I am writing the the compilation went through, this is not up
to the end, because I got this later on:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
Loading c:/Programmes/installation/emacs-install/master/emacs/lisp/emacs-lisp/eldoc.el (source)...
dumped_data_commit: memory exhausted.
Enlarge dumped_data[]!
mv -f emacs.exe bootstrap-emacs.exe
mv: cannot stat `emacs.exe': No such file or directory
make[2]: *** [bootstrap-emacs.exe] Error 1
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

Anyway, I would be quite happy to understand how to have gnutls linked
to, so that Emacs could use the builtin rather than a gnutls client which, I could not manage to get it
detected. A similar question for other image connected libraries (jpeg,
tiff, gif, png, imagemagick...).

VBR,
	Vincent.


In GNU Emacs 25.2.50.1 (i686-pc-mingw32)
 of 2017-06-14 built on AIGLEROYAL
Repository revision: da62c1532e479bbac4ce242ee1d170df9c435591
Windowing system distributor 'Microsoft Corp.', version 10.0.14393
Configured using:
 'configure --prefix=c:/Nos_Programmes/GNU/Emacs --without-jpeg
 --without-tiff --without-gif --without-png 'CFLAGS= -Og -g3 -L
 C:/Programmes/installation/emacs-install/libXpm-3.5.8/src' 'CPPFLAGS=
 -DFOR_MSW=1 -I
 C:/Programmes/installation/emacs-install/libXpm-3.5.8/include -I
 C:/Programmes/installation/emacs-install/libXpm-3.5.8/src -L
 C:/Programmes/installation/emacs-install/libXpm-3.5.8/src''

Configured features:
XPM SOUND NOTIFY ACL TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: FRA
  locale-coding-system: cp1252

Major mode: Shell

Minor modes in effect:
  TeX-PDF-mode: t
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Mark set [2 times]
previous-line: Beginning of buffer [7 times]
scroll-down-command: Beginning of buffer
Mark set
(No changes need to be saved)
Mark set [2 times]
Formatting BBDB...done.
Mark set
C-x C-g is undefined
Formatting BBDB...done.

Load-path shadows:
c:/Programmes/installation/cedet-install/cedet-git/lisp/speedbar/loaddefs hides c:/Nos_Programmes/GNU/Emacs_build20170614/share/emacs/25.2.50/lisp/loaddefs
c:/Programmes/installation/cedet-install/cedet-git/lisp/speedbar/loaddefs hides c:/Programmes/installation/cedet-install/cedet-git/lisp/cedet/loaddefs

Features:
(shadow emacsbug texmathp bat-mode info preview prv-emacs reftex-dcr
reftex reftex-vars tex-bar tex-buf toolbar-x font-latex latex tex-style
tex advice tex-mode compile ffap url-parse url-vars calccomp calc-aent
calc-vec cursor-sensor ses unsafep hl-line org-element org-rmail org-mhe
org-irc org-info org-gnus org-docview doc-view subr-x jka-compr
image-mode org-bibtex bibtex org-bbdb org-w3m org org-macro org-footnote
org-pcomplete org-list org-faces org-entities noutline outline
org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-src ob-keys ob-comint ob-core ob-eval org-compat org-macs
org-loaddefs cal-menu calendar cal-loaddefs rect eieio-opt speedbar
sb-image ezimage dframe find-func thingatpt calc-math calc-alg
calc-forms calc-menu network-stream nsm starttls tls gnutls mailalias
smtpmail auth-source eieio eieio-core qp sort iso-transl perl-mode
dired-aux cus-start cus-load quail mail-extr bbdb-com crm bbdb-message
sendmail message dired-x dired format-spec rfc822 mml mml-sec
password-cache epg gnus-util mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr
mailabbrev mail-utils gmm-utils mailheader vc-git diff-mode easy-mmode
misearch multi-isearch sh-script smie executable pcmpl-unix shell
pcomplete comint ansi-color ring edmacro kmacro skeleton calc-misc
calc-arith calc-ext calc calc-loaddefs calc-macs tex-mik preview-latex
tex-site auto-loads bbdb bbdb-site timezone bbdb-loaddefs template
w32utils cl-seq cl-macs cl recentf tree-widget wid-edit
load-path-to-cedet-svn finder-inf package epg-config seq byte-opt gv
bytecomp byte-compile cl-extra help-mode easymenu cconv cl-loaddefs
pcase cl-lib time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table
w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)

Memory information:
((conses 8 727288 171841)
 (symbols 32 45125 0)
 (miscs 32 872 2614)
 (strings 16 105093 14985)
 (string-bytes 1 3977843)
 (vectors 8 47124)
 (vector-slots 4 1546569 34262)
 (floats 8 353 743)
 (intervals 28 46900 3537)
 (buffers 516 60))

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

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

[Noam Postavsky]

On Wed, Jun 28, 2017 at 7:31 AM, Vincent Belaïche
<vincent.belaiche@gmail.com> wrote:
> When trying to build the latest on master branch, I get this error:
>
> --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
> configure: error: The following required libraries were not found:
>      gnutls
> Maybe some development libraries/packages are missing?
> If you don't want to link with them give
>      --with-gnutls=no
> as options to configure
> --8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----
>
> I am using configure with the following command line:
>
> --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
>   ./configure --prefix=c:/Nos_Programmes/GNU/Emacs \
>                           --without-jpeg \
>                           --without-tiff \
>                           --without-gif \
>                           --without-png \
>                           --with-gnutls=no
> --8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

>
> So I am surprised. Also without `--with-gnutls=no' I get the same error
> message, although I have put under my mingw directory the gnutls binary
> from sourceforge EZWinPorts, but configure does not detect its presence.

./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

   pkg-config --debug gnutls

> Having or not --with-gnutls=no does not change the outcome as far as
> error message is concerned. I am a bit confused because in the configure
> --help, `--without-gnutls' is mentioned instead of `--with-gnutls=no'. I
> tried `--without-gnutls' and the compilation went through. So this is an error in the message given by configure.

Using --with-gnutls=no works for me, is it possible you have some
extra whitespace after one of the backslashes?

> Well, when I am writing the the compilation went through, this is not up
> to the end, because I got this later on:
>
> --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
> Loading c:/Programmes/installation/emacs-install/master/emacs/lisp/emacs-lisp/eldoc.el (source)...
> dumped_data_commit: memory exhausted.
> Enlarge dumped_data[]!
> mv -f emacs.exe bootstrap-emacs.exe
> mv: cannot stat `emacs.exe': No such file or directory
> make[2]: *** [bootstrap-emacs.exe] Error 1
> --8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

Hmm, doesn't happen for me, but you can try enlarging DUMPED_HEAP_SIZE
in src/w32heap.c

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

[Vincent Belaïche]

Answers below...

Le 28/06/2017 à 16:09, Noam Postavsky a écrit :
> On Wed, Jun 28, 2017 at 7:31 AM, Vincent Belaïche
> <vincent.belaiche@gmail.com> wrote:
>> When trying to build the latest on master branch, I get this error:
>>
>> --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
>> configure: error: The following required libraries were not found:
>>      gnutls
>> Maybe some development libraries/packages are missing?
>> If you don't want to link with them give
>>      --with-gnutls=no
>> as options to configure
>> --8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----
>>
>> I am using configure with the following command line:
>>
>> --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
>>   ./configure --prefix=c:/Nos_Programmes/GNU/Emacs \
>>                           --without-jpeg \
>>                           --without-tiff \
>>                           --without-gif \
>>                           --without-png \
>>                           --with-gnutls=no
>> --8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----
>
>>
>> So I am surprised. Also without `--with-gnutls=no' I get the same error
>> message, although I have put under my mingw directory the gnutls binary
>> from sourceforge EZWinPorts, but configure does not detect its presence.
>
> ./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:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
# Process this file with autoconf to produce a pkg-config metadata file.

# Copyright (C) 2004-2012 Free Software Foundation, Inc.

# Copying and distribution of this file, with or without modification,
# are permitted in any medium without royalty provided the copyright
# notice and this notice are preserved.  This file is offered as-is,
# without any warranty.

# Author: Simon Josefsson

prefix=/mingw
exec_prefix=/mingw
libdir=/mingw/lib
includedir=/mingw/include/gnutls

Name: GnuTLS
Description: Transport Security Layer implementation for the GNU system
URL: http://www.gnutls.org/
Version: 3.3.13
Libs: -L${libdir} -lgnutls
# Libs.private: -Ld:/usr/lib -lgmp -lz -lintl -liconv -lws2_32
# Requires.private: nettle, hogweed, libtasn1, libidn, zlib
Cflags: -I${includedir}
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----



>
>    pkg-config --debug gnutls

After doing these tricks about gnutls.pc, I get this:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
$ pkg-config --debug gnutls
no output option set, defaulting to --exists
Error printing disabled by default due to use of output options --exists, --atleast/exact/max-version or no output option at all. Value of --print-errors: 0
Error printing disabled
Adding virtual 'pkg-config' package to list of known packages
Scanning directory 'c:/Nos_Programmes/MinGW/mingw-w32/lib/pkgconfig'
Ignoring file '.' in search directory; not a .pc file
Ignoring file '..' in search directory; not a .pc file
File 'gnutls.pc' appears to be a .pc file
Will find package 'gnutls' in file 'c:/Nos_Programmes/MinGW/mingw-w32/lib/pkgconfig\gnutls.pc'
Ignoring file 'gnutls.pc-original' in search directory; not a .pc file
Ignoring file 'gnutls.pc~' in search directory; not a .pc file
File 'libpng.pc' appears to be a .pc file
Will find package 'libpng' in file 'c:/Nos_Programmes/MinGW/mingw-w32/lib/pkgconfig\libpng.pc'
File 'libpng16.pc' appears to be a .pc file
Will find package 'libpng16' in file 'c:/Nos_Programmes/MinGW/mingw-w32/lib/pkgconfig\libpng16.pc'
Scanning directory 'c:/Nos_Programmes/MinGW/mingw-w32/share/pkgconfig'
Ignoring file '.' in search directory; not a .pc file
Ignoring file '..' in search directory; not a .pc file
Looking for package 'gnutls'
Looking for package 'gnutls-uninstalled'
Reading 'gnutls' from file 'c:/Nos_Programmes/MinGW/mingw-w32/lib/pkgconfig\gnutls.pc'
Parsing package file 'c:/Nos_Programmes/MinGW/mingw-w32/lib/pkgconfig\gnutls.pc'
  line>
  line>
  line>
  line>
  line>
  line>
  line>
  line>
  line>
  line>
  line>
  line>prefix=/mingw
 Variable declaration, 'prefix' overridden with 'c:/Nos_Programmes/MinGW/mingw-w32'
  line>exec_prefix=/mingw
 Variable declaration, 'exec_prefix' has value '/mingw'
  line>libdir=/mingw/lib
 Variable declaration, 'libdir' has value 'c:/Nos_Programmes/MinGW/mingw-w32/lib'
  line>includedir=/mingw/include/gnutls
 Variable declaration, 'includedir' has value 'c:/Nos_Programmes/MinGW/mingw-w32/include/gnutls'
  line>
  line>Name: GnuTLS
  line>Description: Transport Security Layer implementation for the GNU system
  line>URL: http://www.gnutls.org/
  line>Version: 3.3.13
  line>Libs: -L${libdir} -lgnutls
  line>
  line>
  line>Cflags: -I${includedir}
Path position of 'gnutls' is 1
Adding 'gnutls' to list of known packages
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

>
>> Having or not --with-gnutls=no does not change the outcome as far as
>> error message is concerned. I am a bit confused because in the configure
>> --help, `--without-gnutls' is mentioned instead of `--with-gnutls=no'. I
>> tried `--without-gnutls' and the compilation went through. So this is an error in the message given by configure.
>
> Using --with-gnutls=no works for me, is it possible you have some
> extra whitespace after one of the backslashes?

Well, I could not reproduce this issue. It seems that I had an
unrecognized option *after* --with-gnutls=no.

>
>> Well, when I am writing the the compilation went through, this is not up
>> to the end, because I got this later on:
>>
>> --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
>> Loading c:/Programmes/installation/emacs-install/master/emacs/lisp/emacs-lisp/eldoc.el (source)...
>> dumped_data_commit: memory exhausted.
>> Enlarge dumped_data[]!
>> mv -f emacs.exe bootstrap-emacs.exe
>> mv: cannot stat `emacs.exe': No such file or directory
>> make[2]: *** [bootstrap-emacs.exe] Error 1
>> --8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----
>
> Hmm, doesn't happen for me, but you can try enlarging DUMPED_HEAP_SIZE
> in src/w32heap.c

I could compile till the end with a slight increase as follows:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
diff --git a/src/w32heap.c b/src/w32heap.c
index 54de961..507412e 100644
--- 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
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----


I note that that current sizes between narrow and wide are not
consistent, as 21 is not the double of 12.

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----


My configuration is as follows:

   smtpmail-default-smtp-server  smtpmail-smtp-server
   smtpmail-stream-type          starttls
   smtpmail-starttls-credentials ((smtpmail-smtp-server smtpmail-smtp-service smtpmail-from-address nil))

   Vincent


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

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

[npostavs]

vincent.belaiche@gmail.com (Vincent Belaïche) writes:
>
> I could compile till the end with a slight increase as follows:
>
> --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
> diff --git a/src/w32heap.c b/src/w32heap.c
> index 54de961..507412e 100644
> --- 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
> --8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----
>
>
> I note that that current sizes between narrow and wide are not
> consistent, as 21 is not the double of 12.

Okay, I don't really understand how this heap size thing works, so I
hope someone more knowledgable will chime in.

> 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----

You also need to put the gnutls dll where Emacs can find it, e.g., next
to emacs.exe in bin/ (or elsewhere on %PATH%, I believe).

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

[Eli Zaretskii]

> 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.

> --- 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 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.

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

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

[Noam Postavsky]

close 27516
quit

vincent.belaiche@gmail.com (Vincent Belaïche) writes:

> 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.

I guess this can be closed by now.