bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE'


From: Eli Zaretskii
Subject: bug#21590: 25.0.50; MS-Windows; fns.c:4863:21: error: 'MD5_DIGEST_SIZE' undeclared (first use in this function)
Date: Thu, 01 Oct 2015 10:00:44 +0300

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]