bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Keith David Bershatsky]

I am trying to build Emacs on MS-Windows with support for images (and hopefully XPM too), using a combination of MinGW and GnuWin32.

MinGW has the following four (4) installations:

    mingw-get install mingw32-base

    mingw-get install msys-base

    mingw-get install autoconf

    mingw-get install automake

And, I ran the following from a MinGW shell:  mount c:/mingw /mingw

GnuWin32 has everything that comes with `download.bat`, with the extras offered during install, followed by `install c:\gnuwin32`

The recipe that I am using to build is as follows:

    export CPPFLAGS="-I/c/gnuwin32/include"

    export LDFLAGS="-L/c/gnuwin32/lib"

    export PATH=/c/mingw/bin:/c/mingw/msys/1.0/bin:/c/gnuwin32/bin

    ./autogen.sh

    ./configure --prefix=/c/docume~1/lawlist/desktop/trunk

    make

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; THE `CONFIGURE` STAGE LOOKS LIKE THIS:

***

Configured for 'i686-pc-mingw32'.

  Where should the build process find the source code?    .
  What compiler should emacs be built with?               gcc -std=gnu99  -g3 -O
2 -gdwarf-2
  Should Emacs use the GNU version of malloc?             no
    (The GNU allocators don't work with this system configuration.)
  Should Emacs use a relocating allocator for buffers?    no
  Should Emacs use mmap(2) for buffer allocation?         yes
  What window system should Emacs use?                    w32
  What toolkit should Emacs use?                          none
  Where do we find X Windows header files?                NONE
  Where do we find X Windows libraries?                   NONE
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   no
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes
  Does Emacs use a png library?                           yes
  Does Emacs use -lrsvg-2?                                no
  Does Emacs use cairo?                                   no
  Does Emacs use imagemagick?                             no
  Does Emacs support sound?                               yes
  Does Emacs use -lgpm?                                   no
  Does Emacs use -ldbus?                                  no
  Does Emacs use -lgconf?                                 no
  Does Emacs use GSettings?                               no
  Does Emacs use a file notification library?             yes (w32)
  Does Emacs use access control lists?                    yes
  Does Emacs use -lselinux?                               no
  Does Emacs use -lgnutls?                                no
  Does Emacs use -lxml2?                                  no
  Does Emacs use -lfreetype?                              no
  Does Emacs use -lm17n-flt?                              no
  Does Emacs use -lotf?                                   no
  Does Emacs use -lxft?                                   no
  Does Emacs directly use zlib?                           yes
  Does Emacs use toolkit scroll bars?                     yes

***

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; THE `MAKE` STAGE LOOKS LIKE THIS:

* * *

make[1]: Leaving directory `/c/docume~1/lawlist/desktop/emacs/nt'
make -C lib all
make[1]: Entering directory `/c/docume~1/lawlist/desktop/emacs/lib'
  GEN    alloca.h
  GEN    byteswap.h
  GEN    errno.h
  GEN    execinfo.h
  GEN    arg-nonnull.h
  GEN    getopt.h
  GEN    c++defs.h
  GEN    warn-on-use.h
  GEN    stddef.h
  GEN    string.h
  GEN    time.h
make  all-am
make[2]: Entering directory `/c/docume~1/lawlist/desktop/emacs/lib'
  CC     acl-errno-valid.o
  CC     acl-internal.o
  CC     get-permissions.o
  CC     binary-io.o
  CC     c-ctype.o
  CC     c-strcasecmp.o
  CC     c-strncasecmp.o
  CC     close-stream.o
  CC     count-one-bits.o
  CC     count-trailing-zeros.o
  CC     md5.o
  CC     sha1.o
  CC     sha256.o
  CC     sha512.o
  CC     dtoastr.o
  CC     dtotimespec.o
  CC     filemode.o
  CC     gettime.o
  CC     qcopy-acl.o
  CC     stat-time.o
  CC     strftime.o
  CC     timespec.o
  CC     timespec-add.o
  CC     timespec-sub.o
  CC     u64.o
  CC     utimens.o
  CC     acl_entries.o
  CC     execinfo.o
  CC     fpending.o
  CC     getopt.o
  CC     getopt1.o
  CC     memrchr.o
  CC     mktime.o
  CC     sig2str.o
  CC     stpcpy.o
  CC     time_r.o
  CC     time_rz.o
  CC     timegm.o
  AR     libgnu.a
make[2]: Leaving directory `/c/docume~1/lawlist/desktop/emacs/lib'
make[1]: Leaving directory `/c/docume~1/lawlist/desktop/emacs/lib'
make -C lib-src all
make[1]: Entering directory `/c/docume~1/lawlist/desktop/emacs/lib-src'
  CC       regex.o
  CC       ntlib.o
  CCLD     etags.exe
  CCLD     ctags.exe
  CCLD     emacsclient.exe
  RC       emacsclient.res
  CCLD     emacsclientw.exe
  CCLD     ebrowse.exe
  CCLD     profile.exe
  CC       pop.o
  CCLD     movemail.exe
  CCLD     hexl.exe
  CCLD     update-game-score.exe
  CCLD     make-docfile.exe
make[1]: Leaving directory `/c/docume~1/lawlist/desktop/emacs/lib-src'
make -C src VCSWITNESS='' all
make[1]: Entering directory `/c/docume~1/lawlist/desktop/emacs/src'
  GEN      lisp.mk
make[1]: Leaving directory `/c/docume~1/lawlist/desktop/emacs/src'
make[1]: Entering directory `/c/docume~1/lawlist/desktop/emacs/src'
  GEN      globals.h
  CC       firstfile.o
  CC       dispnew.o
  CC       frame.o
  CC       scroll.o
  CC       xdisp.o
  CC       menu.o
  CC       window.o
  CC       charset.o
  CC       coding.o
  CC       category.o
  CC       ccl.o
  CC       character.o
  CC       chartab.o
  CC       bidi.o
  CC       term.o
  CC       terminal.o
  CC       xfaces.o
  CC       emacs.o
  CC       keyboard.o
  CC       macros.o
  CC       keymap.o
  CC       sysdep.o
  CC       buffer.o
  CC       filelock.o
  CC       insdel.o
  CC       marker.o
  CC       minibuf.o
  CC       fileio.o
  CC       dired.o
  CC       cmds.o
  CC       casetab.o
  CC       casefiddle.o
  CC       indent.o
  CC       search.o
  CC       regex.o
  CC       undo.o
  CC       alloc.o
  CC       data.o
  GEN      buildobj.h
  CC       doc.o
  CC       editfns.o
  CC       callint.o
  CC       eval.o
  CC       floatfns.o
  CC       fns.o
fns.c: In function 'secure_hash':
fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)
       digest_size = MD5_DIGEST_SIZE;
                     ^
fns.c:4863:21: note: each undeclared identifier is reported only once for each f
unction it appears in
fns.c:4864:21: error: 'md5_buffer' undeclared (first use in this function)
       hash_func   = md5_buffer;
                     ^
make[1]: *** [fns.o] Error 1
make[1]: Leaving directory `/c/docume~1/lawlist/desktop/emacs/src'
make: *** [src] Error 2

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Glenn Morris]

Keith David Bershatsky wrote:

> fns.c: In function 'secure_hash':
> fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

Perhaps the first hit on a web search is relevant:

https://lists.gnu.org/archive/html/help-emacs-windows/2011-09/msg00022.html

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Keith David Bershatsky]

Thank you, Glenn, for the reference to the mail-list archives regarding moving `C:\gnuwin32\include\md5.h` out of the way.

Building the latest version of Emacs trunk master branch on Windows is by no stretch of the imagination as simple as the first Google search.  There is a reason that only one person in the entire world is posting Windows trunk builds every few weeks -- i.e., building Emacs on Windows is completely beyond the reach of mere mortals, and out of the reach of beginning programmers and hobbyists such as myself (without the assistance of advanced programmers such as you and Eli).

I renamed it to `md5.h.off` and tried my luck at building Emacs again, but was met with the error below.  I also tried my luck at building and incorporating into the `mingw` directory the following five (5) libraries -- zlib, giflib, libpng, jpeg and libpng -- in an effort to remove `gnuwin32` from the equation entirely; however, I was met with the same error message below.

* * *

In auth-source-backend-parse:
gnus/auth-source.el:523:7:Warning: Obsolete name arg "Empty" to constructor
    auth-source-backend
* * * 

In auth-source-search-backends:
gnus/auth-source.el:786:34:Warning: Unknown slot `:type'
gnus/auth-source.el:787:15:Warning: Unknown slot `:source'
  ELC      gnus/canlock.elc
  ELC      gnus/compface.elc
  ELC      gnus/deuglify.elc
utf7.el: `mm-with-unibyte-current-buffer' is an obsolete macro (as of 25.1).
mml2015.el: `mm-with-unibyte-current-buffer' is an obsolete macro (as of 25.1).
mml2015.el: `mm-with-unibyte-current-buffer' is an obsolete macro (as of 25.1).
mml2015.el: `mm-with-unibyte-current-buffer' is an obsolete macro (as of 25.1).
make[2]: *** [gnus/deuglify.elc] Error 3
make[2]: Leaving directory `/c/docume~1/lawlist/desktop/emacs/lisp'
make[2]: Entering directory `/c/docume~1/lawlist/desktop/emacs/lisp'
  ELC      mh-e/mh-thread.elc
No MH variant found on the system
make[2]: *** [mh-e/mh-thread.elc] Error 3
make[2]: Leaving directory `/c/docume~1/lawlist/desktop/emacs/lisp'
make[2]: Entering directory `/c/docume~1/lawlist/desktop/emacs/lisp'
  ELC      url/url.elc
make[2]: *** [url/url.elc] Error 3
make[2]: Leaving directory `/c/docume~1/lawlist/desktop/emacs/lisp'
make[1]: *** [compile-main] Error 2
make[1]: Leaving directory `/c/docume~1/lawlist/desktop/emacs/lisp'
make: *** [lisp] Error 2


Any additional help would sure be greatly appreciated.

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Tue, 29 Sep 2015 21:34:45 -0400,
Glenn Morris wrote:
> 
> Keith David Bershatsky wrote:
> 
> > fns.c: In function 'secure_hash':
> > fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)
> 
> Perhaps the first hit on a web search is relevant:
> 
> https://lists.gnu.org/archive/html/help-emacs-windows/2011-09/msg00022.html

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Keith David Bershatsky]

Eureka!  I now have a working recipe to build Emacs on WindowsXP with image support.  It ended up being a combination of mingw32, ezwinports, and xpm from GnuWin.  I will write up a current "cheat sheet" on emacs.stackexchange.com in the near future -- I opened a question there a couple of days ago.

The build fails at least a couple of ways on WindowsXP as described in this bug report #21590 when using GnuWin32, so there should probably be a strong warning (near the top) in the Emacs INSTALL readme file advising against using that resource -- and suggesting the use of ezwinports instead.  Alternatively, it may be a good idea at some point for the Emacs team to find out why Emacs fails (beyond just moving `md5.h` out of the way) to build with GnuWin32 and create a workaround in the building scripts, etc. since others will undoubtedly try to use that resource in the future.

Eli:  As a feature request, please consider adding an XPM zip archive to ezwinports as this portion of the build recipe is more complicated than it needs to be.

Here is the rough outline of the recipe for building Emacs master branch on Windows XP -- thank you all for helping me to get passed several hurdles until finally reaching a working solution:

;; https://git-scm.com/download/win
Git-2.5.3-32-bit.exe
Run the installer.
Next
Next
Standard installation directory is `C:\Program Files\Git`, but I chose instead:  c:\git
Select components:  default is okay, but I chose nothing instead.
Select start menu folder:  default is okay, bit I chose not to create a folder instead.
Adjusting your PATH environment:  default is okay:  Use Git from Bash only.
;; For this next section, pay close attention to the non-default setting -- see Emacs bug #21582.
Configure the line ending conversions:  Emacs requires a non-default setting of "checkout as-is, commit as-is"
Configuring the terminal emulator to use with Git Bash:  default is okay:  Use MinTTY (the default terminal of MSys2)
Configuring experimental performance tweaks:  I chose NOT to "Enable file system caching".
Finish [view release notes if so desired]

;; http://www.mingw.org/wiki/Getting_Started
;; mingw-get-setup.exe
c:\mingw\bin\mingw-get install mingw32-base
c:\mingw\bin\mingw-get install msys-base
c:\mingw\bin\mingw-get install autoconf
c:\mingw\bin\mingw-get install automake
c:\mingw\bin\mingw-get install msys-coreutils
c:\mingw\msys\1.0\msys.bat
mount c:/mingw /mingw

;; https://sourceforge.net/projects/ezwinports/files/
;; unzip all of the following ezwinports packages into `c:/mingw`, overwriting any duplicates.
giflib-5.1.0-w32-bin.zip
gnutls-3.3.11-w32-bin.zip
jpeg-v9a-w32-bin.zip
libpng-1.6.12-w32-bin.zip
libxml2-2.7.8-w32-bin.zip
mingw-get-setup.exe
tiff-4.0.3-w32-bin.zip
zlib-1.2.8-2-w32-bin.zip

;; https://sourceforge.net/projects/gnuwin32/files/xpm/3.5.1-1/
;; Obtain from:  xpm-3.5.1-1-src.zip
;; Obtain from:  xpm-3.5.1-1-src.zip
;; extract `simx.h` from `xpm-3.5.1-1-src/src/xpm/3.5.1/libXpm-3.5.1-src/lib/simx.h`
;; extract `xpm.h` from `/Users/HOME/Desktop/xpm-3.5.1-1-src/src/xpm/3.5.1/libXpm-3.5.1-src/lib/xpm.h`
;; extract `xpm4.dll` from `/Users/HOME/Desktop/xpm-3.5.1-1-bin/bin/xpm4.dll`
;; copy `simx.h` to `C:\mingw\include`
;; copy `xpm.h` to `C:\mingw\include\X11` -- create that directory.
;; copy `xpm4.dll` to `C:\mingw\bin`

c:\git\git-bash.exe

cd /c/docume~1/lawlist/desktop/

git clone -b master git://git.sv.gnu.org/emacs.git

c:\mingw\msys\1.0\msys.bat

cd /c/docume~1/lawlist/desktop/emacs

./autogen.sh

./configure --prefix=/c/docume~1/lawlist/desktop/trunk

make

make install

;; copy the following files to the `/bin` directory where `emacs.exe` is located.
giflib4.dll
jpeg62.dll
libXpm.dll
libpng16-16.dll
libtiff3.dll
xpm4.dll
zlib1.dll

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Keith David Bershatsky]

Here is the updated `cheat sheet` to building Emacs master branch on MS-Windows.  Future updates will be made to the applicable thread on emacs.stackexchange.com

http://emacs.stackexchange.com/q/16971/2287


This answer was tested on WindowsXP--SP3.  The installation paths will need to be adjusted based on the individual preferences of the user.  In this example:

-  The desktop is:  `C:\Documents and Settings\lawlist\Desktop`

-  The `git` installation is:  `C:\git`

-  The `MinGW` installation is:  `C:\mingw`

-  The git download location of Emacs master branch is: `C:\Documents and Settings\lawlist\Desktop\emacs`

-  The target for Emacs installation is:  `C:\Documents and Settings\lawlist\Desktop\trunk`


**Step Number 1**:  Install `git` and be sure to select "checkout as-is, commit as-is" during installation:

https://git-scm.com/download/win

Git-2.5.3-32-bit.exe

Run the installer.

Next

Next

Standard installation directory is `C:\Program Files\Git`, but I chose instead:  c:\git

Select components:  default is okay, but I chose nothing instead.

Select start menu folder:  default is okay, bit I chose not to create a folder instead.

Adjusting your PATH environment:  default is okay:  Use Git from Bash only.

;; For this next section, pay close attention to the non-default setting -- see Emacs bug #21582.

Configure the line ending conversions:  Emacs requires a non-default setting of "checkout as-is, commit as-is"

Configuring the terminal emulator to use with Git Bash:  default is okay:  Use MinTTY (the default terminal of MSys2)

Configuring experimental performance tweaks:  I chose NOT to "Enable file system caching".

Finish [view release notes if so desired]


**Step Number 2**:  Install `MinGW`

http://www.mingw.org/wiki/Getting_Started

mingw-get-setup.exe

    c:\mingw\bin\mingw-get install mingw32-base

    c:\mingw\bin\mingw-get install msys-base

    c:\mingw\bin\mingw-get install autoconf

    c:\mingw\bin\mingw-get install automake

    c:\mingw\bin\mingw-get install msys-coreutils

    c:\mingw\msys\1.0\msys.bat

    mount c:/mingw /mingw


**Step Number 3**:  Download the following `ezwinports` zipped packages and extract to the root `mingw` directory.

https://sourceforge.net/projects/ezwinports/files/

;; unzip all of the following ezwinports packages into `c:/mingw`, overwriting any duplicates.

`gdk-pixbuf-2.30.2-w32-bin.zip`

`giflib-5.1.0-w32-bin.zip`

`glib-2.38.2-w32-bin.zip`

`gnutls-3.3.11-w32-bin.zip`

`jpeg-v9a-w32-bin.zip`

`libpng-1.6.12-w32-bin.zip`

`librsvg-2.40.1-2-w32-bin.zip`

`libxml2-2.7.8-w32-bin.zip`

`tiff-4.0.3-w32-bin.zip`

`zlib-1.2.8-2-w32-bin.zip`


**Step Number 4**:  Obtain support for XPM.

https://sourceforge.net/projects/gnuwin32/files/xpm/3.5.1-1/

;; download:  `xpm-3.5.1-1-src.zip`

;; download:  `xpm-3.5.1-1-src.zip`

;; extract `simx.h` from `xpm-3.5.1-1-src/src/xpm/3.5.1/libXpm-3.5.1-src/lib/simx.h`

;; extract `xpm.h` from `xpm-3.5.1-1-src/src/xpm/3.5.1/libXpm-3.5.1-src/lib/xpm.h`

;; extract `xpm4.dll` from `xpm-3.5.1-1-bin/bin/xpm4.dll`

;; copy `simx.h` to `C:\mingw\include`

;; copy `xpm.h` to `C:\mingw\include\X11` -- create that directory.

;; copy `xpm4.dll` to `C:\mingw\bin`


**Step Number 5**:  Download the latest Emacs master branch source files using a `git-bash` shell

    c:\git\git-bash.exe

    cd /c/docume~1/lawlist/desktop/

    git clone -b master git://git.sv.gnu.org/emacs.git

;; close the `git-bash`


**Step Number 6**:  Build the Emacs master branch and copy over the .dll files when done.

;; open generic Command Prompt

    c:\mingw\msys\1.0\msys.bat
    
    cd /c/docume~1/lawlist/desktop/emacs
    
    ./autogen.sh
    
    ./configure --prefix=/c/docume~1/lawlist/desktop/trunk
    
    make
    
    make install
    
    ;; copy the following files to the `/bin` directory where `emacs.exe` is located.
    
    cp /c/mingw/bin/xpm4.dll /c/docume~1/lawlist/desktop/trunk/bin/xpm4.dll
    
    cp /c/mingw/bin/libpng16-16.dll /c/docume~1/lawlist/desktop/trunk/bin/libpng16-16.dll
    
    cp /c/mingw/bin/libtiff-5.dll /c/docume~1/lawlist/desktop/trunk/bin/libtiff-5.dll
    
    cp /c/mingw/bin/libjpeg-9.dll /c/docume~1/lawlist/desktop/trunk/bin/libjpeg-9.dll
    
    cp /c/mingw/bin/libgif-7.dll /c/docume~1/lawlist/desktop/trunk/bin/libgif-7.dll
    
    cp /c/mingw/bin/librsvg-2-2.dll /c/docume~1/lawlist/desktop/trunk/bin/librsvg-2-2.dll
    
    cp /c/mingw/bin/libgdk_pixbuf-2.0-0.dll /c/docume~1/lawlist/desktop/trunk/bin/libgdk_pixbuf-2.0-0.dll
    
    cp /c/mingw/bin/libglib-2.0-0.dll /c/docume~1/lawlist/desktop/trunk/bin/libglib-2.0-0.dll
    
    cp /c/mingw/bin/libgobject-2.0-0.dll /c/docume~1/lawlist/desktop/trunk/bin/libgobject-2.0-0.dll
    
    cp /c/mingw/bin/libgnutls-28.dll /c/docume~1/lawlist/desktop/trunk/bin/libgnutls-28.dll
    
    cp /c/mingw/bin/libxml2-2.dll /c/docume~1/lawlist/desktop/trunk/bin/libxml2-2.dll
    
    cp /c/mingw/bin/zlib1.dll /c/docume~1/lawlist/desktop/trunk/bin/zlib1.dll

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Tue, 29 Sep 2015 21:34:45 -0400
> Cc: 21590@debbugs.gnu.org
> 
> Keith David Bershatsky wrote:
> 
> > fns.c: In function 'secure_hash':
> > fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)
> 
> Perhaps the first hit on a web search is relevant:
> 
> https://lists.gnu.org/archive/html/help-emacs-windows/2011-09/msg00022.html

Yes.  And I still stand up by my advice later on:

  https://lists.gnu.org/archive/html/help-emacs-windows/2011-09/msg00024.html

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Eli Zaretskii]

> Date:  Wed, 30 Sep 2015 14:26:08 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  21590@debbugs.gnu.org
> 
> Eureka!  I now have a working recipe to build Emacs on WindowsXP with image support.  It ended up being a combination of mingw32, ezwinports, and xpm from GnuWin.  I will write up a current "cheat sheet" on emacs.stackexchange.com in the near future -- I opened a question there a couple of days ago.
> 
> The build fails at least a couple of ways on WindowsXP as described in this bug report #21590 when using GnuWin32, so there should probably be a strong warning (near the top) in the Emacs INSTALL readme file advising against using that resource -- and suggesting the use of ezwinports instead.  Alternatively, it may be a good idea at some point for the Emacs team to find out why Emacs fails (beyond just moving `md5.h` out of the way) to build with GnuWin32 and create a workaround in the building scripts, etc. since others will undoubtedly try to use that resource in the future.

GnuWin32 is the last resort.  If you cannot find something in other
places, you have either to look there or build your own ports.  The
latter is not something many people will consider on Windows.

And yes, some GnuWin32 need "tinkering".

> Eli:  As a feature request, please consider adding an XPM zip archive to ezwinports as this portion of the build recipe is more complicated than it needs to be.

We provide libXpm from the GNU FTP site, right near the Emacs Windows
binaries.  Building libXpm on Windows (actually, anything that lacks
X11) is not trivial, since you must hack out large parts of the code
that assume X.  At the time I decided not to port a new version of
libXpm because the new features were insignificant (or even absent, I
don't remember), whereas the existing port works very well for Emacs.

I see now that the information about libXpm availability is missing
from nt/INSTALL, so I will add it soon.

> Here is the rough outline of the recipe for building Emacs master branch on Windows XP -- thank you all for helping me to get passed several hurdles until finally reaching a working solution:

We have detailed instructions for this in nt/INSTALL.  It would be
good if you could compare your experience with what that file says,
and suggest any changes/additions.

Thanks.

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Eli Zaretskii]

> Date: Tue, 29 Sep 2015 21:04:35 -0700
> From: Keith David Bershatsky <esq@lawlist.com>
> Cc: 21590@debbugs.gnu.org
> 
> Thank you, Glenn, for the reference to the mail-list archives regarding moving `C:\gnuwin32\include\md5.h` out of the way.
> 
> Building the latest version of Emacs trunk master branch on Windows is by no stretch of the imagination as simple as the first Google search.  There is a reason that only one person in the entire world is posting Windows trunk builds every few weeks -- i.e., building Emacs on Windows is completely beyond the reach of mere mortals, and out of the reach of beginning programmers and hobbyists such as myself (without the assistance of advanced programmers such as you and Eli).

This is somewhat inaccurate.  What _is_ hard is creating a
well-organized MSYS/MinGW development environment.  This is more or
less a one-time effort, and it does take some time, blood and tears.
In effect, you are creating by hand a sophisticated environment that
any Posix system has for you out of the box.  So it's a little wonder
that part is not simple, even before we consider the few Windows
specific tricks one must pull for that environment to be rock-solid.

But once you are through that one-time effort, the actual building of
Emacs presents no problems at all.  It "just works", as on any Posix
system.

We provide detailed instructions for building Emacs in Windows in
nt/INSTALL.  Most of the information in that file is dedicated to that
first step -- creating a stable, coherent development environment.
The experience I and others gained while achieving that goal is
described there, complete with several notable gotchas and how to
avoid them.  It would be good if you could read that file, now armed
with your own experience, and provide feedback, so that the
instructions could be improved where they need improvement.

> I renamed it to `md5.h.off` and tried my luck at building Emacs again, but was met with the error below.  I also tried my luck at building and incorporating into the `mingw` directory the following five (5) libraries -- zlib, giflib, libpng, jpeg and libpng -- in an effort to remove `gnuwin32` from the equation entirely; however, I was met with the same error message below.
> 
> * * *
> 
> In auth-source-backend-parse:
> gnus/auth-source.el:523:7:Warning: Obsolete name arg "Empty" to constructor
>     auth-source-backend
> * * * 
> 
> In auth-source-search-backends:
> gnus/auth-source.el:786:34:Warning: Unknown slot `:type'
> gnus/auth-source.el:787:15:Warning: Unknown slot `:source'
>   ELC      gnus/canlock.elc
>   ELC      gnus/compface.elc
>   ELC      gnus/deuglify.elc
> utf7.el: `mm-with-unibyte-current-buffer' is an obsolete macro (as of 25.1).
> mml2015.el: `mm-with-unibyte-current-buffer' is an obsolete macro (as of 25.1).
> mml2015.el: `mm-with-unibyte-current-buffer' is an obsolete macro (as of 25.1).
> mml2015.el: `mm-with-unibyte-current-buffer' is an obsolete macro (as of 25.1).
> make[2]: *** [gnus/deuglify.elc] Error 3
> make[2]: Leaving directory `/c/docume~1/lawlist/desktop/emacs/lisp'
> make[2]: Entering directory `/c/docume~1/lawlist/desktop/emacs/lisp'
>   ELC      mh-e/mh-thread.elc
> No MH variant found on the system
> make[2]: *** [mh-e/mh-thread.elc] Error 3
> make[2]: Leaving directory `/c/docume~1/lawlist/desktop/emacs/lisp'
> make[2]: Entering directory `/c/docume~1/lawlist/desktop/emacs/lisp'
>   ELC      url/url.elc
> make[2]: *** [url/url.elc] Error 3
> make[2]: Leaving directory `/c/docume~1/lawlist/desktop/emacs/lisp'
> make[1]: *** [compile-main] Error 2
> make[1]: Leaving directory `/c/docume~1/lawlist/desktop/emacs/lisp'
> make: *** [lisp] Error 2

I'm guessing that "Error 3" means Emacs aborted.  If that problem
still exists, we will need the details, like running the compilation
command under GDB.

Thanks.

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Eli Zaretskii]

> Date:  Wed, 30 Sep 2015 14:26:08 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  21590@debbugs.gnu.org
> 
> Eli:  As a feature request, please consider adding an XPM zip archive to ezwinports as this portion of the build recipe is more complicated than it needs to be.

Done.

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Keith David Bershatsky]

Thank you very much, Eli, for implementing the feature request -- greatly appreciated!  :)

Keith

At Thu, 01 Oct 2015 18:54:27 +0300,
Eli Zaretskii wrote:
> 
> > Date:  Wed, 30 Sep 2015 14:26:08 -0700
> > From:  Keith David Bershatsky <esq@lawlist.com>
> > Cc:  21590@debbugs.gnu.org
> > 
> > Eli:  As a feature request, please consider adding an XPM zip archive to ezwinports as this portion of the build recipe is more complicated than it needs to be.
> 
> Done.

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Eli Zaretskii]

> Date:  Thu, 01 Oct 2015 15:15:28 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  21590@debbugs.gnu.org
> 
> Thank you very much, Eli, for implementing the feature request -- greatly appreciated!  :)

You are welcome.

Are you using that port of libXpm?  Does it work well for you?  I
couldn't give it too much testing, since I have Emacs sessions open
that use the old one.  So I hesitate whether to update nt/INSTALL
already to point to this port.  WDYT?

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Keith David Bershatsky]

I tracked down another build discrepancy this evening relating to a failure to find `iconv.h`.  It is caused because the default new installation of MinGW comes with a later version of libiconv than used by ezwinports.  I am pretty certain the error comes about when adding `cairo-1.12.16-w32-bin.zip` from ezwinports for the purposes mentioned in the `.../emacs/nt/INSTALL` readme file.  It might be caused by adding `p11-kit-0.9-w32-bin.zip` or `pkg-config-0.28-w32-bin.zip`, but I don't think so.  I have run so many builds recently, it's hard to keep track.

I think the process of installing packages with MingGW has changed since the early days when the `.../emacs/nt/INSTALL` was written.  There are references on the internet about placing the archives into the main root MinGW directory and they will supposedly be recognized automatically; however, the current installer seems to be using `C:\mingw\var\cache\mingw-get\packages` for storing the default repositories.  Placing the ezwinports dependencies into the MinGW root directory or the latter packages directory is insufficient for the old libiconv to be seen as an available install in the graphical installation utility for MinGW.  After a ton of Googles, I came up with the following to remove the repository default of 1.14-3 and replace it with the older version:

c:\mingw\bin\mingw-get remove mingw32-libiconv

c:\mingw\bin\mingw-get install "libiconv=1.13.1-1"

The result is that the Emacs build no longer fails for failure to find `iconv.h`.

I'm not sure how the issue above should be dealt with, but it certainly was time consuming tracking it down.


On a different note, I haven't been able to configure `guntls` so that it shows up automatically as an available "yes" Emacs install following a plain `./configure --prefix=/my/path`.  I have extracted all of the following from ezwinports to the MinGW root:

gnutls-3.3.11-w32-bin.zip
p11-kit-0.9-w32-bin.zip
pkg-config-0.28-w32-bin.zip
gdk-pixbuf-2.30.2-w32-bin.zip
giflib-5.1.0-w32-bin.zip
glib-2.38.2-w32-bin.zip
jpeg-v9a-w32-bin.zip
libpng-1.6.12-w32-bin.zip
librsvg-2.40.1-2-w32-bin.zip
libxml2-2.7.8-w32-bin.zip
tiff-4.0.3-w32-bin.zip
zlib-1.2.8-2-w32-bin.zip
libXpm-3.5.11-w32-bin.zip
cairo-1.12.16-w32-bin.zip

Any ideas on how to make the guntls option show up as `yes` when running `./configure` would be greatly appreciated.  Perhaps it's another dependency issue where something in MinGW is newer and needs to be downgraded?

Thanks,

Keith

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Keith David Bershatsky]

Yes, I extracted the new `libXpm-3.5.11-w32-bin.zip` from ezwinports this morning to my MinGW root, and removed the old ones, and built a new Emacs trunk master branch a few times today.  The installs went without incident, and the pretty toolbar buttons and my custom minor-mode that uses XPM overlays are working well with `libXpm-3.5.11-w32-bin.zip` and the new Emacs build.

In terms of the nt/INSTALL, it is certainly a lot easier extracting `libXpm-3.5.11-w32-bin.zip` than manually pulling out the three (3) essential files from `libxpm-3.5.8-w32-src.zip` and manually copying them to the MinGW directory.  I found a reference to the needed files by Googling and reading:  http://www.emacswiki.org/emacs/BuildingCvsWThirtyTwoMingw -- without that wiki mention of the three files, it would have taken much longer to figure it out.

Keith

At Fri, 02 Oct 2015 09:45:56 +0300,
Eli Zaretskii wrote:
> 
> ***
> 
> Are you using that port of libXpm?  Does it work well for you?  I
> couldn't give it too much testing, since I have Emacs sessions open
> that use the old one.  So I hesitate whether to update nt/INSTALL
> already to point to this port.  WDYT?

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Eli Zaretskii]

> Date:  Fri, 02 Oct 2015 00:00:13 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  21590@debbugs.gnu.org
> 
> I tracked down another build discrepancy this evening relating to a failure to find `iconv.h`.  It is caused because the default new installation of MinGW comes with a later version of libiconv than used by ezwinports.  I am pretty certain the error comes about when adding `cairo-1.12.16-w32-bin.zip` from ezwinports for the purposes mentioned in the `.../emacs/nt/INSTALL` readme file.  It might be caused by adding `p11-kit-0.9-w32-bin.zip` or `pkg-config-0.28-w32-bin.zip`, but I don't think so.  I have run so many builds recently, it's hard to keep track.

I can only give one advice: do NOT use that newer libiconv (and the
corresponding new libintl).  They are buggy.  They will cause Emacs to
crash on exit.  See this discussion, for example:

  http://lists.gnu.org/archive/html/help-emacs-windows/2015-06/msg00017.html

(it continues into the next month).  There are more similar reports in
the archives.

Always use the libraries from ezwinports.  They are reliable, tested
by many users (myself included) on quite a few different Windows
platforms.  Save yourself a lot of time and hair by refusing to
upgrade to these 2 newer MinGW packages.  I understand this is not
easy if you use mingw-get (I don't), but there's no other way,
unfortunately.

> I think the process of installing packages with MingGW has changed since the early days when the `.../emacs/nt/INSTALL` was written.  There are references on the internet about placing the archives into the main root MinGW directory and they will supposedly be recognized automatically; however, the current installer seems to be using `C:\mingw\var\cache\mingw-get\packages` for storing the default repositories.

I don't understand what do you mean by "repositories".  Where the
packages in their .tar.lzma form are stored is irrelevant.  What
matters is the root of the MinGW installation -- AFAIK this still
defaults to C:\mingw32.

> Placing the ezwinports dependencies into the MinGW root directory or the latter packages directory is insufficient for the old libiconv to be seen as an available install in the graphical installation utility for MinGW.

I don't think you are right, but I don't really understand what you
are saying.  Please describe where you have the libiconv files and how
do you see them "not seen as available".

> After a ton of Googles, I came up with the following to remove the repository default of 1.14-3 and replace it with the older version:
> 
> c:\mingw\bin\mingw-get remove mingw32-libiconv
> 
> c:\mingw\bin\mingw-get install "libiconv=1.13.1-1"
> 
> The result is that the Emacs build no longer fails for failure to find `iconv.h`.

Where was iconv.h before, and how (with what error message) did the
build fail?

> On a different note, I haven't been able to configure `guntls` so that it shows up automatically as an available "yes" Emacs install following a plain `./configure --prefix=/my/path`.  I have extracted all of the following from ezwinports to the MinGW root:
> 
> gnutls-3.3.11-w32-bin.zip
> p11-kit-0.9-w32-bin.zip
> pkg-config-0.28-w32-bin.zip
> gdk-pixbuf-2.30.2-w32-bin.zip
> giflib-5.1.0-w32-bin.zip
> glib-2.38.2-w32-bin.zip
> jpeg-v9a-w32-bin.zip
> libpng-1.6.12-w32-bin.zip
> librsvg-2.40.1-2-w32-bin.zip
> libxml2-2.7.8-w32-bin.zip
> tiff-4.0.3-w32-bin.zip
> zlib-1.2.8-2-w32-bin.zip
> libXpm-3.5.11-w32-bin.zip
> cairo-1.12.16-w32-bin.zip
> 
> Any ideas on how to make the guntls option show up as `yes` when running `./configure` would be greatly appreciated.

Look in your config.log for the tests performed by the configure
script when it probes the system for GnuTLS availability.  If what's
there doesn't explain why it fails, post those parts here, and someone
will help you.

Here's what I have in my config.log about that:

  configure:12780: result: no
  configure:12801: checking for LIBGNUTLS
  configure:12808: $PKG_CONFIG --exists --print-errors "gnutls >= 2.6.6"
  configure:12811: $? = 0
  configure:12825: $PKG_CONFIG --exists --print-errors "gnutls >= 2.6.6"
  configure:12828: $? = 0
  configure:12866: result: yes
  configure:12877: checking for LIBGNUTLS3
  configure:12884: $PKG_CONFIG --exists --print-errors "gnutls >= 3.0.0"
  configure:12887: $? = 0
  configure:12901: $PKG_CONFIG --exists --print-errors "gnutls >= 3.0.0"
  configure:12904: $? = 0
  configure:12942: result: yes

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Eli Zaretskii]

> Date:  Fri, 02 Oct 2015 00:17:18 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  21590@debbugs.gnu.org
> 
> Yes, I extracted the new `libXpm-3.5.11-w32-bin.zip` from ezwinports this morning to my MinGW root, and removed the old ones, and built a new Emacs trunk master branch a few times today.  The installs went without incident, and the pretty toolbar buttons and my custom minor-mode that uses XPM overlays are working well with `libXpm-3.5.11-w32-bin.zip` and the new Emacs build.
> 
> In terms of the nt/INSTALL, it is certainly a lot easier extracting `libXpm-3.5.11-w32-bin.zip` than manually pulling out the three (3) essential files from `libxpm-3.5.8-w32-src.zip` and manually copying them to the MinGW directory.  I found a reference to the needed files by Googling and reading:  http://www.emacswiki.org/emacs/BuildingCvsWThirtyTwoMingw -- without that wiki mention of the three files, it would have taken much longer to figure it out.

OK, I've changed the instructions to point to ezwinports.  Thanks.

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[martin rudalics]

Thanks for the recipe.  Please keep it updated.

 > Here is the rough outline of the recipe for building Emacs master
 > branch on Windows XP -- thank you all for helping me to get passed
 > several hurdles until finally reaching a working solution:
[...]
 > Adjusting your PATH environment:  default is okay:  Use Git from Bash only.

IIUC you nowhere else mention whether and how you adjust PATH.

martin

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Eli Zaretskii]

> Date: Fri, 02 Oct 2015 10:36:44 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 21590@debbugs.gnu.org
> 
>  > Adjusting your PATH environment:  default is okay:  Use Git from Bash only.
> 
> IIUC you nowhere else mention whether and how you adjust PATH.

If you use that default, you don't need to, not for building Emacs.
If you want Git to be available for invocation from Emacs, then yes,
Git's bin/git.exe should be on PATH, or reachable by "other means"
(like a shell script, a.k.a. "batch file").

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[martin rudalics]

 >>   > Adjusting your PATH environment:  default is okay:  Use Git from Bash only.
 >>
 >> IIUC you nowhere else mention whether and how you adjust PATH.
 >
 > If you use that default, you don't need to, not for building Emacs.
 > If you want Git to be available for invocation from Emacs, then yes,
 > Git's bin/git.exe should be on PATH, or reachable by "other means"
 > (like a shell script, a.k.a. "batch file").

I was rather thinking about including the path of MinGW/bin/.  Or does
MSYS resolve that by itself?

martin

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Eli Zaretskii]

> Date: Fri, 02 Oct 2015 11:00:16 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: esq@lawlist.com, rgm@gnu.org, 21590@debbugs.gnu.org
> 
>  >>   > Adjusting your PATH environment:  default is okay:  Use Git from Bash only.
>  >>
>  >> IIUC you nowhere else mention whether and how you adjust PATH.
>  >
>  > If you use that default, you don't need to, not for building Emacs.
>  > If you want Git to be available for invocation from Emacs, then yes,
>  > Git's bin/git.exe should be on PATH, or reachable by "other means"
>  > (like a shell script, a.k.a. "batch file").
> 
> I was rather thinking about including the path of MinGW/bin/.

Ah, so I've misunderstood what you meant.  I thought you were talking
about including Git in PATH.

Yes, the bin directory where all the binaries are installed should be
on PATH.  The MinGW and MSYS installation instructions in nt/INSTALL
already have that described in detail, including a couple of caveats.

But I see now that I was mistaken even in my interpretation: a recent
change to autogen.sh invokes Git from that script, to install Git
hooks.  So I changed nt/INSTALL to include that bit.

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Keith David Bershatsky]

Thank you, Martin, for mentioning the git PATH -- I will update my "cheat-sheet" to set the PATH for `git` so that I don't receive an error message when running `autogen.sh` as to the `git` command not being found when it tries to update hooks, etc.

The advice by Eli on looking at the `config.log` to track down why gnutls was not available worked like a charm.  It told me that I was missing both `libtasn1` and `nettle`.  I downloaded and extracted `libtasn1-4.2-w32-bin.zip` and `nettle-2.7.1-w32-bin.zip` from ezwinports and now gnutls is detected during the configure and it says "yes" by default.

I didn't see any mention in the `gnutls` section of the `../emacs/nt/INSTALL` readme about the prerequisites of the above-mentioned two libraries `libtasn1` and `nettle`, so my suggestion would be to include a mention, and maybe even something about checking the `config.log` if there seems to be a problem.

The newer version of libiconv (i.e., 1.14-3) does not use `iconv.h`, so that is why the prior attempts at building emacs failed -- i.e., `missing` the file.  Downgrading libiconv to 1.13.1-1 produces the required `iconv.h`, and that resolves the error message regarding the missing header file.

The version of `libintl` installed in MinGW is 0.18.3.2-2 -- `mingw32-libintl`, which traces to mingw32-gettext.  What version, please, should I be using (so that I can locate and downgrade if needed)?

The `MinGW Installation Manager` (graphical user interface) has a reference to the "Installed Version" and the "Repository Version" and that is where I am getting my information and terminology.  Simply placing the .tar.lzma files in the mingw32 installation folder `C:\mingw32` or `C:\mingw\var\cache\mingw-get\packages` does not automatically make it show up in the installation manager.  I tried clicking on the menubar Installation - Update Catalogue, but that didn't produce the expected result of showing 1.13.1-1 as an available install option.  Ultimately, the following two command lines resolved the issue to remove libiconv 1.14-3 and then install 1.13.1-1.

c:\mingw\bin\mingw-get remove mingw32-libiconv

c:\mingw\bin\mingw-get install "libiconv=1.13.1-1"

Keith

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Eli Zaretskii]

> Date:  Fri, 02 Oct 2015 08:59:09 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  21590@debbugs.gnu.org
> 
> The advice by Eli on looking at the `config.log` to track down why gnutls was not available worked like a charm.  It told me that I was missing both `libtasn1` and `nettle`.  I downloaded and extracted `libtasn1-4.2-w32-bin.zip` and `nettle-2.7.1-w32-bin.zip` from ezwinports and now gnutls is detected during the configure and it says "yes" by default.

I guess you were missing the header files from these 2 libraries.

> I didn't see any mention in the `gnutls` section of the `../emacs/nt/INSTALL` readme about the prerequisites of the above-mentioned two libraries `libtasn1` and `nettle`, so my suggestion would be to include a mention, and maybe even something about checking the `config.log` if there seems to be a problem.

Will do.

> The newer version of libiconv (i.e., 1.14-3) does not use `iconv.h`, so that is why the prior attempts at building emacs failed -- i.e., `missing` the file.  Downgrading libiconv to 1.13.1-1 produces the required `iconv.h`, and that resolves the error message regarding the missing header file.
> 
> The version of `libintl` installed in MinGW is 0.18.3.2-2 -- `mingw32-libintl`, which traces to mingw32-gettext.  What version, please, should I be using (so that I can locate and downgrade if needed)?

The one you find here:

  https://sourceforge.net/projects/ezwinports/files/Dependencies/

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Keith David Bershatsky]

Thank you, Eli, for helping me track down the prior versions of `libintl` and `libiconv`.

Underneath the configure printout below is a listing of all the files that were used to create the build on WindowsXP.  Once I had a better understanding of the basics needed by MinGW and MSYS, I ended up using a manual install of the packages instead of using the package manager.  I have the entire "cheat-sheet" in a thread on emacs.stackexchange.com and I anticipate updating it from time to time as needed:  http://emacs.stackexchange.com/a/17040/2287

Configured for 'i686-pc-mingw32'.
Where should the build process find the source code?    .
What compiler should emacs be built with?               gcc -std=gnu99  -g3 -O 2 -gdwarf-2
Should Emacs use the GNU version of malloc?             no
  (The GNU allocators don't work with this system configuration.)
Should Emacs use a relocating allocator for buffers?    no
Should Emacs use mmap(2) for buffer allocation?         yes
What window system should Emacs use?                    w32
What toolkit should Emacs use?                          none
Where do we find X Windows header files?                NONE
Where do we find X Windows libraries?                   NONE
Does Emacs use -lXaw3d?                                 no
Does Emacs use -lXpm?                                   yes
Does Emacs use -ljpeg?                                  yes
Does Emacs use -ltiff?                                  yes
Does Emacs use a gif library?                           yes
Does Emacs use a png library?                           yes
Does Emacs use -lrsvg-2?                                yes
Does Emacs use cairo?                                   no
Does Emacs use imagemagick?                             no
Does Emacs support sound?                               yes
Does Emacs use -lgpm?                                   no
Does Emacs use -ldbus?                                  no
Does Emacs use -lgconf?                                 no
Does Emacs use GSettings?                               no
Does Emacs use a file notification library?             yes (w32)
Does Emacs use access control lists?                    yes
Does Emacs use -lselinux?                               no
Does Emacs use -lgnutls?                                yes
Does Emacs use -lxml2?                                  yes
Does Emacs use -lfreetype?                              no
Does Emacs use -lm17n-flt?                              no
Does Emacs use -lotf?                                   no
Does Emacs use -lxft?                                   no
Does Emacs directly use zlib?                           yes
Does Emacs use toolkit scroll bars?                     yes



EZWINPORTS

cairo-1.12.16-w32-bin.zip
gdk-pixbuf-2.30.2-w32-bin.zip
giflib-5.1.0-w32-bin.zip
glib-2.38.2-w32-bin.zip
gnutls-3.3.11-w32-bin.zip
jpeg-v9a-w32-bin.zip
libXpm-3.5.11-2-w32-bin.zip
libpng-1.6.12-w32-bin.zip
librsvg-2.40.1-2-w32-bin.zip
libtasn1-4.2-w32-bin.zip
libxml2-2.7.8-w32-bin.zip
nettle-2.7.1-w32-bin.zip
p11-kit-0.9-w32-bin.zip
pixman-0.32.4-w32-bin.zip
pkg-config-0.28-w32-bin.zip
tiff-4.0.3-w32-bin.zip
zlib-1.2.8-2-w32-bin.zip

MINGW

autoconf-10-1-mingw32-bin.tar.lzma
autoconf-10-1-mingw32-lic.tar.lzma
autoconf2.1-2.13-4-mingw32-bin.tar.lzma
autoconf2.5-2.68-1-mingw32-bin.tar.lzma
automake-4-1-mingw32-bin.tar.lzma
automake-4-1-mingw32-lic.tar.lzma
automake1.10-1.10.2-1-mingw32-bin.tar.lzma
automake1.11-1.11.1-1-mingw32-bin.tar.lzma
automake1.4-1.4p6-1-mingw32-bin.tar.lzma
automake1.5-1.5-1-mingw32-bin.tar.lzma
automake1.6-1.6.3-1-mingw32-bin.tar.lzma
automake1.7-1.7.9-1-mingw32-bin.tar.lzma
automake1.8-1.8.5-1-mingw32-bin.tar.lzma
automake1.9-1.9.6-3-mingw32-bin.tar.lzma
binutils-2.25.1-1-mingw32-bin.tar.xz
gcc-core-4.8.1-4-mingw32-bin.tar.lzma
gcc-core-4.8.1-4-mingw32-dev.tar.lzma
gcc-core-4.8.1-4-mingw32-dll.tar.lzma
gcc-core-4.8.1-4-mingw32-lic.tar.lzma
gdb-7.6.1-1-mingw32-bin.tar.lzma
gmp-5.1.2-1-mingw32-dll.tar.lzma
libcharset-1.13.1-1-mingw32-dll-1.tar.lzma
libiconv-1.13.1-1-mingw32-bin.tar.lzma
libiconv-1.13.1-1-mingw32-dev.tar.lzma
libiconv-1.13.1-1-mingw32-dll-2.tar.lzma
libiconv-1.13.1-1-mingw32-doc.tar.lzma
libiconv-1.13.1-1-mingw32-lic.tar.lzma
libintl-0.17-1-mingw32-dll-8.tar.lzma
libmpc-1.0.2-mingw32-dll-3.tar.xz
make-3.82.90-2-mingw32-cvs-20120902-bin.tar.lzma
mingwrt-3.21.1-mingw32-dev.tar.xz
mingwrt-3.21.1-mingw32-dll.tar.xz
mpfr-3.1.2-2-mingw32-dll.tar.lzma
pthreads-w32-2.9.1-1-mingw32-dll.tar.lzma
w32api-3.17-2-mingw32-dev.tar.lzma

MSYS

bash-3.1.23-1-msys-1.0.18-bin.tar.xz
bzip2-1.0.6-1-msys-1.0.17-bin.tar.lzma
coreutils-5.97-3-msys-1.0.13-bin.tar.lzma
coreutils-5.97-3-msys-1.0.13-doc.tar.lzma
coreutils-5.97-3-msys-1.0.13-ext.tar.lzma
coreutils-5.97-3-msys-1.0.13-lang.tar.lzma
coreutils-5.97-3-msys-1.0.13-lic.tar.lzma
diffutils-2.8.7.20071206cvs-3-msys-1.0.13-bin.tar.lzma
dos2unix-7.2.3-1-msys-1.0.18-bin.tar.lzma
file-5.04-1-msys-1.0.13-bin.tar.lzma
findutils-4.4.2-2-msys-1.0.13-bin.tar.lzma
gawk-3.1.7-2-msys-1.0.13-bin.tar.lzma
grep-2.5.4-2-msys-1.0.13-bin.tar.lzma
gzip-1.3.12-2-msys-1.0.13-bin.tar.lzma
less-436-2-msys-1.0.13-bin.tar.lzma
libbz2-1.0.6-1-msys-1.0.17-dll-1.tar.lzma
libcrypt-1.1_1-3-msys-1.0.13-dll-0.tar.lzma
libexpat-2.0.1-1-msys-1.0.13-dll-1.tar.lzma
libgdbm-1.8.3-3-msys-1.0.13-dll-3.tar.lzma
libiconv-1.14-1-msys-1.0.17-dll-2.tar.lzma
libintl-0.18.1.1-1-msys-1.0.17-dll-8.tar.lzma
liblzma-5.0.3-1-msys-1.0.17-dll-5.tar.lzma
libmagic-5.04-1-msys-1.0.13-dll-1.tar.lzma
libregex-1.20090805-2-msys-1.0.13-dll-1.tar.lzma
libtermcap-0.20050421_1-2-msys-1.0.13-dll-0.tar.lzma
libxml2-2.7.6-1-msys-1.0.13-dll-2.tar.lzma
m4-1.4.16-2-msys-1.0.17-bin.tar.lzma
make-3.81-3-msys-1.0.13-bin.tar.lzma
msysCORE-1.0.18-1-msys-1.0.18-bin.tar.lzma
msysCORE-1.0.18-1-msys-1.0.18-doc.tar.lzma
msysCORE-1.0.18-1-msys-1.0.18-ext.tar.lzma
msysCORE-1.0.18-1-msys-1.0.18-lic.tar.lzma
perl-5.8.8-1-msys-1.0.17-bin.tar.lzma
sed-4.2.1-2-msys-1.0.13-bin.tar.lzma
tar-1.23-1-msys-1.0.13-bin.tar.lzma
termcap-0.20050421_1-2-msys-1.0.13-bin.tar.lzma
texinfo-4.13a-2-msys-1.0.13-bin.tar.lzma
xz-5.0.3-1-msys-1.0.17-bin.tar.lzma
zlib-1.2.7-1-msys-1.0.17-dll.tar.lzma

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)

[Eli Zaretskii]

> Date:  Tue, 06 Oct 2015 11:33:35 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  21590@debbugs.gnu.org,Martin Rudalics <rudalics@gmx.at>,Glenn Morris <rgm@gnu.org>
> 
> Underneath the configure printout below is a listing of all the files that were used to create the build on WindowsXP.  Once I had a better understanding of the basics needed by MinGW and MSYS, I ended up using a manual install of the packages instead of using the package manager.  I have the entire "cheat-sheet" in a thread on emacs.stackexchange.com and I anticipate updating it from time to time as needed:  http://emacs.stackexchange.com/a/17040/2287

We maintain those cheat-sheets in nt/INSTALL.

A few comments regarding the list of packages:

> MINGW
> 
> autoconf-10-1-mingw32-bin.tar.lzma
> autoconf-10-1-mingw32-lic.tar.lzma
> autoconf2.1-2.13-4-mingw32-bin.tar.lzma
> autoconf2.5-2.68-1-mingw32-bin.tar.lzma
> automake-4-1-mingw32-bin.tar.lzma
> automake-4-1-mingw32-lic.tar.lzma
> automake1.10-1.10.2-1-mingw32-bin.tar.lzma
> automake1.11-1.11.1-1-mingw32-bin.tar.lzma
> automake1.4-1.4p6-1-mingw32-bin.tar.lzma
> automake1.5-1.5-1-mingw32-bin.tar.lzma
> automake1.6-1.6.3-1-mingw32-bin.tar.lzma
> automake1.7-1.7.9-1-mingw32-bin.tar.lzma
> automake1.8-1.8.5-1-mingw32-bin.tar.lzma
> automake1.9-1.9.6-3-mingw32-bin.tar.lzma

I don't think MinGW packages for Autoconf and Automake are needed, or
even useful.  You need MSYS packages instead, installed into the MSYS
tree.  You can find such packages on the ezwinports site (they are
also easy to build and install by yourself.)

> gdb-7.6.1-1-mingw32-bin.tar.lzma

There's a much newer (and much more functional) port of GDB 7.10 on
ezwinports.

> make-3.82.90-2-mingw32-cvs-20120902-bin.tar.lzma

Make 4.1 is available from ezwinports.  The above is not even an
official release.