* MS-Windows build using Posix configury
@ 2013-04-16 18:24 Eli Zaretskii
2013-04-16 18:40 ` Eli Zaretskii
` (8 more replies)
0 siblings, 9 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-16 18:24 UTC (permalink / raw)
To: emacs-devel
This job is finished, as far as my todo list and debugging are
concerned: Emacs and all the auxiliary programs build, get installed,
and seem to work. I performed a full bootstrap several times and also
several partial builds, including a few parallel builds. "make
install" likewise works. The only item left on my todo is to get
"make install-strip" to work; but since this doesn't work in the
current Windows build, it is not a regression and can be taken care of
later.
I would appreciate it very much if Autotools gurus here could take a
look at my tweaking of the configury; the diffs against the current
trunk are below.
Also, if people could apply the diffs and try building Emacs on their
platforms, I'd appreciate. Of special interest are the Cygwin w32
build and any Unix system. (I tested this on one GNU/Linux box, but I
have no access to other Posix systems.)
Windows users are encouraged to try this. The diffs below will create
a file nt/INSTALL.MSYS with detailed instructions for how to build
this way; please read it before you try the build. (Actually, about
85% of the job is just to set up a working MSYS installation, which
therefore takes the lion's share of the instructions.)
I will continue tracking the trunk for a while and fixing any issues I
find, and will look into merging this with the trunk in a few days, if
no major issues arise.
Thanks.
Here are the patches:
=== modified file '.bzrignore'
--- .bzrignore 2013-03-30 06:23:47 +0000
+++ .bzrignore 2013-04-06 15:42:58 +0000
@@ -126,6 +126,7 @@ lib-src/ctags
lib-src/ctags.c
lib-src/ebrowse
lib-src/emacsclient
+lib-src/emacsclient.res
lib-src/etags
lib-src/fakemail
lib-src/hexl
@@ -147,6 +148,7 @@ nextstep/Cocoa/Emacs.base/Contents/Resou
nextstep/GNUstep/Emacs.base/Resources/Emacs.desktop
nextstep/GNUstep/Emacs.base/Resources/Info-gnustep.plist
nt/config.log
+nt/emacs.res
src/_dbxinit
src/_gdbinit
src/bootstrap-emacs
@@ -163,6 +165,8 @@ src/stamp-oldxmenu
src/stamp-h.in
src/emacs.res
src/temacs
+src/temacs.map
+src/temacs.tmp
test/indent/*.new
+*
src/globals.h
=== modified file 'Makefile.in'
--- Makefile.in 2013-03-18 21:02:34 +0000
+++ Makefile.in 2013-04-14 15:57:24 +0000
@@ -93,6 +93,9 @@ version=@version@
### for, like `mips-dec-ultrix' or `sparc-sun-sunos'.
configuration=@configuration@
+### The nt/ subdirectory gets built only for MinGW
+NTDIR=@NTDIR@
+
# ==================== Where To Install Things ====================
# Location to install Emacs.app under GNUstep / Mac OS X.
@@ -254,6 +257,8 @@ INSTALL_INFO = @INSTALL_INFO@
INSTALL_STRIP =
MKDIR_P = @MKDIR_P@
LN_S = @LN_S@
+# Used in "make install". Usually, $(LN_S), but MS-Windows uses hard links.
+LN_EMACS = @LN_EMACS@
# We use gzip to compress installed .el files.
GZIP_PROG = @GZIP_PROG@
@@ -271,23 +276,23 @@ EMACS = ${EMACS_NAME}${EXEEXT}
EMACSFULL = `echo emacs-${version} | sed '$(TRANSFORM)'`${EXEEXT}
# Subdirectories to make recursively.
-SUBDIR = lib lib-src src lisp leim
+SUBDIR = $(NTDIR) lib lib-src src lisp leim
# The subdir makefiles created by config.status.
SUBDIR_MAKEFILES_IN = @SUBDIR_MAKEFILES_IN@
SUBDIR_MAKEFILES = `echo $(SUBDIR_MAKEFILES_IN:.in=) | sed 's|$(srcdir)/||g'`
-# Subdirectories to install, and where they'll go.
-# lib-src's makefile knows how to install it, so we don't do that here.
-# Directories that cannot simply be copied, eg info,
-# are treated separately.
-# quail appears twice because in out-of-tree builds, it exists twice.
+# Subdirectories to install, and where they'll go. lib-src's and nt's
+# makefiles know how to install them, so we don't do that here.
+# Directories that cannot simply be copied, eg info, are treated
+# separately. quail appears twice because in out-of-tree builds, it
+# exists twice.
COPYDIR = ${srcdir}/etc ${srcdir}/lisp ${srcdir}/leim/ja-dic ${srcdir}/leim/quail leim/quail
COPYDESTS = $(DESTDIR)${etcdir} $(DESTDIR)${lispdir} $(DESTDIR)${leimdir}/ja-dic $(DESTDIR)${leimdir}/quail $(DESTDIR)${leimdir}/quail
all: ${SUBDIR}
-.PHONY: all ${SUBDIR} blessmail epaths-force FRC
+.PHONY: all ${SUBDIR} blessmail epaths-force epaths-force-w32 FRC
removenullpaths=sed -e 's/^://g' -e 's/:$$//g' -e 's/::/:/g'
@@ -314,7 +319,20 @@ epaths-force: FRC
-e 's;\(#.*PATH_DOC\).*$$;\1 "${docdir}";') && \
${srcdir}/build-aux/move-if-change epaths.h.$$$$ src/epaths.h
-lib-src src: lib
+# Convert MSYS-style /x/foo file name into x:/foo that Windows can grok.
+msys_to_w32=sed -e 's,^/\([A-Za-z]\)/,\1:/,'
+
+# The w32 build needs a slightly different editing, and it uses
+# nt/epaths.nt as the template.
+epaths-force-w32: FRC
+ @(w32srcdir=`echo "${srcdir}" | ${msys_to_w32}` ; \
+ sed < ${srcdir}/nt/epaths.nt > epaths.h.$$$$ \
+ -e '/^.*#/s/@VER@/${version}/g' \
+ -e '/^.*#/s/@CFG@/${configuration}/g' \
+ -e "/^.*#/s|@SRC@|$${w32srcdir}|g") && \
+ ${srcdir}/build-aux/move-if-change epaths.h.$$$$ src/epaths.h
+
+lib-src src: $(NTDIR) lib
src: lib-src FRC
@@ -323,7 +341,7 @@ src: lib-src FRC
lisp leim: src
# These targets should be "${SUBDIR} without `src'".
-lib lib-src lisp leim: Makefile FRC
+lib lib-src lisp leim nt: Makefile FRC
cd $@ && $(MAKE) all $(MFLAGS) \
CC='${CC}' CFLAGS='${CFLAGS}' CPPFLAGS='${CPPFLAGS}' \
LDFLAGS='${LDFLAGS}' MAKE='${MAKE}'
@@ -455,13 +473,20 @@ install-arch-dep: src install-arch-indep
chmod 1755 $(DESTDIR)${bindir}/$(EMACSFULL) || true; \
if test "x${NO_BIN_LINK}" = x; then \
rm -f $(DESTDIR)${bindir}/$(EMACS) ; \
- cd $(DESTDIR)${bindir} && $(LN_S) $(EMACSFULL) $(EMACS); \
+ cd $(DESTDIR)${bindir} && $(LN_EMACS) $(EMACSFULL) $(EMACS); \
fi; \
else \
subdir=${ns_appresdir}/site-lisp; \
${write_subdir} || exit 1; \
rm -rf ${ns_appresdir}/share; \
fi
+ if test "x$(NTDIR)" != "x"; then \
+ cd $(NTDIR) && \
+ $(MAKE) install $(MFLAGS) prefix=${prefix} \
+ exec_prefix=${exec_prefix} bindir=${bindir} \
+ libexecdir=${libexecdir} archlibdir=${archlibdir} \
+ INSTALL_STRIP=${INSTALL_STRIP}; \
+ fi
## In the share directory, we are deleting:
## applications (with emacs.desktop, also found in etc/)
@@ -692,6 +717,13 @@ uninstall:
$(MAKE) $(MFLAGS) uninstall \
prefix=${prefix} exec_prefix=${exec_prefix} \
bindir=${bindir} libexecdir=${libexecdir} archlibdir=${archlibdir}
+
+ if test "x$(NTDIR)" != "x"; then \
+ cd $(NTDIR) && \
+ $(MAKE) $(MFLAGS) uninstall \
+ prefix=${prefix} exec_prefix=${exec_prefix} \
+ bindir=${bindir} libexecdir=${libexecdir} archlibdir=${archlibdir}; \
+ fi
-unset CDPATH; \
for dir in $(DESTDIR)${lispdir} $(DESTDIR)${etcdir} ; do \
if [ -d $${dir} ]; then \
@@ -753,6 +785,7 @@ mostlyclean: FRC
(cd lwlib; $(MAKE) $(MFLAGS) mostlyclean)
(cd lib; $(MAKE) $(MFLAGS) mostlyclean)
(cd lib-src; $(MAKE) $(MFLAGS) mostlyclean)
+ (cd nt; $(MAKE) $(MFLAGS) mostlyclean)
-(cd doc/emacs && $(MAKE) $(MFLAGS) mostlyclean)
-(cd doc/misc && $(MAKE) $(MFLAGS) mostlyclean)
-(cd doc/lispref && $(MAKE) $(MFLAGS) mostlyclean)
@@ -774,6 +807,7 @@ clean: FRC
(cd lwlib; $(MAKE) $(MFLAGS) clean)
(cd lib; $(MAKE) $(MFLAGS) clean)
(cd lib-src; $(MAKE) $(MFLAGS) clean)
+ (cd nt; $(MAKE) $(MFLAGS) clean)
-(cd doc/emacs && $(MAKE) $(MFLAGS) clean)
-(cd doc/misc && $(MAKE) $(MFLAGS) clean)
-(cd doc/lispref && $(MAKE) $(MFLAGS) clean)
@@ -800,6 +834,7 @@ distclean: FRC
(cd lwlib; $(MAKE) $(MFLAGS) distclean)
(cd lib; $(MAKE) $(MFLAGS) distclean)
(cd lib-src; $(MAKE) $(MFLAGS) distclean)
+ (cd nt; $(MAKE) $(MFLAGS) distclean)
(cd doc/emacs && $(MAKE) $(MFLAGS) distclean)
(cd doc/misc && $(MAKE) $(MFLAGS) distclean)
(cd doc/lispref && $(MAKE) $(MFLAGS) distclean)
@@ -818,6 +853,7 @@ bootstrap-clean: FRC
(cd lwlib; $(MAKE) $(MFLAGS) maintainer-clean)
(cd lib; $(MAKE) $(MFLAGS) maintainer-clean)
(cd lib-src; $(MAKE) $(MFLAGS) maintainer-clean)
+ (cd nt; $(MAKE) $(MFLAGS) maintainer-clean)
-(cd doc/emacs && $(MAKE) $(MFLAGS) maintainer-clean)
-(cd doc/misc && $(MAKE) $(MFLAGS) maintainer-clean)
-(cd doc/lispref && $(MAKE) $(MFLAGS) maintainer-clean)
=== modified file 'configure.ac'
--- configure.ac 2013-04-12 13:00:57 +0000
+++ configure.ac 2013-04-14 17:21:04 +0000
@@ -192,7 +192,7 @@ OPTION_DEFAULT_ON([toolkit-scroll-bars],
OPTION_DEFAULT_ON([xaw3d],[don't use Xaw3d])
OPTION_DEFAULT_ON([xim],[don't use X11 XIM])
OPTION_DEFAULT_OFF([ns],[use NeXTstep (Cocoa or GNUstep) windowing system])
-OPTION_DEFAULT_OFF([w32], [use native MS Windows GUI])
+OPTION_DEFAULT_OFF([w32], [use native MS Windows GUI in a Cygwin build])
OPTION_DEFAULT_ON([gpm],[don't use -lgpm for mouse support on a GNU/Linux console])
OPTION_DEFAULT_ON([dbus],[don't compile with D-Bus support])
@@ -377,7 +377,7 @@ AC_ARG_ENABLE(gtk-deprecation-warnings,
## Make sure CDPATH doesn't affect cd (in case PWD is relative).
unset CDPATH
case "${srcdir}" in
- /* ) ;;
+ [[\\/]]* | ?:[[\\/]]*) ;;
. )
## We may be able to use the $PWD environment variable to make this
## absolute. But sometimes PWD is inaccurate.
@@ -550,6 +550,11 @@ case "${canonical}" in
i[3456]86-*-* )
case "${canonical}" in
*-darwin* ) opsys=darwin ;;
+ *-mingw32 )
+ opsys=mingw32
+ # MinGW overrides and adds some system headers in nt/inc.
+ GCC_TEST_OPTIONS="-I $srcdir/nt/inc"
+ ;;
*-sysv4.2uw* ) opsys=unixware ;;
*-sysv5uw* ) opsys=unixware ;;
*-sysv5OpenUNIX* ) opsys=unixware ;;
@@ -598,6 +603,11 @@ else
test "x$NON_GCC_TEST_OPTIONS" != x && CC="$CC $NON_GCC_TEST_OPTIONS"
fi
+dnl This is used in lib/Makefile.am to use nt/gnulib.mk, the
+dnl alternative to lib/gnulib.mk, so as to avoid generating header files
+dnl that clash with MinGW.
+AM_CONDITIONAL([BUILDING_FOR_WINDOWSNT], [test "x$opsys" = "xmingw32"])
+
# Avoid gnulib's tests for HAVE_WORKING_O_NOATIME and HAVE_WORKING_O_NOFOLLOW,
# as we don't use them.
AC_DEFUN([gl_FCNTL_O_FLAGS])
@@ -633,6 +643,9 @@ if test "$ac_test_CFLAGS" != set; then
else
CFLAGS=$emacs_save_CFLAGS
fi
+ if test $opsys = mingw32; then
+ CFLAGS="$CFLAGS -gdwarf-2"
+ fi
fi
fi
@@ -801,6 +814,12 @@ dnl AC_PROG_RANLIB
dnl fi
AC_PROG_LN_S
+LN_EMACS="\$(LN_S)"
+if test "$opsys" = "mingw32"; then
+ LN_EMACS="ln"
+fi
+AC_SUBST(LN_EMACS)
+
AC_PATH_PROG(INSTALL_INFO, install-info, :,
$PATH$PATH_SEPARATOR/usr/sbin$PATH_SEPARATOR/sbin)
dnl Don't use GZIP, which is used by gzip for additional parameters.
@@ -906,7 +925,6 @@ AC_SUBST(CANNOT_DUMP)
UNEXEC_OBJ=unexelf.o
case "$opsys" in
# MSDOS uses unexcoff.o
- # MSWindows uses unexw32.o
aix4-2)
UNEXEC_OBJ=unexaix.o
;;
@@ -919,6 +937,9 @@ case "$opsys" in
hpux10-20 | hpux11)
UNEXEC_OBJ=unexhp9k800.o
;;
+ mingw32)
+ UNEXEC_OBJ=unexw32.o
+ ;;
sol2-10)
# Use the Solaris dldump() function, called from unexsol.c, to dump
# emacs, instead of the generic ELF dump code found in unexelf.c.
@@ -1013,6 +1034,7 @@ C_SWITCH_SYSTEM=
## additional optimization. --nils@exp-math.uni-essen.de
test "$opsys" = "aix4.2" && test "x$GCC" != "xyes" && \
C_SWITCH_SYSTEM="-ma -qmaxmem=4000"
+test "$opsys" = "mingw32" && C_SWITCH_SYSTEM="-mtune=pentium4"
## gnu-linux might need -D_BSD_SOURCE on old libc5 systems.
## It is redundant in glibc2, since we define _GNU_SOURCE.
AC_SUBST(C_SWITCH_SYSTEM)
@@ -1032,8 +1054,8 @@ case "$opsys" in
## Motif needs -lgen.
unixware) LIBS_SYSTEM="-lsocket -lnsl -lelf -lgen" ;;
esac
-AC_SUBST(LIBS_SYSTEM)
+AC_SUBST(LIBS_SYSTEM)
### Make sure subsequent tests use flags consistent with the build flags.
@@ -1071,6 +1093,10 @@ case $opsys in
;;
hpux10-20 | hpux11 )
;;
+ mingw32 )
+ LIB_MATH=
+ SYSTEM_TYPE=windows-nt
+ ;;
dnl NB this may be adjusted below.
netbsd | openbsd )
SYSTEM_TYPE=berkeley-unix
@@ -1146,11 +1172,15 @@ AC_DEFUN([PKG_CHECK_MODULES], [
fi
])
-
if test "${with_sound}" != "no"; then
- # Sound support for GNU/Linux and the free BSDs.
- AC_CHECK_HEADERS(machine/soundcard.h sys/soundcard.h soundcard.h,
- have_sound_header=yes)
+ # Sound support for GNU/Linux, the free BSDs, and MinGW.
+ AC_CHECK_HEADERS(machine/soundcard.h sys/soundcard.h soundcard.h mmsystem.h,
+ have_sound_header=yes, [], [
+ #ifdef __MINGW32__
+ #define WIN32_LEAN_AND_MEAN
+ #include <windows.h>
+ #endif
+ ])
# Emulation library used on NetBSD.
AC_CHECK_LIB(ossaudio, _oss_ioctl, LIBSOUND=-lossaudio, LIBSOUND=)
AC_SUBST(LIBSOUND)
@@ -1193,6 +1223,9 @@ if test "${with_sound}" != "no"; then
gnu-linux|freebsd|netbsd)
AC_DEFINE(HAVE_SOUND, 1, [Define to 1 if you have sound support.])
;;
+ mingw32)
+ AC_DEFINE(HAVE_SOUND, 1, [Define to 1 if you have sound support.])
+ ;;
esac
fi
@@ -1512,31 +1545,93 @@ AC_SUBST(NS_OBJC_OBJ)
HAVE_W32=no
W32_OBJ=
W32_LIBS=
-W32_RES=
+EMACSRES=
+CLIENTRES=
+CLIENTW=
W32_RES_LINK=
+EMACS_MANIFEST=
if test "${with_w32}" != no; then
if test "${opsys}" != "cygwin"; then
- AC_MSG_ERROR([Using w32 with an autotools build is only supported for Cygwin.])
+ if test "${opsys}" != "mingw32"; then
+ AC_MSG_ERROR([Using w32 with an autotools build is only supported for Cygwin and MinGW32.])
+ fi
fi
AC_CHECK_HEADER([windows.h], [HAVE_W32=yes],
[AC_MSG_ERROR([`--with-w32' was specified, but windows.h
cannot be found.])])
+fi
+if test "${opsys}" = "mingw32"; then
+ AC_CHECK_HEADER([windows.h], [HAVE_W32=yes],
+ [AC_MSG_ERROR([The windows.h header file is required,
+ but cannot be found.])])
+ AC_MSG_CHECKING([whether Windows API headers are recent enough])
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
+ #include <windows.h>
+ #include <usp10.h>]],
+ [[void test(PIMAGE_NT_HEADERS pHeader)
+ {PIMAGE_SECTION_HEADER pSection = IMAGE_FIRST_SECTION(pHeader);}]])],
+ emacs_cv_w32api=yes, emacs_cv_w32api=no)
+ AC_MSG_RESULT($emacs_cv_w32api)
+ if test "${emacs_cv_w32api}" = "no"; then
+ AC_MSG_ERROR([the Windows API headers are too old to support this build.])
+ fi
+fi
+
+FIRSTFILE_OBJ=
+NTDIR=
+LIBS_ECLIENT=
+LIB_WSOCK32=
+NTLIB=
+CM_OBJ="cm.o"
+XARGS_LIMIT=
+if test "${HAVE_W32}" = "yes"; then
AC_DEFINE(HAVE_NTGUI, 1, [Define to use native MS Windows GUI.])
AC_CHECK_TOOL(WINDRES, [windres],
[AC_MSG_ERROR([No resource compiler found.])])
W32_OBJ="w32fns.o w32menu.o w32reg.o w32font.o w32term.o"
W32_OBJ="$W32_OBJ w32xfns.o w32select.o w32uniscribe.o"
- W32_LIBS="$W32_LIBS -lkernel32 -luser32 -lgdi32 -lole32 -lcomdlg32"
- W32_LIBS="$W32_LIBS -lusp10 -lcomctl32 -lwinspool"
- W32_RES="emacs.res"
- # Tell the linker that emacs.res is an object (which we compile from
- # the rc file), not a linker script.
- W32_RES_LINK="-Wl,emacs.res"
+ EMACSRES="emacs.res"
+ case "$canonical" in
+ x86_64-*-*) EMACS_MANIFEST="emacs-x64.manifest" ;;
+ *) EMACS_MANIFEST="emacs-x86.manifest" ;;
+ esac
+ if test "${opsys}" = "cygwin"; then
+ W32_LIBS="$W32_LIBS -lkernel32 -luser32 -lgdi32 -lole32 -lcomdlg32"
+ W32_LIBS="$W32_LIBS -lusp10 -lcomctl32 -lwinspool"
+ # Tell the linker that emacs.res is an object (which we compile from
+ # the rc file), not a linker script.
+ W32_RES_LINK="-Wl,emacs.res"
+ else
+ W32_OBJ="$W32_OBJ w32.o w32console.o w32heap.o w32inevt.o w32proc.o"
+ W32_OBJ="$W32_OBJ w32notify.o"
+ W32_LIBS="$W32_LIBS -lwinmm -lgdi32 -lcomdlg32"
+ W32_LIBS="$W32_LIBS -lmpr -lwinspool -lole32 -lcomctl32 -lusp10"
+ W32_RES_LINK="\$(EMACSRES)"
+ CLIENTRES="emacsclient.res"
+ CLIENTW="emacsclientw\$(EXEEXT)"
+ FIRSTFILE_OBJ=firstfile.o
+ NTDIR=nt
+ CM_OBJ=
+ LIBS_ECLIENT="-lcomctl32"
+ LIB_WSOCK32="-lwsock32"
+ NTLIB="ntlib.$ac_objext"
+ XARGS_LIMIT="-s 10000"
+ fi
fi
AC_SUBST(W32_OBJ)
AC_SUBST(W32_LIBS)
-AC_SUBST(W32_RES)
+AC_SUBST(EMACSRES)
+AC_SUBST(EMACS_MANIFEST)
+AC_SUBST(CLIENTRES)
+AC_SUBST(CLIENTW)
AC_SUBST(W32_RES_LINK)
+AC_SUBST(FIRSTFILE_OBJ)
+AC_SUBST(NTDIR)
+AC_SUBST(CM_OBJ)
+AC_SUBST(LIBS_ECLIENT)
+AC_SUBST(LIB_WSOCK32)
+AC_SUBST(NTLIB)
+AC_SUBST(XARGS_LIMIT)
if test "${HAVE_W32}" = "yes"; then
window_system=w32
@@ -1861,7 +1956,7 @@ fi
### Use -lrsvg-2 if available, unless `--with-rsvg=no' is specified.
HAVE_RSVG=no
-if test "${HAVE_X11}" = "yes" || test "${HAVE_NS}" = "yes"; then
+if test "${HAVE_X11}" = "yes" || test "${HAVE_NS}" = "yes" || test "${opsys}" = "mingw32"; then
if test "${with_rsvg}" != "no"; then
RSVG_REQUIRED=2.11.0
RSVG_MODULE="librsvg-2.0 >= $RSVG_REQUIRED"
@@ -1904,43 +1999,45 @@ HAVE_GTK=no
GTK_OBJ=
check_gtk2=no
gtk3_pkg_errors=
-if test "${with_gtk3}" = "yes" || test "${with_gtk}" = "yes" || test "$USE_X_TOOLKIT" = "maybe"; then
- GLIB_REQUIRED=2.28
- GTK_REQUIRED=3.0
- GTK_MODULES="gtk+-3.0 >= $GTK_REQUIRED glib-2.0 >= $GLIB_REQUIRED"
-
- dnl Checks for libraries.
- PKG_CHECK_MODULES(GTK, $GTK_MODULES, pkg_check_gtk=yes, pkg_check_gtk=no)
- if test "$pkg_check_gtk" = "no" && test "$with_gtk3" = "yes"; then
- AC_MSG_ERROR($GTK_PKG_ERRORS)
- fi
- if test "$pkg_check_gtk" = "yes"; then
- AC_DEFINE(HAVE_GTK3, 1, [Define to 1 if using GTK 3 or later.])
- GTK_OBJ=emacsgtkfixed.o
- term_header=gtkutil.h
- USE_GTK_TOOLKIT="GTK3"
- if test "x$ac_enable_gtk_deprecation_warnings" = x; then
- GTK_CFLAGS="$GTK_CFLAGS -DGDK_DISABLE_DEPRECATION_WARNINGS"
- fi
- else
- check_gtk2=yes
- gtk3_pkg_errors="$GTK_PKG_ERRORS "
+if test "${opsys}" != "mingw32"; then
+ if test "${with_gtk3}" = "yes" || test "${with_gtk}" = "yes" || test "$USE_X_TOOLKIT" = "maybe"; then
+ GLIB_REQUIRED=2.28
+ GTK_REQUIRED=3.0
+ GTK_MODULES="gtk+-3.0 >= $GTK_REQUIRED glib-2.0 >= $GLIB_REQUIRED"
+
+ dnl Checks for libraries.
+ PKG_CHECK_MODULES(GTK, $GTK_MODULES, pkg_check_gtk=yes, pkg_check_gtk=no)
+ if test "$pkg_check_gtk" = "no" && test "$with_gtk3" = "yes"; then
+ AC_MSG_ERROR($GTK_PKG_ERRORS)
+ fi
+ if test "$pkg_check_gtk" = "yes"; then
+ AC_DEFINE(HAVE_GTK3, 1, [Define to 1 if using GTK 3 or later.])
+ GTK_OBJ=emacsgtkfixed.o
+ term_header=gtkutil.h
+ USE_GTK_TOOLKIT="GTK3"
+ if test "x$ac_enable_gtk_deprecation_warnings" = x; then
+ GTK_CFLAGS="$GTK_CFLAGS -DGDK_DISABLE_DEPRECATION_WARNINGS"
+ fi
+ else
+ check_gtk2=yes
+ gtk3_pkg_errors="$GTK_PKG_ERRORS "
+ fi
fi
-fi
-
-if test "${with_gtk2}" = "yes" || test "$check_gtk2" = "yes"; then
- GLIB_REQUIRED=2.10
- GTK_REQUIRED=2.10
- GTK_MODULES="gtk+-2.0 >= $GTK_REQUIRED glib-2.0 >= $GLIB_REQUIRED"
- dnl Checks for libraries.
- PKG_CHECK_MODULES(GTK, $GTK_MODULES, pkg_check_gtk=yes, pkg_check_gtk=no)
- if test "$pkg_check_gtk" = "no" &&
- { test "$with_gtk" = yes || test "$with_gtk2" = "yes"; }
- then
- AC_MSG_ERROR($gtk3_pkg_errors$GTK_PKG_ERRORS)
+ if test "${with_gtk2}" = "yes" || test "$check_gtk2" = "yes"; then
+ GLIB_REQUIRED=2.10
+ GTK_REQUIRED=2.10
+ GTK_MODULES="gtk+-2.0 >= $GTK_REQUIRED glib-2.0 >= $GLIB_REQUIRED"
+
+ dnl Checks for libraries.
+ PKG_CHECK_MODULES(GTK, $GTK_MODULES, pkg_check_gtk=yes, pkg_check_gtk=no)
+ if test "$pkg_check_gtk" = "no" &&
+ { test "$with_gtk" = yes || test "$with_gtk2" = "yes"; }
+ then
+ AC_MSG_ERROR($gtk3_pkg_errors$GTK_PKG_ERRORS)
+ fi
+ test "$pkg_check_gtk" = "yes" && USE_GTK_TOOLKIT="GTK2"
fi
- test "$pkg_check_gtk" = "yes" && USE_GTK_TOOLKIT="GTK2"
fi
if test x"$pkg_check_gtk" = xyes; then
@@ -2110,6 +2207,8 @@ if test "${with_gnutls}" = "yes" ; then
AC_DEFINE(HAVE_GNUTLS, 1, [Define if using GnuTLS.])
fi
+ OLD_CFLAGS=$CFLAGS
+ OLD_LIBS=$LIBS
CFLAGS="$CFLAGS $LIBGNUTLS_CFLAGS"
LIBS="$LIBGNUTLS_LIBS $LIBS"
AC_CHECK_FUNCS(gnutls_certificate_set_verify_function, HAVE_GNUTLS_CALLBACK_CERTIFICATE_VERIFY=yes)
@@ -2117,6 +2216,13 @@ if test "${with_gnutls}" = "yes" ; then
if test "${HAVE_GNUTLS_CALLBACK_CERTIFICATE_VERIFY}" = "yes"; then
AC_DEFINE(HAVE_GNUTLS_CALLBACK_CERTIFICATE_VERIFY, 1, [Define if using GnuTLS certificate verification callbacks.])
fi
+
+ # Windows loads GnuTLS dynamically
+ if test "${opsys}" = "mingw32"; then
+ CFLAGS=$OLD_CFLAGS
+ LIBS=$OLD_LIBS
+ LIBGNUTLS_LIBS=
+ fi
fi
AC_SUBST(LIBGNUTLS_LIBS)
@@ -2249,6 +2355,9 @@ case $opsys in
hpux* | aix4-2 )
test "X$ac_cv_lib_Xmu_XmuConvertStandardSelection" != "Xyes" && LIBXMU=
;;
+ mingw32 )
+ LIBXMU=
+ ;;
esac
AC_SUBST(LIBXMU)
@@ -2507,10 +2616,10 @@ AC_SUBST(M17N_FLT_CFLAGS)
AC_SUBST(M17N_FLT_LIBS)
### Use -lXpm if available, unless `--with-xpm=no'.
+### mingw32 doesn't use -lXpm, since it loads the library dynamically.
HAVE_XPM=no
LIBXPM=
-
-if test "${HAVE_W32}" = "yes"; then
+if test "${HAVE_W32}" = "yes" && test "${opsys}" = "cygwin"; then
if test "${with_xpm}" != "no"; then
SAVE_CPPFLAGS="$CPPFLAGS"
SAVE_LDFLAGS="$LDFLAGS"
@@ -2571,19 +2680,29 @@ no_return_alloc_pixels
fi
fi
+if test "${opsys}" = "mingw32"; then
+ if test "${with_xpm}" != "no"; then
+ AC_CHECK_HEADER(X11/xpm.h, HAVE_XPM=yes, HAVE_XPM=no, [
+#define FOR_MSW 1])
+ fi
+
+ if test "${HAVE_XPM}" = "yes"; then
+ AC_DEFINE(HAVE_XPM, 1, [Define to 1 if you have the Xpm library (-lXpm).])
+ fi
+fi
+
AC_SUBST(LIBXPM)
### Use -ljpeg if available, unless `--with-jpeg=no'.
+### mingw32 doesn't use -ljpeg, since it loads the library dynamically.
HAVE_JPEG=no
LIBJPEG=
-if test "${HAVE_X11}" = "yes" || test "${HAVE_W32}" = "yes"; then
+if test "${opsys}" = "mingw32"; then
if test "${with_jpeg}" != "no"; then
dnl Checking for jpeglib.h can lose because of a redefinition of
- dnl HAVE_STDLIB_H.
- AC_CHECK_HEADER(jerror.h,
- [AC_CHECK_LIB(jpeg, jpeg_destroy_compress, HAVE_JPEG=yes)])
+ dnl HAVE_STDLIB_H.
+ AC_CHECK_HEADER(jerror.h, HAVE_JPEG=yes, HAVE_JPEG=no)
fi
-
AH_TEMPLATE(HAVE_JPEG, [Define to 1 if you have the jpeg library (-ljpeg).])dnl
if test "${HAVE_JPEG}" = "yes"; then
AC_DEFINE(HAVE_JPEG)
@@ -2595,6 +2714,25 @@ if test "${HAVE_X11}" = "yes" || test "$
[AC_MSG_WARN([libjpeg found, but not version 6b or later])
HAVE_JPEG=no])
fi
+elif test "${HAVE_X11}" = "yes" || test "${HAVE_W32}" = "yes"; then
+ if test "${with_jpeg}" != "no"; then
+ dnl Checking for jpeglib.h can lose because of a redefinition of
+ dnl HAVE_STDLIB_H.
+ AC_CHECK_HEADER(jerror.h,
+ [AC_CHECK_LIB(jpeg, jpeg_destroy_compress, HAVE_JPEG=yes)])
+ fi
+
+ AH_TEMPLATE(HAVE_JPEG, [Define to 1 if you have the jpeg library (-ljpeg).])dnl
+ if test "${HAVE_JPEG}" = "yes"; then
+ AC_DEFINE(HAVE_JPEG)
+ AC_EGREP_CPP([version= *(6[2-9]|[7-9][0-9])],
+ [#include <jpeglib.h>
+ version=JPEG_LIB_VERSION
+],
+ [AC_DEFINE(HAVE_JPEG)],
+ [AC_MSG_WARN([libjpeg found, but not version 6b or later])
+ HAVE_JPEG=no])
+ fi
if test "${HAVE_JPEG}" = "yes"; then
LIBJPEG=-ljpeg
fi
@@ -2602,9 +2740,30 @@ fi
AC_SUBST(LIBJPEG)
### Use -lpng if available, unless `--with-png=no'.
+### mingw32 doesn't use -lpng, since it loads the library dynamically.
HAVE_PNG=no
LIBPNG=
-if test "${HAVE_X11}" = "yes" || test "${HAVE_W32}" = "yes"; then
+if test "${opsys}" = "mingw32"; then
+ if test "${with_png}" != "no"; then
+ AC_CHECK_HEADER(png.h, HAVE_PNG=yes, HAVE_PNG=no)
+ fi
+ if test "${HAVE_PNG}" = "yes"; then
+ AC_DEFINE(HAVE_PNG, 1, [Define to 1 if you have the png library (-lpng).])
+
+ AC_CHECK_DECL(png_longjmp,
+ [],
+ [AC_DEFINE(PNG_DEPSTRUCT, [],
+ [Define to empty to suppress deprecation warnings when building
+ with --enable-gcc-warnings and with libpng versions before 1.5,
+ which lack png_longjmp.])],
+ [[#ifdef HAVE_LIBPNG_PNG_H
+ # include <libpng/png.h>
+ #else
+ # include <png.h>
+ #endif
+ ]])
+ fi
+elif test "${HAVE_X11}" = "yes" || test "${HAVE_W32}" = "yes"; then
if test "${with_png}" != "no"; then
# Debian unstable as of July 2003 has multiple libpngs, and puts png.h
# in /usr/include/libpng.
@@ -2635,9 +2794,17 @@ fi
AC_SUBST(LIBPNG)
### Use -ltiff if available, unless `--with-tiff=no'.
+### mingw32 doesn't use -ltiff, since it loads the library dynamically.
HAVE_TIFF=no
LIBTIFF=
-if test "${HAVE_X11}" = "yes" || test "${HAVE_W32}" = "yes"; then
+if test "${opsys}" = "mingw32"; then
+ if test "${with_tiff}" != "no"; then
+ AC_CHECK_HEADER(tiffio.h, HAVE_TIFF=yes, HAVE_TIFF=no)
+ fi
+ if test "${HAVE_TIFF}" = "yes"; then
+ AC_DEFINE(HAVE_TIFF, 1, [Define to 1 if you have the tiff library (-ltiff).])
+ fi
+elif test "${HAVE_X11}" = "yes" || test "${HAVE_W32}" = "yes"; then
if test "${with_tiff}" != "no"; then
AC_CHECK_HEADER(tiffio.h,
[tifflibs="-lz -lm"
@@ -2655,9 +2822,17 @@ fi
AC_SUBST(LIBTIFF)
### Use -lgif or -lungif if available, unless `--with-gif=no'.
+### mingw32 doesn't use -lgif/-lungif, since it loads the library dynamically.
HAVE_GIF=no
LIBGIF=
-if test "${HAVE_X11}" = "yes" && test "${with_gif}" != "no" \
+if test "${opsys}" = "mingw32"; then
+ if test "${with_gif}" != "no"; then
+ AC_CHECK_HEADER(gif_lib.h, HAVE_GIF=yes, HAVE_GIF=no)
+ fi
+ if test "${HAVE_GIF}" = "yes"; then
+ AC_DEFINE(HAVE_GIF, 1, [Define to 1 if you have a gif (or ungif) library.])
+ fi
+elif test "${HAVE_X11}" = "yes" && test "${with_gif}" != "no" \
|| test "${HAVE_W32}" = "yes"; then
AC_CHECK_HEADER(gif_lib.h,
# EGifPutExtensionLast only exists from version libungif-4.1.0b1.
@@ -2763,13 +2938,18 @@ fi
AC_SUBST(LIBXSM)
### Use libxml (-lxml2) if available
+### mingw32 doesn't use -lxml2, since it loads the library dynamically.
HAVE_LIBXML2=no
if test "${with_xml2}" != "no"; then
### I'm not sure what the version number should be, so I just guessed.
PKG_CHECK_MODULES(LIBXML2, libxml-2.0 > 2.6.17, HAVE_LIBXML2=yes, HAVE_LIBXML2=no)
if test "${HAVE_LIBXML2}" = "yes"; then
- LIBS="$LIBXML2_LIBS $LIBS"
- AC_CHECK_LIB(xml2, htmlReadMemory, HAVE_LIBXML2=yes, HAVE_LIBXML2=no)
+ if test "${opsys}" != "mingw32"; then
+ LIBS="$LIBXML2_LIBS $LIBS"
+ AC_CHECK_LIB(xml2, htmlReadMemory, HAVE_LIBXML2=yes, HAVE_LIBXML2=no)
+ else
+ LIBXML2_LIBS=""
+ fi
if test "${HAVE_LIBXML2}" = "yes"; then
AC_DEFINE(HAVE_LIBXML2, 1, [Define to 1 if you have the libxml library (-lxml2).])
else
@@ -2782,6 +2962,10 @@ AC_SUBST(LIBXML2_LIBS)
AC_SUBST(LIBXML2_CFLAGS)
# If netdb.h doesn't declare h_errno, we must declare it by hand.
+# On MinGW, that is provided by nt/inc/sys/socket.h and w32.c.
+if test "${opsys}" = "mingw32"; then
+ emacs_cv_netdb_declares_h_errno=yes
+fi
AC_CACHE_CHECK(whether netdb declares h_errno,
emacs_cv_netdb_declares_h_errno,
[AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <netdb.h>]],
@@ -2792,8 +2976,10 @@ if test $emacs_cv_netdb_declares_h_errno
fi
# sqrt and other floating-point functions such as fmod and frexp
-# are found in -lm on most systems.
-AC_CHECK_LIB(m, sqrt)
+# are found in -lm on most systems, but mingw32 doesn't use -lm.
+if test "${opsys}" != "mingw32"; then
+ AC_CHECK_LIB(m, sqrt)
+fi
# Check for mail-locking functions in a "mail" library. Probably this should
# have the same check as for liblockfile below.
@@ -2857,6 +3043,9 @@ case "$opsys" in
test $ac_cv_header_maillock_h = yes && mail_lock=no
fi
;;
+
+ mingw32)
+ mail_lock="none-needed" ;;
esac
BLESSMAIL_TARGET=
@@ -2865,6 +3054,8 @@ case "$mail_lock" in
lockf) AC_DEFINE(MAIL_USE_LOCKF, 1, [Define if the mailer uses lockf to interlock the mail spool.]) ;;
+ none-needed) ;;
+
*) BLESSMAIL_TARGET="need-blessmail" ;;
esac
AC_SUBST(BLESSMAIL_TARGET)
@@ -2936,25 +3127,29 @@ AC_DEFUN([tputs_link_source], [
return 0;
}]])
])
-# Maybe curses should be tried earlier?
-# See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9736#35
-for tputs_library in '' tinfo ncurses terminfo termcap curses; do
- OLIBS=$LIBS
- if test -z "$tputs_library"; then
- LIBS_TERMCAP=
- msg='none required'
- else
- LIBS_TERMCAP=-l$tputs_library
- msg=$LIBS_TERMCAP
- LIBS="$LIBS_TERMCAP $LIBS"
- fi
- AC_RUN_IFELSE([tputs_link_source], [], [msg=no],
- [AC_LINK_IFELSE([tputs_link_source], [], [msg=no])])
- LIBS=$OLIBS
- if test "X$msg" != Xno; then
- break
- fi
-done
+if test "${opsys}" = "mingw32"; then
+ msg='none required'
+else
+ # Maybe curses should be tried earlier?
+ # See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9736#35
+ for tputs_library in '' tinfo ncurses terminfo termcap curses; do
+ OLIBS=$LIBS
+ if test -z "$tputs_library"; then
+ LIBS_TERMCAP=
+ msg='none required'
+ else
+ LIBS_TERMCAP=-l$tputs_library
+ msg=$LIBS_TERMCAP
+ LIBS="$LIBS_TERMCAP $LIBS"
+ fi
+ AC_RUN_IFELSE([tputs_link_source], [], [msg=no],
+ [AC_LINK_IFELSE([tputs_link_source], [], [msg=no])])
+ LIBS=$OLIBS
+ if test "X$msg" != Xno; then
+ break
+ fi
+ done
+fi
AC_MSG_RESULT([$msg])
if test "X$msg" = Xno; then
AC_MSG_ERROR([The required function `tputs' was not found in any library.
@@ -3000,6 +3195,11 @@ fail;
fi
;;
+ mingw32)
+ TERMINFO=no
+ LIBS_TERMCAP=
+ ;;
+
netbsd)
if test "x$LIBS_TERMCAP" != "x-lterminfo"; then
TERMINFO=no
@@ -3289,11 +3489,14 @@ dnl AC_DEFINE(HAVE_TCATTR, 1, [Define
dnl fi
dnl Turned on June 1996 supposing nobody will mind it.
-AC_DEFINE(AMPERSAND_FULL_NAME, 1, [Define to use the convention that &
- in the full name stands for the login id.])
+dnl MinGW emulates passwd database, so this feature doesn't make sense there.
+if test "${opsys}" != "mingw32"; then
+ AC_DEFINE(AMPERSAND_FULL_NAME, 1, [Define to use the convention that &
+ in the full name stands for the login id.])
+fi
-dnl Every platform that uses configure (ie every non-MS platform)
-dnl supports this. There is a create-lockfiles option you can
+dnl Every platform that uses configure supports this.
+dnl There is a create-lockfiles option you can
dnl customize if you do not want the lock files to be written.
dnl So it is not clear that this #define still needs to exist.
AC_DEFINE(CLASH_DETECTION, 1, [Define if you want lock files to be written,
@@ -3303,7 +3506,9 @@ AC_DEFINE(CLASH_DETECTION, 1, [Define if
dnl Everybody supports this, except MS.
dnl Seems like the kind of thing we should be testing for, though.
## Note: PTYs are broken on darwin <6. Use at your own risk.
-AC_DEFINE(HAVE_PTYS, 1, [Define if the system supports pty devices.])
+if test "${opsys}" != "mingw32"; then
+ AC_DEFINE(HAVE_PTYS, 1, [Define if the system supports pty devices.])
+fi
dnl Everybody supports this, except MS-DOS.
dnl Seems like the kind of thing we should be testing for, though.
@@ -3313,10 +3518,19 @@ AC_DEFINE(HAVE_SOCKETS, 1, [Define if th
AH_TEMPLATE(INTERNAL_TERMINAL, [This is substituted when $TERM is "internal".])
-AC_DEFINE(NULL_DEVICE, ["/dev/null"], [Name of the file to open to get
- a null file, or a data sink.])
+if test "${opsys}" = "mingw32"; then
+ AC_DEFINE(NULL_DEVICE, ["NUL:"], [Name of the file to open to get
+ a null file, or a data sink.])
+else
+ AC_DEFINE(NULL_DEVICE, ["/dev/null"], [Name of the file to open to get
+ a null file, or a data sink.])
+fi
-AC_DEFINE(SEPCHAR, [':'], [Character that separates PATH elements.])
+if test "${opsys}" = "mingw32"; then
+ AC_DEFINE(SEPCHAR, [';'], [Character that separates PATH elements.])
+else
+ AC_DEFINE(SEPCHAR, [':'], [Character that separates PATH elements.])
+fi
dnl Everybody supports this, except MS-DOS.
AC_DEFINE(subprocesses, 1, [Define to enable asynchronous subprocesses.])
@@ -3327,19 +3541,29 @@ AC_DEFINE(USER_FULL_NAME, [pw->pw_gecos]
AC_DEFINE(DIRECTORY_SEP, ['/'],
[Character that separates directories in a file name.])
-dnl Only used on MS platforms.
-AH_TEMPLATE(DEVICE_SEP, [Character that separates a device in a file name.])
+if test "${opsys}" = "mingw32"; then
+ dnl Only used on MS platforms.
+ AC_DEFINE(DEVICE_SEP, ':', [Character that separates a device in a file name.])
+ AC_DEFINE(IS_DEVICE_SEP(_c_), [((_c_) == DEVICE_SEP)],
+ [Returns true if character is a device separator.])
+
+ AC_DEFINE(IS_DIRECTORY_SEP(_c_), [((_c_) == '/' || (_c_) == '\\')],
+ [Returns true if character is a directory separator.])
-AC_DEFINE(IS_DEVICE_SEP(_c_), 0,
- [Returns true if character is a device separator.])
+ AC_DEFINE(IS_ANY_SEP(_c_), [(IS_DIRECTORY_SEP (_c_) || IS_DEVICE_SEP(_c_))],
+ [Returns true if character is any form of separator.])
+else
+ AH_TEMPLATE(DEVICE_SEP, [Character that separates a device in a file name.])
-AC_DEFINE(IS_DIRECTORY_SEP(_c_), [((_c_) == DIRECTORY_SEP)],
- [Returns true if character is a directory separator.])
+ AC_DEFINE(IS_DEVICE_SEP(_c_), 0,
+ [Returns true if character is a device separator.])
-dnl On MS, this also accepts IS_DEVICE_SEP.
-AC_DEFINE(IS_ANY_SEP(_c_), [(IS_DIRECTORY_SEP (_c_))],
- [Returns true if character is any form of separator.])
+ AC_DEFINE(IS_DIRECTORY_SEP(_c_), [((_c_) == DIRECTORY_SEP)],
+ [Returns true if character is a directory separator.])
+ AC_DEFINE(IS_ANY_SEP(_c_), [(IS_DIRECTORY_SEP (_c_))],
+ [Returns true if character is any form of separator.])
+fi
AH_TEMPLATE(NO_EDITRES, [Define if XEditRes should not be used.])
@@ -3728,10 +3952,14 @@ else
esac
fi dnl GCC?
+dnl In a weird quirk, MS runtime uses _setjmp and longjmp.
AC_CACHE_CHECK([for _setjmp], [emacs_cv_func__setjmp],
[AC_LINK_IFELSE(
[AC_LANG_PROGRAM(
[[#include <setjmp.h>
+ #ifdef __MINGW32__
+ # define _longjmp longjmp
+ #endif
]],
[[jmp_buf j;
if (! _setjmp (j))
@@ -3826,6 +4054,14 @@ case $opsys in
AC_DEFINE(IRIX6_5, [], [Define if the system is IRIX.])
;;
+ mingw32)
+ AC_DEFINE(DOS_NT, [])
+ AC_DEFINE(WINDOWSNT, 1, [Define if compiling for native MS Windows.])
+ if test "x$ac_enable_checking" != "x" ; then
+ AC_DEFINE(EMACSDEBUG, 1, [Define to 1 to enable w32 debug facilities.])
+ fi
+ ;;
+
sol2*)
AC_DEFINE(USG, [])
AC_DEFINE(USG5, [])
@@ -3847,6 +4083,10 @@ AC_CACHE_CHECK([for usable FIONREAD], [e
emacs_cv_usable_FIONREAD=no
;;
+ mingw32)
+ emacs_cv_usable_FIONREAD=yes
+ ;;
+
*)
AC_COMPILE_IFELSE(
[AC_LANG_PROGRAM([[#include <sys/types.h>
@@ -3987,6 +4227,12 @@ AC_DEFINE_UNQUOTED(EMACS_CONFIG_OPTIONS,
AH_TEMPLATE(config_opsysfile, [Some platforms that do not use configure
define this to include extra configuration information.])
+case $opsys in
+ mingw32)
+ AC_DEFINE(config_opsysfile, <ms-w32.h>, [])
+ ;;
+esac
+
XMENU_OBJ=
XOBJ=
FONT_OBJ=
@@ -4047,12 +4293,14 @@ case "$USE_X_TOOLKIT" in
esac
AC_SUBST(TOOLKIT_LIBW)
-if test "$USE_X_TOOLKIT" = "none"; then
- LIBXT_OTHER="\$(LIBXSM)"
- OLDXMENU_TARGET="really-oldXMenu"
-else
- LIBXT_OTHER="\$(LIBXMU) -lXt \$(LIBXTR6) -lXext"
- OLDXMENU_TARGET="really-lwlib"
+if test "${opsys}" != "mingw32"; then
+ if test "$USE_X_TOOLKIT" = "none"; then
+ LIBXT_OTHER="\$(LIBXSM)"
+ OLDXMENU_TARGET="really-oldXMenu"
+ else
+ LIBXT_OTHER="\$(LIBXMU) -lXt \$(LIBXTR6) -lXext"
+ OLDXMENU_TARGET="really-lwlib"
+ fi
fi
AC_SUBST(LIBXT_OTHER)
@@ -4126,6 +4374,10 @@ if test "$opsys" = "cygwin"; then
## Cygwin differs because of its unexec().
PRE_ALLOC_OBJ=
POST_ALLOC_OBJ=lastfile.o
+elif test "$opsys" = "mingw32"; then
+ CYGWIN_OBJ=
+ PRE_ALLOC_OBJ=
+ POST_ALLOC_OBJ=lastfile.o
else
CYGWIN_OBJ=
PRE_ALLOC_OBJ=lastfile.o
@@ -4153,6 +4405,12 @@ gl_INIT
CFLAGS=$SAVE_CFLAGS
LIBS=$SAVE_LIBS
+if test "${opsys}" = "mingw32"; then
+ CPPFLAGS="$CPPFLAGS -DUSE_CRT_DLL=1 -I $srcdir/nt/inc"
+ # Remove unneeded switches from the value of CC that goes to Makefiles
+ CC=`echo $CC | sed -e "s,$GCC_TEST_OPTIONS,,"`
+fi
+
case "$opsys" in
aix4-2) LD_SWITCH_SYSTEM_TEMACS="-Wl,-bnodelcsect" ;;
@@ -4186,6 +4444,13 @@ case "$opsys" in
## It seems clearer therefore to put this piece in LD_SWITCH_SYSTEM_TEMACS.
gnu*) LD_SWITCH_SYSTEM_TEMACS="\$(LD_SWITCH_X_SITE_RPATH)" ;;
+ mingw32)
+ case "$canonical" in
+ x86_64-*-*) LD_SWITCH_SYSTEM_TEMACS="-Wl,-stack,0x00800000 -Wl,-heap,0x00100000 -Wl,-image-base,0x01000000 -Wl,-subsystem,console -Wl,-entry,_start -Wl,-Map,./temacs.map" ;;
+ *) LD_SWITCH_SYSTEM_TEMACS="-Wl,-stack,0x00800000 -Wl,-heap,0x00100000 -Wl,-image-base,0x01000000 -Wl,-subsystem,console -Wl,-entry,__start -Wl,-Map,./temacs.map" ;;
+ esac
+ ;;
+
*) LD_SWITCH_SYSTEM_TEMACS= ;;
esac
@@ -4198,6 +4463,24 @@ fi
AC_SUBST(LD_SWITCH_SYSTEM_TEMACS)
+## MinGW-specific post-link processing of temacs.
+TEMACS_POST_LINK=":"
+ADDSECTION=
+EMACS_HEAPSIZE=
+if test "${opsys}" = "mingw32"; then
+ TEMACS_POST_LINK="\$(MINGW_TEMACS_POST_LINK)"
+ ADDSECTION="../nt/addsection\$(EXEEXT)"
+ ## Preload heap size of temacs.exe in MB.
+ case "$canonical" in
+ x86_64-*-*) EMACS_HEAPSIZE=42 ;;
+ *) EMACS_HEAPSIZE=27 ;;
+ esac
+fi
+
+AC_SUBST(ADDSECTION)
+AC_SUBST(TEMACS_POST_LINK)
+AC_SUBST(EMACS_HEAPSIZE)
+
## Common for all window systems
if test "$window_system" != "none"; then
AC_DEFINE(HAVE_WINDOW_SYSTEM, 1, [Define if you have a window system.])
@@ -4356,12 +4639,12 @@ dnl This will work, but you get a config
dnl (see http://lists.gnu.org/archive/html/bug-autoconf/2008-08/msg00028.html).
dnl That doesn't have any obvious consequences for Emacs, but on the whole
dnl it seems better to just live with the duplication.
-SUBDIR_MAKEFILES="lib/Makefile lib-src/Makefile oldXMenu/Makefile doc/emacs/Makefile doc/misc/Makefile doc/lispintro/Makefile doc/lispref/Makefile src/Makefile lwlib/Makefile lisp/Makefile leim/Makefile nextstep/Makefile"
+SUBDIR_MAKEFILES="lib/Makefile lib-src/Makefile oldXMenu/Makefile doc/emacs/Makefile doc/misc/Makefile doc/lispintro/Makefile doc/lispref/Makefile src/Makefile lwlib/Makefile lisp/Makefile leim/Makefile nextstep/Makefile nt/Makefile"
AC_CONFIG_FILES([Makefile lib/Makefile lib-src/Makefile oldXMenu/Makefile \
doc/emacs/Makefile doc/misc/Makefile doc/lispintro/Makefile \
doc/lispref/Makefile src/Makefile lwlib/Makefile lisp/Makefile \
- leim/Makefile nextstep/Makefile])
+ leim/Makefile nextstep/Makefile nt/Makefile])
dnl test/ is not present in release tarfiles.
opt_makefile=test/automated/Makefile
@@ -4404,8 +4687,12 @@ dnl by configure. This also explains th
dnl the use of force in the `epaths-force' rule in Makefile.in.
AC_CONFIG_COMMANDS([epaths], [
echo creating src/epaths.h
-${MAKE-make} MAKEFILE_NAME=do-not-make-Makefile epaths-force
-], [GCC="$GCC" CPPFLAGS="$CPPFLAGS"])
+if test "${opsys}" = "mingw32"; then
+ ${MAKE-make} MAKEFILE_NAME=do-not-make-Makefile epaths-force-w32
+else
+ ${MAKE-make} MAKEFILE_NAME=do-not-make-Makefile epaths-force
+fi
+], [GCC="$GCC" CPPFLAGS="$CPPFLAGS" opsys="$opsys"])
AC_CONFIG_COMMANDS([gdbinit], [
if test ! -f src/.gdbinit && test -f "$srcdir/src/.gdbinit"; then
=== modified file 'lib-src/Makefile.in'
--- lib-src/Makefile.in 2013-03-13 18:42:22 +0000
+++ lib-src/Makefile.in 2013-04-14 15:28:50 +0000
@@ -113,8 +113,11 @@ MKDIR_P = @MKDIR_P@
# ========================== Lists of Files ===========================
+# emacsclientw.exe for MinGW, empty otherwise
+CLIENTW = @CLIENTW@
+
# Things that a user might actually run, which should be installed in bindir.
-INSTALLABLES = etags${EXEEXT} ctags${EXEEXT} emacsclient${EXEEXT} \
+INSTALLABLES = etags${EXEEXT} ctags${EXEEXT} emacsclient${EXEEXT} $(CLIENTW) \
ebrowse${EXEEXT}
INSTALLABLE_SCRIPTS = grep-changelog
@@ -163,10 +166,21 @@ LIBS_MAIL=@LIBS_MAIL@
LIB_CLOCK_GETTIME = @LIB_CLOCK_GETTIME@
## empty or -lrt or -lposix4 if HAVE_FDATASYNC
LIB_FDATASYNC = @LIB_FDATASYNC@
+## empty or -lwsock2 for MinGW
+LIB_WSOCK32=@LIB_WSOCK32@
## Extra libraries to use when linking movemail.
LIBS_MOVE = $(LIBS_MAIL) $(KRB4LIB) $(DESLIB) $(KRB5LIB) $(CRYPTOLIB) \
- $(COM_ERRLIB) $(LIBHESIOD) $(LIBRESOLV)
+ $(COM_ERRLIB) $(LIBHESIOD) $(LIBRESOLV) $(LIB_WSOCK32)
+
+## Extra libraries when linking emacsclient
+## (empty or -lcomctl32 for MinGW)
+LIBS_ECLIENT = @LIBS_ECLIENT@
+
+## Extra object files for linking for MinGW
+NTLIB = @NTLIB@
+CLIENTRES = @CLIENTRES@
+WINDRES = @WINDRES@
## Some systems define this to request special libraries.
LIBS_SYSTEM = @LIBS_SYSTEM@
@@ -227,7 +241,7 @@ $(DESTDIR)${archlibdir}: all
umask 022; ${MKDIR_P} $(DESTDIR)${gamedir}; \
touch $(DESTDIR)${gamedir}/snake-scores; \
touch $(DESTDIR)${gamedir}/tetris-scores
- -if chown ${gameuser} $(DESTDIR)${archlibdir}/update-game-score && chmod u+s $(DESTDIR)${archlibdir}/update-game-score; then \
+ -if chown ${gameuser} $(DESTDIR)${archlibdir}/update-game-score${EXEEXT} && chmod u+s $(DESTDIR)${archlibdir}/update-game-score${EXEEXT}; then \
chown ${gameuser} $(DESTDIR)${gamedir}; \
chmod u=rwx,g=rwx,o=rx $(DESTDIR)${gamedir}; \
fi
@@ -292,7 +306,7 @@ TAGS: etags${EXEEXT}
## distribute Emacs. If they were clobbered, all the .elc files were
## clobbered too.
test-distrib${EXEEXT}: ${srcdir}/test-distrib.c
- $(CC) ${ALL_CFLAGS} -o test-distrib ${srcdir}/test-distrib.c
+ $(CC) ${ALL_CFLAGS} -o test-distrib${EXEEXT} ${srcdir}/test-distrib.c
./test-distrib ${srcdir}/testfile
../lib/libgnu.a: $(config_h)
@@ -302,47 +316,68 @@ regex.o: $(srcdir)/../src/regex.c $(srcd
${CC} -c ${CPP_CFLAGS} -DCONFIG_BROKETS -DINHIBIT_STRING_HEADER \
${srcdir}/../src/regex.c
-etags${EXEEXT}: ${srcdir}/etags.c regex.o $(config_h)
+etags${EXEEXT}: ${srcdir}/etags.c regex.o $(NTLIB) $(config_h)
$(CC) ${ALL_CFLAGS} -DEMACS_NAME="\"GNU Emacs\"" \
-DVERSION="\"${version}\"" ${srcdir}/etags.c \
- regex.o $(LOADLIBES) -o etags
+ regex.o $(LOADLIBES) $(NTLIB) -o etags${EXEEXT}
-ebrowse${EXEEXT}: ${srcdir}/ebrowse.c ${srcdir}/../lib/min-max.h $(config_h)
+ebrowse${EXEEXT}: ${srcdir}/ebrowse.c ${srcdir}/../lib/min-max.h $(NTLIB) \
+ $(config_h)
$(CC) ${ALL_CFLAGS} -DVERSION="\"${version}\"" \
- ${srcdir}/ebrowse.c $(LOADLIBES) -o ebrowse
+ ${srcdir}/ebrowse.c $(LOADLIBES) $(NTLIB) -o ebrowse${EXEEXT}
## We depend on etags to assure that parallel makes do not write two
## etags.o files on top of each other.
ctags${EXEEXT}: etags${EXEEXT}
$(CC) ${ALL_CFLAGS} -DCTAGS -DEMACS_NAME="\"GNU Emacs\"" \
-DVERSION="\"${version}\"" ${srcdir}/etags.c \
- regex.o $(LOADLIBES) -o ctags
+ regex.o $(LOADLIBES) $(NTLIB) -o ctags${EXEEXT}
-profile${EXEEXT}: ${srcdir}/profile.c $(config_h)
+profile${EXEEXT}: ${srcdir}/profile.c $(NTLIB) $(config_h)
$(CC) ${ALL_CFLAGS} ${srcdir}/profile.c \
- $(LOADLIBES) $(LIB_CLOCK_GETTIME) -o profile
+ $(LOADLIBES) $(NTLIB) $(LIB_CLOCK_GETTIME) -o profile${EXEEXT}
-make-docfile${EXEEXT}: ${srcdir}/make-docfile.c $(config_h)
- $(CC) ${ALL_CFLAGS} ${srcdir}/make-docfile.c $(LOADLIBES) \
- -o make-docfile
+make-docfile${EXEEXT}: ${srcdir}/make-docfile.c $(NTLIB) $(config_h)
+ $(CC) ${ALL_CFLAGS} ${srcdir}/make-docfile.c $(LOADLIBES) $(NTLIB) \
+ -o make-docfile${EXEEXT}
-movemail${EXEEXT}: ${srcdir}/movemail.c pop.o $(config_h)
+movemail${EXEEXT}: ${srcdir}/movemail.c pop.o $(NTLIB) $(config_h)
$(CC) ${ALL_CFLAGS} ${MOVE_FLAGS} ${srcdir}/movemail.c pop.o \
- $(LOADLIBES) $(LIBS_MOVE) -o movemail
+ $(LOADLIBES) $(NTLIB) $(LIBS_MOVE) -o movemail${EXEEXT}
-pop.o: ${srcdir}/pop.c ${srcdir}/../lib/min-max.h $(config_h)
+pop.o: ${srcdir}/pop.c ${srcdir}/pop.h ${srcdir}/../lib/min-max.h $(config_h)
$(CC) -c ${CPP_CFLAGS} ${MOVE_FLAGS} ${srcdir}/pop.c
-emacsclient${EXEEXT}: ${srcdir}/emacsclient.c $(config_h)
+emacsclient${EXEEXT}: ${srcdir}/emacsclient.c $(NTLIB) $(config_h)
$(CC) ${ALL_CFLAGS} ${srcdir}/emacsclient.c \
- -DVERSION="\"${version}\"" \
- $(LOADLIBES) $(LIB_FDATASYNC) -o emacsclient
+ -DVERSION="\"${version}\"" $(NTLIB) $(LOADLIBES) $(LIB_FDATASYNC) \
+ $(LIB_WSOCK32) $(LIBS_ECLIENT) -o emacsclient${EXEEXT}
-hexl${EXEEXT}: ${srcdir}/hexl.c $(config_h)
- $(CC) ${ALL_CFLAGS} ${srcdir}/hexl.c $(LOADLIBES) -o hexl
+emacsclientw${EXEEXT}: ${srcdir}/emacsclient.c $(NTLIB) $(CLIENTRES) $(config_h)
+ $(CC) ${ALL_CFLAGS} $(CLIENTRES) -mwindows ${srcdir}/emacsclient.c \
+ -DVERSION="\"${version}\"" $(LOADLIBES) $(LIB_FDATASYNC) \
+ $(LIB_WSOCK32) $(LIBS_ECLIENT) -o emacsclientw${EXEEXT}
+
+NTINC = ${srcdir}/../nt/inc
+NTDEPS = $(NTINC)/ms-w32.h $(NTINC)/sys/stat.h $(NTINC)/inttypes.h \
+ $(NTINC)/stdint.h $(NTINC)/pwd.h $(NTINC)/sys/time.h $(NTINC)/stdbool.h \
+ $(NTINC)/sys/wait.h $(NTINC)/unistd.h $(NTINC)/sys/file.h $(NTINC)/netdb.h
+
+# The dependency on $(NTDEPS) is a trick intended to cause recompile of
+# programs on MinGW whenever some private header in nt/inc is modified.
+ntlib.o: ${srcdir}/ntlib.c ${srcdir}/ntlib.h $(NTDEPS)
+ $(CC) -c ${CPP_CFLAGS} ${srcdir}/ntlib.c
-update-game-score${EXEEXT}: ${srcdir}/update-game-score.c $(config_h)
+hexl${EXEEXT}: ${srcdir}/hexl.c $(NTLIB) $(config_h)
+ $(CC) ${ALL_CFLAGS} ${srcdir}/hexl.c $(LOADLIBES) -o hexl${EXEEXT}
+
+update-game-score${EXEEXT}: ${srcdir}/update-game-score.c $(NTLIB) $(config_h)
$(CC) ${ALL_CFLAGS} -DHAVE_SHARED_GAME_DIR="\"$(gamedir)\"" \
- ${srcdir}/update-game-score.c $(LOADLIBES) -o update-game-score
+ ${srcdir}/update-game-score.c $(LOADLIBES) $(NTLIB) \
+ -o update-game-score${EXEEXT}
+
+emacsclient.res: $(NTINC)/../emacsclient.rc
+ $(WINDRES) -O coff --include-dir=$(NTINC)/.. -o emacsclient.res \
+ $(NTINC)/../emacsclient.rc
## Makefile ends here.
=== modified file 'lib-src/ntlib.c'
--- lib-src/ntlib.c 2013-03-26 08:21:27 +0000
+++ lib-src/ntlib.c 2013-03-31 13:55:12 +0000
@@ -49,10 +49,11 @@ struct timezone
/* Emulate sleep...we could have done this with a define, but that
would necessitate including windows.h in the files that used it.
This is much easier. */
-void
-sleep (unsigned long seconds)
+unsigned
+sleep (unsigned seconds)
{
Sleep (seconds * 1000);
+ return 0;
}
/* Get the current working directory. */
@@ -138,6 +139,12 @@ getuid (void)
}
unsigned
+geteuid (void)
+{
+ return getuid ();
+}
+
+unsigned
getgid (void)
{
return 0;
@@ -415,4 +422,3 @@ lstat (const char * path, struct stat *
{
return stat (path, buf);
}
-
=== modified file 'lib-src/ntlib.h'
--- lib-src/ntlib.h 2013-01-01 09:11:05 +0000
+++ lib-src/ntlib.h 2013-03-30 16:43:19 +0000
@@ -16,7 +16,6 @@ GNU General Public License for more deta
You should have received a copy of the GNU General Public License
along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */
-
#include <pwd.h>
#include <malloc.h>
@@ -29,12 +28,13 @@ along with GNU Emacs. If not, see <http
#ifdef sleep
#undef sleep
#endif
-void sleep (unsigned long seconds);
+unsigned sleep (unsigned seconds);
char *getwd (char *dir);
int getppid (void);
char * getlogin (void);
char * cuserid (char * s);
unsigned getuid (void);
+unsigned geteuid (void);
unsigned getegid (void);
unsigned getgid (void);
int setuid (unsigned uid);
=== modified file 'lib-src/update-game-score.c'
--- lib-src/update-game-score.c 2013-01-02 16:13:04 +0000
+++ lib-src/update-game-score.c 2013-03-30 16:45:50 +0000
@@ -46,6 +46,10 @@ along with GNU Emacs. If not, see <http
#include <sys/stat.h>
#include <getopt.h>
+#ifdef WINDOWSNT
+#include "ntlib.h"
+#endif
+
#define MAX_ATTEMPTS 5
#define MAX_SCORES 200
#define MAX_DATA_LEN 1024
=== modified file 'lib/Makefile.am'
--- lib/Makefile.am 2013-04-07 06:21:40 +0000
+++ lib/Makefile.am 2013-04-14 17:17:40 +0000
@@ -7,6 +7,10 @@ noinst_LIBRARIES =
AM_CFLAGS = $(PROFILING_CFLAGS) $(GNULIB_WARN_CFLAGS) $(WERROR_CFLAGS)
DEFAULT_INCLUDES = -I. -I$(top_srcdir)/lib -I../src -I$(top_srcdir)/src
+if BUILDING_FOR_WINDOWSNT
+include ../nt/gnulib.mk
+else
include gnulib.mk
libgnu_a_SOURCES += openat-die.c save-cwd.c
+endif
=== modified file 'lisp/Makefile.in'
--- lisp/Makefile.in 2013-01-02 16:13:04 +0000
+++ lisp/Makefile.in 2013-04-14 15:04:31 +0000
@@ -24,6 +24,10 @@ abs_top_builddir = @abs_top_builddir@
lisp = $(srcdir)
VPATH = $(srcdir)
+# Empty for all systems except MinGW, where xargs needs an explicit
+# limitation.
+XARGS_LIMIT = @XARGS_LIMIT@
+
# You can specify a different executable on the make command line,
# e.g. "make EMACS=../src/emacs ...".
@@ -160,21 +164,21 @@ $(lisp)/cus-load.el:
custom-deps: doit
cd $(lisp); $(setwins_almost); \
echo Directories: $$wins; \
- $(emacs) -l cus-dep --eval '(setq generated-custom-dependencies-file "$(lisp)/cus-load.el")' -f custom-make-dependencies $$wins
+ $(emacs) -l cus-dep --eval '(set-generated-custom-dependencies-file "$(lisp)/cus-load.el")' -f custom-make-dependencies $$wins
$(lisp)/finder-inf.el:
$(MAKE) $(MFLAGS) finder-data
finder-data: doit
cd $(lisp); $(setwins_almost); \
echo Directories: $$wins; \
- $(emacs) -l finder --eval '(setq generated-finder-keywords-file "$(lisp)/finder-inf.el")' -f finder-compile-keywords-make-dist $$wins
+ $(emacs) -l finder --eval '(set-generated-finder-keywords-file "$(lisp)/finder-inf.el")' -f finder-compile-keywords-make-dist $$wins
# The chmod +w is to handle env var CVSREAD=1.
autoloads: $(LOADDEFS) doit
cd $(lisp) && chmod +w $(AUTOGEN_VCS)
cd $(lisp); $(setwins_almost); \
echo Directories: $$wins; \
- $(emacs) -l autoload --eval '(setq generated-autoload-file "$(lisp)/loaddefs.el")' -f batch-update-autoloads $$wins
+ $(emacs) -l autoload --eval '(set-generated-autoload-file "$(lisp)/loaddefs.el")' -f batch-update-autoloads $$wins
# This is required by the bootstrap-emacs target in ../src/Makefile, so
# we know that if we have an emacs executable, we also have a subdirs.el.
@@ -274,7 +278,7 @@ compile-main: compile-clean
test -f $$el || continue; \
test ! -f $${el}c && GREP_OPTIONS= grep '^;.*no-byte-compile: t' $$el > /dev/null && continue; \
echo "$${el}c"; \
- done | xargs echo) | \
+ done | xargs $(XARGS_LIMIT) echo) | \
while read chunk; do \
$(MAKE) $(MFLAGS) compile-targets EMACS="$(EMACS)" TARGETS="$$chunk"; \
done
@@ -369,7 +373,7 @@ mh-autoloads: $(MH_E_DIR)/mh-loaddefs.el
$(MH_E_DIR)/mh-loaddefs.el: $(MH_E_SRC)
$(emacs) -l autoload \
--eval "(setq generate-autoload-cookie \";;;###mh-autoload\")" \
- --eval "(setq generated-autoload-file \"$@\")" \
+ --eval "(set-generated-autoload-file \"$@\")" \
--eval "(setq make-backup-files nil)" \
-f batch-update-autoloads $(MH_E_DIR)
@@ -387,7 +391,7 @@ TRAMP_SRC = $(TRAMP_DIR)/tramp.el $(T
$(TRAMP_DIR)/tramp-loaddefs.el: $(TRAMP_SRC)
$(emacs) -l autoload \
--eval "(setq generate-autoload-cookie \";;;###tramp-autoload\")" \
- --eval "(setq generated-autoload-file \"$@\")" \
+ --eval "(set-generated-autoload-file \"$@\")" \
--eval "(setq make-backup-files nil)" \
-f batch-update-autoloads $(TRAMP_DIR)
@@ -409,21 +413,21 @@ CAL_SRC = $(CAL_DIR)/cal-bahai.el $(CAL_
$(CAL_DIR)/cal-loaddefs.el: $(CAL_SRC)
$(emacs) -l autoload \
--eval "(setq generate-autoload-cookie \";;;###cal-autoload\")" \
- --eval "(setq generated-autoload-file \"$@\")" \
+ --eval "(set-generated-autoload-file \"$@\")" \
--eval "(setq make-backup-files nil)" \
-f batch-update-autoloads $(CAL_DIR)
$(CAL_DIR)/diary-loaddefs.el: $(CAL_SRC)
$(emacs) -l autoload \
--eval "(setq generate-autoload-cookie \";;;###diary-autoload\")" \
- --eval "(setq generated-autoload-file \"$@\")" \
+ --eval "(set-generated-autoload-file \"$@\")" \
--eval "(setq make-backup-files nil)" \
-f batch-update-autoloads $(CAL_DIR)
$(CAL_DIR)/hol-loaddefs.el: $(CAL_SRC)
$(emacs) -l autoload \
--eval "(setq generate-autoload-cookie \";;;###holiday-autoload\")" \
- --eval "(setq generated-autoload-file \"$@\")" \
+ --eval "(set-generated-autoload-file \"$@\")" \
--eval "(setq make-backup-files nil)" \
-f batch-update-autoloads $(CAL_DIR)
=== modified file 'lisp/cus-dep.el'
--- lisp/cus-dep.el 2013-01-01 09:11:05 +0000
+++ lisp/cus-dep.el 2013-04-14 14:25:36 +0000
@@ -38,6 +38,18 @@ ldefs-boot\\|cus-load\\|finder-inf\\|esh
(autoload 'autoload-rubric "autoload")
+(defun set-generated-custom-dependencies-file (file)
+ "Set value of `generated-custom-dependencies-file' from FILE.
+
+On systems other than MS-Windows, just sets the value
+of `generated-custom-dependencies-file'. On MS-Windows, converts
+/d/foo/bar form passed by MSYS Make into d:/foo/bar that Emacs can
+grok. This function is called from lisp/Makefile."
+ (when (and (eq system-type 'windows-nt)
+ (string-match "\\`/[a-zA-Z]/" file))
+ (setq file (concat (substring file 1 2) ":" (substring file 2))))
+ (setq generated-custom-dependencies-file file))
+
(defun custom-make-dependencies ()
"Batch function to extract custom dependencies from .el files.
Usage: emacs -batch -l ./cus-dep.el -f custom-make-dependencies DIRS"
=== modified file 'lisp/emacs-lisp/autoload.el'
--- lisp/emacs-lisp/autoload.el 2013-01-01 09:11:05 +0000
+++ lisp/emacs-lisp/autoload.el 2013-04-14 14:27:05 +0000
@@ -86,6 +86,18 @@ that text will be copied verbatim to `ge
(defvar autoload-modified-buffers) ;Dynamically scoped var.
+(defun set-generated-autoload-file (file)
+ "Set value of `generated-autoload-file' from FILE.
+
+On systems other than MS-Windows, just sets the value
+of `generated-autoload-file'. On MS-Windows, converts /d/foo/bar
+form passed by MSYS Make into d:/foo/bar that Emacs can grok.
+This function is called from lisp/Makefile."
+ (when (and (eq system-type 'windows-nt)
+ (string-match "\\`/[a-zA-Z]/" file))
+ (setq file (concat (substring file 1 2) ":" (substring file 2))))
+ (setq generated-autoload-file file))
+
(defun make-autoload (form file &optional expansion)
"Turn FORM into an autoload or defvar for source file FILE.
Returns nil if FORM is not a special autoload form (i.e. a function definition
=== modified file 'lisp/finder.el'
--- lisp/finder.el 2013-01-01 09:11:05 +0000
+++ lisp/finder.el 2013-04-14 14:26:56 +0000
@@ -138,6 +138,18 @@ cus-load\\|finder-inf\\|esh-groups\\|sub
(autoload 'autoload-rubric "autoload")
+(defun set-generated-finder-keywords-file (file)
+ "Set value of `generated-finder-keywords-file' from FILE.
+
+On systems other than MS-Windows, just sets the value
+of `generated-finder-keywords-file'. On MS-Windows, converts
+/d/foo/bar form passed by MSYS Make into d:/foo/bar that Emacs
+can grok. This function is called from lisp/Makefile."
+ (when (and (eq system-type 'windows-nt)
+ (string-match "\\`/[a-zA-Z]/" file))
+ (setq file (concat (substring file 1 2) ":" (substring file 2))))
+ (setq generated-finder-keywords-file file))
+
(defvar finder--builtins-alist
'(("calc" . calc)
("ede" . ede)
=== modified file 'lisp/loadup.el'
--- lisp/loadup.el 2013-01-01 09:11:05 +0000
+++ lisp/loadup.el 2013-04-16 17:25:22 +0000
@@ -290,9 +290,12 @@
(equal (nth 4 command-line-args) "dump"))
(not (eq system-type 'ms-dos)))
(let* ((base (concat "emacs-" emacs-version "."))
+ (exelen (if (eq system-type 'windows-nt) -4))
(files (file-name-all-completions base default-directory))
- (versions (mapcar (function (lambda (name)
- (string-to-number (substring name (length base)))))
+ (versions (mapcar (function
+ (lambda (name)
+ (string-to-number
+ (substring name (length base) exelen))))
files)))
(setq emacs-bzr-version (condition-case nil (emacs-bzr-get-version)
(error nil)))
@@ -311,8 +314,18 @@
"-"
(substring name (match-end 0)))))
(if (memq system-type '(ms-dos windows-nt))
- (setq name (expand-file-name
- (if (fboundp 'x-create-frame) "DOC-X" "DOC") "../etc"))
+ (let ((name1 (expand-file-name
+ (if (fboundp 'x-create-frame) "DOC-X" "DOC")
+ "../etc")))
+ ;; There will be no DOC-X on MS-Windows when we build
+ ;; using the Posix Makefile's. In that case, we want
+ ;; to create DOC-XX.YY.ZZ, as on Unix.
+ (if (file-exists-p name1)
+ (setq name name1)
+ (setq name (concat (expand-file-name "../etc/DOC-") name))
+ (if (file-exists-p name)
+ (delete-file name))
+ (copy-file (expand-file-name "../etc/DOC") name t)))
(setq name (concat (expand-file-name "../etc/DOC-") name))
(if (file-exists-p name)
(delete-file name))
@@ -388,18 +401,25 @@
(dump-emacs "emacs" "temacs")
(message "%d pure bytes used" pure-bytes-used)
;; Recompute NAME now, so that it isn't set when we dump.
- (if (not (or (memq system-type '(ms-dos windows-nt))
+ (if (not (or (eq system-type 'ms-dos)
;; Don't bother adding another name if we're just
;; building bootstrap-emacs.
(equal (nth 3 command-line-args) "bootstrap")
(equal (nth 4 command-line-args) "bootstrap")))
- (let ((name (concat "emacs-" emacs-version)))
+ (let ((name (concat "emacs-" emacs-version))
+ (exe (if (eq system-type 'windows-nt) ".exe" "")))
(while (string-match "[^-+_.a-zA-Z0-9]+" name)
(setq name (concat (downcase (substring name 0 (match-beginning 0)))
"-"
(substring name (match-end 0)))))
+ (setq name (concat name exe))
(message "Adding name %s" name)
- (add-name-to-file "emacs" name t)))
+ ;; When this runs on Windows, invocation-directory is not
+ ;; necessarily the current directory.
+ (add-name-to-file (expand-file-name (concat "emacs" exe)
+ invocation-directory)
+ (expand-file-name name invocation-directory)
+ t)))
(kill-emacs)))
;; For machines with CANNOT_DUMP defined in config.h,
=== modified file 'nt/INSTALL'
--- nt/INSTALL 2013-02-02 08:23:52 +0000
+++ nt/INSTALL 2013-04-15 16:32:40 +0000
@@ -13,9 +13,13 @@
Do not use this recipe with Cygwin. For building on Cygwin,
use the normal installation instructions, ../INSTALL.
- If you have a Cygwin or MSYS port of Bash on your Path, you will be
- better off removing it from PATH. (For details, search for "MSYS
- sh.exe" below.)
+ Do not use these instructions with MSYS encironment. For building
+ the native Windows binary with MinGW and MSYS, follow the
+ instructions in the file INSTALL.MSYS in this directory.
+
+ For building without MSYS, if you have a Cygwin or MSYS port of Bash
+ on your Path, you will be better off removing it from PATH. (For
+ details, search for "MSYS sh.exe" below.)
1. Change to the `nt' directory (the directory of this file):
=== added file 'nt/INSTALL.MSYS'
--- nt/INSTALL.MSYS 1970-01-01 00:00:00 +0000
+++ nt/INSTALL.MSYS 2013-04-16 13:18:16 +0000
@@ -0,0 +1,575 @@
+ Building and Installing Emacs on MS-Windows
+ using the MSYS and MinGW tools
+
+ Copyright (C) 2013 Free Software Foundation, Inc.
+ See the end of the file for license conditions.
+
+* For the brave (a.k.a. "impatient"):
+
+ For those who have a working MSYS/MinGW development environment and
+ are comfortable with running Posix configure scripts, here are the
+ concise instructions for configuring and building the native Windows
+ binary of Emacs with these tools.
+
+ Do not use this recipe with Cygwin. For building on Cygwin, use the
+ normal installation instructions, ../INSTALL.
+
+ Do not use these instructions if you don't have MSYS installed; for
+ that, see the file INSTALL in this directory.
+
+ 0. Start the MSYS Bash window. Everything else below is done from
+ that window's Bash prompt.
+
+ 0a. If you are building from the development trunk (as opposed to a
+ release tarball), produce the configure script, by typing from
+ the top-level Emacs source directory:
+
+ ./autogen.sh
+
+ 1. If you want to build Emacs outside of the source tree
+ (recommended), create the build directory and chdir there.
+
+ 2. Invoke the MSYS-specific configure script:
+
+ - If you are building outside the source tree:
+
+ /PATH/TO/EMACS/SOURCE/TREE/nt/msysconfig.sh --prefix=PREFIX ...
+
+ - If you are building in-place, i.e. inside the source tree:
+
+ ./nt/msysconfig.sh --prefix=PREFIX ...
+
+ It is always preferable to use --prefix to configure Emacs for
+ some specific location of its installed tree; the default
+ /usr/local is not suitable for Windows.
+
+ You can pass other options to the configure script. Here's a
+ typical example (for an in-place debug build):
+
+ CPPFLAGS='-DGLYPH_DEBUG=1' CFLAGS='-O0 -g3' ./nt/msysconfig.sh --prefix=d:/usr/emacs --enable-checking
+
+ 3. After the configure script finishes, it should display the
+ resulting configuration. After that, type
+
+ make
+
+ Use "make -j N" if your MSYS Make supports parallel execution;
+ the build will take significantly less time in that case. Here N
+ is the number of simultaneous parallel jobs; use the number of
+ the cores on your system.
+
+ 4. Install the produced binaries:
+
+ make install
+
+ If you want the installation tree to go to a place that is
+ different from the one specified by --prefix, say
+
+ make install prefix=/where/ever/you/want
+
+ That's it!
+
+ If these short instructions somehow fail, read the rest of this
+ file.
+
+* Installing MinGW and MSYS
+
+ Make sure you carefully read the following two sections in their
+ entirety and install/configure the various packages as instructed.
+ A correct installation makes all the rest almost trivial; a botched
+ installation will likely make you miserable for quite some time.
+
+** Installing MinGW
+
+ You will need to install the MinGW port of GCC and Binutils, and the
+ MinGW runtime and Windows API distributions, to compile Emacs. You
+ can find these on the MinGW download/Base page:
+
+ https://sourceforge.net/projects/mingw/files/MinGW/Base/
+
+ In general, install the latest stable versions of the following
+ MinGW packages from that page: gcc, binutils, mingw-rt, w32api. You
+ only need the 'bin' and the 'dll' tarballs of each of the above.
+
+ A nice GUI installer, called mingw-get, is available for those who
+ don't like to mess with manual installations. You can download it
+ from here:
+
+ https://sourceforge.net/projects/mingw/files/Installer/mingw-get/
+
+ (This installer only supports packages downloaded from the MinGW
+ site; for the rest you will still need the manual method.)
+
+ MinGW and MSYS packages are distributed as .tar.lzma compressed
+ archives. If you like to install the packages manually, then we
+ recommend to use the Windows port of the 'bsdtar' program to unpack
+ the tarballs. 'bsdtar' is available as part of the 'libarchive'
+ package from here:
+
+ http://sourceforge.net/projects/ezwinports/files/
+
+ The recommended place to install these packages is a single tree
+ starting from some directory on a drive other than the system drive
+ C:. A typical example would be D:\usr, with D:\usr\bin holding the
+ binaries and DLLs (should be added to your Path environment
+ variable), D:\usr\include holding the include files, D:\usr\lib
+ holding the static and import libraries, D:\share holding docs,
+ message catalogs, and package-specific subdirectories, etc.
+
+ Having all the headers and libraries in a single place will greatly
+ reduce the number of -I and -L flags you will have to pass to the
+ configure script (see below), as these files will be right where the
+ compiler expects them.
+
+ We specifically do NOT recommend installing packages below
+ "C:\Program Files" or "C:\Program Files (x86)". These directories
+ are protected on versions of Windows from Vista and on, and you will
+ have difficulties updating and maintaining your installation later,
+ due to UAC elevation prompts, file virtualization, etc. You *have*
+ been warned!
+
+ Additional MinGW packages are required/recommended, especially if
+ you are building from the Bazaar repository:
+
+ . Texinfo (needed to produce the Info manuals when building from bzr)
+
+ Available from http://sourceforge.net/projects/ezwinports/files/.
+
+ . gzip (needed to compress files during "make install")
+
+ Available from http://gnuwin32.sourceforge.net/packages/gzip.htm.
+
+ . pkg-config (needed for building with some optional image libraries)
+
+ Available from http://www.gtk.org/download/win32.php
+
+ Each package might list other packages as prerequisites on its
+ download page (under "Runtime requirements"); download those as
+ well. (Using the GUI installer mingw-get will fetch those
+ prerequisites automatically for you.) A missing prerequisite will
+ manifest itself by the program failing to run and presenting a
+ pop-up dialog that states the missing or incompatible DLL; be sure
+ to find and install these missing DLLs.
+
+ Once you think you have MinGW installed, test the installation by
+ building a trivial "hello, world!" program, and make sure that it
+ builds without any error messages and the binary works when run.
+
+** Installing MSYS
+
+ You will also need a reasonably full MSYS installation. MSYS is an
+ environment needed to run the Posix configure scripts and the
+ resulting Makefile's, in order to produce native Windows binaries
+ using the MinGW compiler and runtime libraries. Here's the list of
+ MSYS packages that are required:
+
+ . All the packages from the MSYS Base distribution, listed here:
+
+ https://sourceforge.net/projects/mingw/files/MSYS/Base/
+
+ . Additional packages listed below, from the MSYS Extension
+ distribution here:
+
+ https://sourceforge.net/projects/mingw/files/MSYS/Extension/
+
+ - flex
+ - bison
+ - m4
+ - perl
+ - mktemp
+
+ These should only be needed if you intend to build development
+ versions of Emacs from the Bazaar repository.
+
+ . Additional packages (needed only if building from the Bazaar
+ repository): Automake and Autoconf. They are available from
+ here:
+
+ http://sourceforge.net/projects/ezwinports/files/automake-1.11.6-msys-bin.zip/download
+ http://sourceforge.net/projects/ezwinports/files/autoconf-2.65-msys-bin.zip/download
+
+ If/when you are confident in your MinGW/MSYS installation, and want
+ to speed up the builds, we recommend installing a pre-release
+ version of Make from here:
+
+ https://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/
+
+ These are snapshot builds of many packages, but you only need
+ make.exe from there. The advantage of this make.exe is that it
+ supports parallel builds, so you can use "make -j N" to considerably
+ speed up your builds
+
+ For each of these packages, install the 'bin' and 'dll' tarballs of
+ their latest stable releases. If there's an 'ext' tarball (e.g.,
+ msysCORE and Coreutils have it), download and install those as well.
+
+ Each package might list other packages as prerequisites on its
+ download page (under "Runtime requirements"); download those as
+ well. (Using the GUI installer mingw-get will fetch those
+ prerequisites automatically for you.) A missing prerequisite will
+ manifest itself by the program failing to run and presenting a
+ pop-up dialog that states the missing or incompatible DLL; be sure
+ to find and install these missing DLLs.
+
+ MSYS packages should be installed in a separate tree from MinGW.
+ For example, use D:\MSYS or D:\usr\MSYS as the top-level directory
+ from which you unpack all of the MSYS packages.
+
+ Do NOT add the MSYS bin directory to your Windows Path! Only the
+ MinGW bin directory should be on Path. When you install MSYS, it
+ creates a shortcut on your desktop that invokes the MSYS Bash shell
+ in a Command Prompt window; that shell is already set up so that the
+ MSYS bin directory is on PATH ahead of any other directory. Thus,
+ Bash will find MSYS executables first, which is exactly what you
+ need.
+
+ At this point, you are ready to build Emacs in its basic
+ configuration. If you want to build it with image support, read
+ about the optional image libraries near the end of this document.
+
+* Generating the configure script.
+
+ If you are building a release or pretest tarball, skip this section,
+ because the configure script is already present in the tarball.
+
+ To build a development snapshot from the Emacs Bazaar repository,
+ you will first need to generate the configure script and a few other
+ auto-generated files. (If this step, described below, somehow
+ fails, you can use the files in the autogen/ directory instead, but
+ they might be outdated, and, most importantly, you are well advised
+ not to disregard any failures in your local build procedures, as
+ these are likely to be symptoms of incorrect installation that will
+ bite you down the road.)
+
+ To generate the configure script, type this at the MSYS Bash prompt
+ from the top-level directory of the Emacs tree:
+
+ ./autogen.sh
+
+ If successful, this command should produce the following output:
+
+ $ ./autogen.sh
+ Checking whether you have the necessary tools...
+ (Read INSTALL.BZR for more details on building Emacs)
+
+ Checking for autoconf (need at least version 2.65)...
+ ok
+ Checking for automake (need at least version 1.11)...
+ ok
+ Your system has the required tools, running autoreconf...
+ You can now run `./configure'.
+
+* Configuring Emacs for MinGW:
+
+ Now it's time to run the configure script. You can do that either
+ from a separate build directory that is outside of the Emacs source
+ tree (recommended), or from inside the source tree. The former is
+ recommended because it allows you to have several different builds,
+ e.g., an optimized build and an unoptimized one, of the same
+ revision of the source tree; the source tree will be left in its
+ pristine state, without any build products.
+
+ You invoke the configure script like this:
+
+ /PATH/TO/EMACS/SOURCE/TREE/nt/msysconfig.sh --prefix=PREFIX ...
+
+ or, if you are building in-place, i.e. inside the source tree:
+
+ ./nt/msysconfig.sh --prefix=PREFIX ...
+
+ Here PREFIX is the place where you eventually want to install Emacs
+ once built, e.g. d:/usr.
+
+ You can pass additional options to the configure script, for the
+ full list type
+
+ ./nt/msysconfig.sh --help
+
+ As explained in the help text, you may need to tell the script what
+ are the optional flags to invoke the compiler. This is needed if
+ some of your headers and libraries, e.g., those belonging to
+ optional image libraries, are installed in places where the compiler
+ normally doesn't look for them. (Remember that advice above to
+ avoid such situations? here's is where you will start paying for
+ disregarding that recommendation.) For example, if you have libpng
+ headers in C:\emacs\libs\libpng-1.2.37-lib\include and jpeg library
+ headers in C:\emacs\libs\jpeg-6b-4-lib\include, you will need to say
+ something like this:
+
+ CPPFLAGS='-Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/jpeg-6b-4-lib/include' ./nt/msysconfig.sh --prefix=PREFIX
+
+ which is quite a mouth-full, especially if you have more directories
+ to specify... Perhaps you may wish to revisit your installation
+ decisions now.
+
+ A few frequently used options are needed when you want to produce an
+ unoptimized binary with runtime checks enabled:
+
+ CPPFLAGS='-DGLYPH_DEBUG=1' CFLAGS='-O0 -g3' ./nt/msysconfig.sh --prefix=PREFIX --enable-checking
+
+ Once invoked, the configure script will run for some time, and, if
+ successful, will eventually produce a summary of the configuration
+ like this:
+
+ Configured for `i686-pc-mingw32'.
+
+ Where should the build process find the source code? /path/to/emacs/sources
+ What compiler should emacs be built with? gcc -std=gnu99 -O0 -g3
+ Should Emacs use the GNU version of malloc? yes
+ Should Emacs use a relocating allocator for buffers? yes
+ Should Emacs use mmap(2) for buffer allocation? no
+ 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 -lpng? yes
+ Does Emacs use -lrsvg-2? no
+ Does Emacs use imagemagick? no
+ Does Emacs use -lgpm? no
+ Does Emacs use -ldbus? no
+ Does Emacs use -lgconf? no
+ Does Emacs use GSettings? no
+ 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 use toolkit scroll bars? yes
+
+ You are almost there, hand on.
+
+ If the output is significantly different, or if configure finishes
+ prematurely and displays some error message, you should examine the
+ configuration log in config.log and find the reason for the failure.
+
+ Once you succeeded in configuring Emacs, and just want to rebuild it
+ after updating your local repository from the main repository, you
+ don't need to re-run the configure script manually, unless you want
+ to change the configure-time options. Just typing "make" will
+ re-run configure if necessary with the exact same options you
+ specified originally, and then go on to invoking Make, described
+ below.
+
+* Running Make.
+
+ This is simple: just type "make" and sit back, watching the fun.
+
+ If you installed a snapshot build of Make, the build will be much
+ faster if you type "make -j N" instead, where N is the number of
+ independent processing units on your machine. E.g., on a core i7
+ system try using N of 6 or even 8.
+
+ When Make finishes, you can install the produced binaries:
+
+ make install
+
+ or, if you want the installed tree to go in a place different from
+ the configured one, type
+
+ make install prefix=WHEREVER
+
+ Congrats! You have built and installed your own Emacs!
+
+* Make targets
+
+ The following make targets may be used by users building the source
+ distribution, or users who have checked out of Bazaar after
+ an initial bootstrapping.
+
+ make
+ Builds Emacs from the available sources and pre-compiled lisp files.
+
+ make install
+ Installs the built programs and the auxiliary files.
+
+ make clean
+ Removes object and executable files produced by the build process in
+ the current configuration. After "make clean", you can rebuild with
+ the same configuration using make. useful when you want to be sure
+ that all of the products are built from coherent sources.
+
+ make distclean
+ In addition to the files removed by make clean, this also removes
+ Makefiles and other generated files to get back to the state of a
+ freshly unpacked source distribution. After make distclean, it is
+ necessary to run the configure script followed by "make", in order
+ to rebuild.
+
+ The following targets are intended only for use with the Bazaar sources.
+
+ make bootstrap
+ Removes all the auto-generated files and all the *.elc byte-compiled
+ files, and builds Emacs from scratch. Useful when some change in
+ basic Emacs functionality makes byte compilation of updated files
+ fail.
+
+ make maintainer-clean
+ Removes everything that can be recreated, including compiled Lisp
+ files, to get back to the state of a fresh Bazaar tree. After make
+ maintainer-clean, it is necessary to run configure and "make" or
+ "make bootstrap" to rebuild. Occasionally it may be necessary to
+ run this target after an update.
+
+* Optional image library support
+
+ In addition to its "native" image formats (pbm and xbm), Emacs can
+ handle other image types: xpm, tiff, gif, png, jpeg and experimental
+ support for svg.
+
+ To build Emacs with support for them, the corresponding headers must
+ be in the include path when the configure script is run. This is be
+ set up using the CPPFLAGS and CFLAGS variable specified on the
+ configure command line. The configure script will report whether it
+ was able to detect the headers. If the results of this testing
+ appear to be incorrect, please look for details in the file
+ config.log: it will show the failed test programs and compiler error
+ messages that should explain what is wrong. (Usually, any such
+ failures happen because some headers are missing due to bad
+ packaging of the image support libraries.)
+
+ Note that any file path passed to the compiler or linker must use
+ forward slashes, or double each backslash, as that is how Bash
+ works.
+
+ If the configure script finds the necessary headers, but they are
+ for some reason incompatible, or if you want to omit support for
+ some image library that is installed on your system for some other
+ reason, use the --without-PACKAGE option to configure, such as
+ --without-gif to omit GIF, --without-tiff to omit TIFF, etc.
+ Passing the --help option to the configure script displays all of
+ the supported --without-PACKAGE options.
+
+ To use the external image support, the DLLs implementing the
+ functionality must be found when Emacs first needs them, either on the
+ PATH, or in the same directory as emacs.exe. Failure to find a
+ library is not an error; the associated image format will simply be
+ unavailable. Note that once Emacs has determined that a library can
+ not be found, there's no way to force it to try again, other than
+ restarting. See the variable `dynamic-library-alist' to configure the
+ expected names of the libraries.
+
+ Some image libraries have dependencies on one another, or on zlib.
+ For example, tiff support depends on the jpeg library. If you did not
+ compile the libraries yourself, you must make sure that any dependency
+ is in the PATH or otherwise accessible and that the binaries are
+ compatible (for example, that they were built with the same compiler).
+
+ Binaries for the image libraries (among many others) can be found at
+ the GnuWin32 project. PNG, JPEG and TIFF libraries are also
+ included with GTK, which is installed along with other Free Software
+ that requires it. Note specifically that, due to some packaging
+ snafus in the GnuWin32-supplied image libraries, you will need to
+ download _source_ packages for some of the libraries in order to get
+ the header files necessary for building Emacs with image support.
+
+ For PNG images, we recommend to use versions 1.4.x and later of
+ libpng, because previous versions had security issues. You can find
+ precompiled libraries and headers on the GTK download page for
+ Windows (http://www.gtk.org/download/win32.php).
+
+ Versions 1.4.0 and later of libpng are binary incompatible with
+ earlier versions, so Emacs will only look for libpng libraries which
+ are compatible with the version it was compiled against. That
+ version is given by the value of the Lisp variable `libpng-version';
+ e.g., 10403 means version 1.4.3. The variable `dynamic-library-alist'
+ is automatically set to name only those DLL names that are known to
+ be compatible with the version given by `libpng-version'. If PNG
+ support does not work for you even though you have the support DLL
+ installed, check the name of the installed DLL against
+ `dynamic-library-alist' and the value of `libpng-version', and
+ download compatible DLLs if needed.
+
+* Optional GnuTLS support
+
+ If the configure script finds the gnutls/gnutls.h file in the
+ include path, Emacs is built with GnuTLS support by default; to
+ avoid that you can pass the argument --without-gnutls.
+
+ In order to support GnuTLS at runtime, a GnuTLS-enabled Emacs must
+ be able to find the relevant DLLs during startup; failure to do so
+ is not an error, but GnuTLS won't be available to the running
+ session.
+
+ You can get pre-built binaries (including any required DLL and the
+ header files) at http://sourceforge.net/projects/ezwinports/files/.
+
+* Optional libxml2 support
+
+ If the configure script finds the libxml/HTMLparser.h file in the
+ include path, Emacs is built with libxml2 support by default; to
+ avoid that you can pass the argument --without-libxml2.
+
+ In order to support libxml2 at runtime, a libxml2-enabled Emacs must
+ be able to find the relevant DLLs during startup; failure to do so
+ is not an error, but libxml2 features won't be available to the
+ running session.
+
+ One place where you can get pre-built Windows binaries of libxml2
+ (including any required DLL and the header files) is here:
+
+ http://sourceforge.net/projects/ezwinports/files/
+
+ For runtime support of libxml2, you will also need to install the
+ libiconv "development" tarball, because the libiconv headers need to
+ be available to the compiler when you compile with libxml2 support.
+ A MinGW port of libiconv can be found on the MinGW site:
+
+ http://sourceforge.net/projects/mingw/files/MinGW/Base/libiconv/
+
+ You need the libiconv-X.Y.Z-N-mingw32-dev.tar.lzma tarball from that
+ site.
+
+* Experimental SVG support
+
+ SVG support is currently experimental, and not built by default.
+ Specify --with-rsvg and ensure you have all the dependencies in your
+ include path. Unless you have built a minimalist librsvg yourself
+ (untested), librsvg depends on a significant chunk of GTK+ to build,
+ plus a few Gnome libraries, libxml2, libbz2 and zlib at runtime. The
+ easiest way to obtain the dependencies required for building is to
+ download a pre-bundled GTK+ development environment for Windows.
+
+ To use librsvg at runtime, ensure that librsvg and its dependencies
+ are on your PATH. If you didn't build librsvg yourself, you will
+ need to check with where you downloaded it from for the
+ dependencies, as there are different build options. If it is a
+ short list, then it most likely only lists the immediate
+ dependencies of librsvg, but the dependencies themselves have
+ dependencies - so don't download individual libraries from GTK+,
+ download and install the whole thing. If you think you've got all
+ the dependencies and SVG support is still not working, check your
+ PATH for other libraries that shadow the ones you downloaded.
+ Libraries of the same name from different sources may not be
+ compatible, this problem was encountered with libbzip2 from GnuWin32
+ with libcroco from gnome.org.
+
+ If you can see etc/images/splash.svg, then you have managed to get
+ SVG support working. Congratulations for making it through DLL hell
+ to this point. You'll probably find that some SVG images crash
+ Emacs. Problems have been observed in some images that contain
+ text, they seem to be a problem in the Windows port of Pango, or
+ maybe a problem with the way Cairo or librsvg is using it that
+ doesn't show up on other platforms.
+
+\f
+This file is part of GNU Emacs.
+
+GNU Emacs is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
+
+GNU Emacs is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>.
=== added file 'nt/Makefile.in'
--- nt/Makefile.in 1970-01-01 00:00:00 +0000
+++ nt/Makefile.in 2013-04-15 13:31:30 +0000
@@ -0,0 +1,212 @@
+# nt/Makefile for GNU Emacs.
+
+# Copyright (C) 2013 Free Software Foundation, Inc.
+
+# This file is part of GNU Emacs.
+
+# GNU Emacs is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# GNU Emacs is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>.
+
+# Avoid trouble on systems where the `SHELL' variable might be
+# inherited from the environment.
+SHELL = /bin/sh
+
+# ==================== Things `configure' will edit ====================
+
+CC=@CC@
+CFLAGS=@CFLAGS@
+version=@version@
+## Used in $archlibdir.
+configuration=@configuration@
+EXEEXT=@EXEEXT@
+C_SWITCH_SYSTEM=@C_SWITCH_SYSTEM@
+C_SWITCH_MACHINE=@C_SWITCH_MACHINE@
+PROFILING_CFLAGS = @PROFILING_CFLAGS@
+WARN_CFLAGS = @WARN_CFLAGS@
+WERROR_CFLAGS = @WERROR_CFLAGS@
+
+# Program name transformation.
+TRANSFORM = @program_transform_name@
+
+# ==================== Where To Install Things ====================
+
+# The default location for installation. Everything is placed in
+# subdirectories of this directory. The default values for many of
+# the variables below are expressed in terms of this one, so you may
+# not need to change them. This is set with the --prefix option to
+# `../configure'.
+prefix=@prefix@
+
+# Like `prefix', but used for architecture-specific files. This is
+# set with the --exec-prefix option to `../configure'.
+exec_prefix=@exec_prefix@
+
+# Where to install Emacs and other binaries that people will want to
+# run directly (like etags). This is set with the --bindir option
+# to `../configure'.
+bindir=@bindir@
+
+# Where to install and expect executable files to be run by Emacs
+# rather than directly by users, and other architecture-dependent
+# data. ${archlibdir} is usually below this. This is set with the
+# --libexecdir option to `../configure'.
+libexecdir=@libexecdir@
+
+# Directory for local state files for all programs.
+localstatedir=@localstatedir@
+
+# Where to find the source code. This is set by the configure
+# script's `--srcdir' option. However, the value of ${srcdir} in
+# this makefile is not identical to what was specified with --srcdir,
+# since the variable here has `/lib-src' added at the end.
+
+# We use $(srcdir) explicitly in dependencies so as not to depend on VPATH.
+srcdir=@srcdir@
+VPATH=@srcdir@
+
+# The top-level source directory, also set by configure.
+top_srcdir=@top_srcdir@
+
+# ==================== Emacs-specific directories ====================
+
+# These variables hold the values Emacs will actually use. They are
+# based on the values of the standard Make variables above.
+
+# Where to put executables to be run by Emacs rather than the user.
+# This path usually includes the Emacs version and configuration name,
+# so that multiple configurations for multiple versions of Emacs may
+# be installed at once. This can be set with the --archlibdir option
+# to `../configure'.
+archlibdir=@archlibdir@
+
+# ==================== Utility Programs for the Build =================
+
+# ../configure figures out the correct values for these.
+INSTALL = @INSTALL@
+INSTALL_PROGRAM = @INSTALL_PROGRAM@
+INSTALL_SCRIPT = @INSTALL_SCRIPT@
+# By default, we uphold the dignity of our programs.
+INSTALL_STRIP =
+MKDIR_P = @MKDIR_P@
+
+# ========================== Lists of Files ===========================
+
+# Things that a user might actually run, which should be installed in bindir.
+INSTALLABLES = runemacs${EXEEXT} addpm${EXEEXT}
+
+# Things that Emacs runs internally, which should not be installed in bindir.
+UTILITIES = cmdproxy${EXEEXT} ddeclient${EXEEXT}
+
+# Things that Emacs runs during the build process.
+DONT_INSTALL = addsection${EXEEXT}
+
+# All files that are created by the linker, i.e., whose names end in ${EXEEXT}.
+EXE_FILES = ${INSTALLABLES} ${UTILITIES} ${DONT_INSTALL}
+
+# =========================== Configuration ===========================
+
+# MS-Windows resource files and resource compiler
+EMACSRES = @EMACSRES@
+EMACS_MANIFEST = @EMACS_MANIFEST@
+WINDRES = @WINDRES@
+
+## Extra libraries to use when linking addpm.
+LIBS_ADDPM = -lole32 -luuid
+
+## Compilation and linking flags
+BASE_CFLAGS = $(C_SWITCH_SYSTEM) $(C_SWITCH_MACHINE) \
+ $(WARN_CFLAGS) $(WERROR_CFLAGS) \
+ -I. -I${srcdir}
+
+ALL_CFLAGS = ${BASE_CFLAGS} ${PROFILING_CFLAGS} ${LDFLAGS} ${CPPFLAGS} ${CFLAGS}
+LINK_CFLAGS = ${BASE_CFLAGS} ${LDFLAGS} ${CFLAGS}
+CPP_CFLAGS = ${BASE_CFLAGS} ${PROFILING_CFLAGS} ${CPPFLAGS} ${CFLAGS}
+
+all: ${EXE_FILES}
+
+.PHONY: all
+
+## Install the internal utilities. Until they are installed, we can
+## just run them directly from nt/.
+$(DESTDIR)${archlibdir}: all
+ @echo
+ @echo "Installing utilities run internally by Emacs."
+ umask 022; ${MKDIR_P} $(DESTDIR)${archlibdir}
+ if [ `cd $(DESTDIR)${archlibdir} && /bin/pwd` != `/bin/pwd` ]; then \
+ for file in ${UTILITIES}; do \
+ $(INSTALL_PROGRAM) $(INSTALL_STRIP) $$file $(DESTDIR)${archlibdir}/$$file ; \
+ done ; \
+ fi
+
+.PHONY: install uninstall mostlyclean clean distclean maintainer-clean
+.PHONY: extraclean check tags
+
+install: $(DESTDIR)${archlibdir}
+ @echo
+ @echo "Installing utilities for users to run."
+ umask 022; ${MKDIR_P} $(DESTDIR)${bindir}
+ for file in ${INSTALLABLES} ; do \
+ $(INSTALL_PROGRAM) $(INSTALL_STRIP) $${file} $(DESTDIR)${bindir}/`echo $${file} | sed -e 's/${EXEEXT}$$//' -e '$(TRANSFORM)'`${EXEEXT} ; \
+ done
+
+uninstall:
+ for file in ${INSTALLABLES}; do \
+ rm -f $(DESTDIR)${bindir}/`echo $${file} | sed -e 's/${EXEEXT}$$//' -e '$(TRANSFORM)'`${EXEEXT} ; \
+ done
+ if [ -d $(DESTDIR)${archlibdir} ]; then \
+ (cd $(DESTDIR)${archlibdir} && rm -f ${UTILITIES}) \
+ fi
+
+mostlyclean:
+ -rm -f core *.o
+
+clean: mostlyclean
+ -rm -f ${EXE_FILES}
+
+distclean: clean
+ -rm -f TAGS
+ -rm -f Makefile
+
+maintainer-clean: distclean
+ true
+
+extraclean: maintainer-clean
+ -rm -f *~ \#*
+
+## Test the contents of the directory.
+check:
+ @echo "We don't have any tests for the nt/ directory yet."
+
+tags: TAGS
+TAGS: ${EXE_FILES:${EXEEXT}=.c}
+ ../lib-src/etags *.[ch]
+
+## Build the programs
+addsection${EXEEXT}: ${srcdir}/addsection.c
+ $(CC) ${ALL_CFLAGS} ${srcdir}/addsection.c -o addsection${EXEEXT}
+
+addpm${EXEEXT}: ${srcdir}/addpm.c ${srcdir}/../src/epaths.h
+ $(CC) ${ALL_CFLAGS} ${srcdir}/addpm.c $(LIBS_ADDPM) -o addpm${EXEEXT}
+
+ddeclient${EXEEXT}: ${srcdir}/ddeclient.c
+ $(CC) ${ALL_CFLAGS} ${srcdir}/ddeclient.c -o ddeclient${EXEEXT}
+
+cmdproxy${EXEEXT}: ${srcdir}/cmdproxy.c
+ $(CC) ${ALL_CFLAGS} ${srcdir}/cmdproxy.c -o cmdproxy${EXEEXT}
+
+runemacs${EXEEXT}: ${srcdir}/runemacs.c $(EMACSRES)
+ $(CC) ${ALL_CFLAGS} ${srcdir}/runemacs.c $(EMACSRES) \
+ -o runemacs${EXEEXT}
+
+emacs.res: ${srcdir}/emacs.rc ${srcdir}/icons/emacs.ico ${srcdir}/$(EMACS_MANIFEST)
+ ${WINDRES} -O coff -o emacs.res emacs.rc
=== modified file 'nt/addpm.c'
--- nt/addpm.c 2013-03-27 07:21:43 +0000
+++ nt/addpm.c 2013-04-15 13:31:42 +0000
@@ -50,6 +50,10 @@ along with GNU Emacs. If not, see <http
#include <shlobj.h>
#include <ddeml.h>
+#ifndef OLD_PATHS
+#include "../src/epaths.h"
+#endif
+
HDDEDATA CALLBACK
DdeCallback (UINT uType, UINT uFmt, HCONV hconv,
HSZ hsz1, HSZ hsz2, HDDEDATA hdata,
@@ -76,6 +80,7 @@ static struct entry
}
env_vars[] =
{
+#ifdef OLD_PATHS
{"emacs_dir", NULL},
{"EMACSLOADPATH", "%emacs_dir%/site-lisp;%emacs_dir%/../site-lisp;%emacs_dir%/lisp;%emacs_dir%/leim"},
{"SHELL", "%emacs_dir%/bin/cmdproxy.exe"},
@@ -86,6 +91,18 @@ env_vars[] =
/* {"INFOPATH", "%emacs_dir%/info"}, */
{"EMACSDOC", "%emacs_dir%/etc"},
{"TERM", "cmd"}
+#else /* !OLD_PATHS */
+ {"emacs_dir", NULL},
+ {"EMACSLOADPATH", PATH_SITELOADSEARCH ";" PATH_LOADSEARCH},
+ {"SHELL", PATH_EXEC "/cmdproxy.exe"},
+ {"EMACSDATA", PATH_DATA},
+ {"EMACSPATH", PATH_EXEC},
+ /* We no longer set INFOPATH because Info-default-directory-list
+ is then ignored. */
+ /* {"INFOPATH", "%emacs_dir%/info"}, */
+ {"EMACSDOC", PATH_DOC},
+ {"TERM", "cmd"}
+#endif
};
BOOL
=== added file 'nt/epaths.nt'
--- nt/epaths.nt 1970-01-01 00:00:00 +0000
+++ nt/epaths.nt 2013-04-06 13:20:36 +0000
@@ -0,0 +1,89 @@
+/* Hey Emacs, this is -*- C -*- code! */
+/* epaths.in file for MS-Windows build that uses the configure script.
+
+ Since Emacs on Windows must be relocatable to any directory, it
+ cannot have here hard-coded directories determined at configure
+ time. Therefore, each directory must begin with %emacs_dir%, which
+ is resolved at startup to the root of the Emacs installation tree
+ (see w32.c:init_environment).
+
+ This file is edited at configure time to replace @VER@ by the Emacs
+ version being built (e.g., 25.9.77), @CFG@ by the canonical name of
+ the host system (e.g., i686-pc-mingw32), and @SRC@ by the root of
+ the Emacs source tree used to build Emacs. */
+/*
+Copyright (C) 1993, 1995, 1997, 1999, 2001-2013 Free Software
+Foundation, Inc.
+
+This file is part of GNU Emacs.
+
+GNU Emacs is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
+
+GNU Emacs is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */
+
+
+/* Together with PATH_SITELOADSEARCH, this gives the default value of
+ load-path, which is the search path for the Lisp function "load".
+ Configure (using "make epaths-force") sets this to
+ ${standardlisppath}, which typically has a value like:
+ <datadir>/emacs/VERSION/lisp:<datadir>/emacs/VERSION/leim
+ where datadir is eg /usr/local/share.
+*/
+#define PATH_LOADSEARCH "%emacs_dir%/share/emacs/@VER@/lisp;%emacs_dir%/share/emacs/@VER@/leim"
+
+/* Like PATH_LOADSEARCH, but contains the non-standard pieces.
+ These are the site-lisp directories, typically something like
+ <datadir>/emacs/VERSION/site-lisp:<datadir>/emacs/site-lisp
+ Configure prepends any $locallisppath, as set by the
+ --enable-locallisppath argument.
+ This is combined with PATH_LOADSEARCH to make the default load-path.
+ If the --no-site-lisp option is used, this piece is excluded.
+*/
+#define PATH_SITELOADSEARCH "%emacs_dir%/share/emacs/@VER@/site-lisp;%emacs_dir%/share/emacs/site-lisp"
+
+/* Like PATH_LOADSEARCH, but used only during the build process
+ when Emacs is dumping. Configure (using "make epaths-force") sets
+ this to $buildlisppath, which normally has the value: <srcdir>/lisp.
+*/
+#define PATH_DUMPLOADSEARCH "@SRC@/lisp"
+
+/* The extra search path for programs to invoke. This is appended to
+ whatever the PATH environment variable says to set the Lisp
+ variable exec-path and the first file name in it sets the Lisp
+ variable exec-directory. exec-directory is used for finding
+ executables and other architecture-dependent files. */
+#define PATH_EXEC "%emacs_dir%/libexec/emacs/@VER@/@CFG@"
+
+/* Where Emacs should look for its architecture-independent data
+ files, like the NEWS file. The lisp variable data-directory
+ is set to this value. */
+#define PATH_DATA "%emacs_dir%/share/emacs/@VER@/etc"
+
+/* Where Emacs should look for X bitmap files.
+ The lisp variable x-bitmap-file-path is set based on this value. */
+#define PATH_BITMAPS ""
+
+/* Where Emacs should look for its docstring file. The lisp variable
+ doc-directory is set to this value. */
+#define PATH_DOC "%emacs_dir%/share/emacs/@VER@/etc"
+
+/* Where the configuration process believes the info tree lives. The
+ lisp variable configure-info-directory gets its value from this
+ macro, and is then used to set the Info-default-directory-list. */
+#define PATH_INFO "%emacs_dir%/share/info"
+
+/* Where Emacs should store game score files. */
+#define PATH_GAME "%emacs_dir%/var/games/emacs"
+
+/* Where Emacs should look for the application default file. */
+#define PATH_X_DEFAULTS ""
+
=== added file 'nt/gnulib.mk'
--- nt/gnulib.mk 1970-01-01 00:00:00 +0000
+++ nt/gnulib.mk 2013-03-31 13:14:54 +0000
@@ -0,0 +1,858 @@
+## This file is an edited copy if ../lib/gnulib.mk.
+##
+## The purpose of the edits is to avoid generating any headers
+## which would conflict with either the headers we have in nt/inc,
+## or with MinGW system headers and subsequent redirection of some
+## functions in nt/inc/ms-w32.h.
+##
+## In general, do NOT remove anything from ../lib/gnulib.mk that
+## doesn't need to be removed, to minimize the differences from
+## upstream gnulib.mk and thus make the maintenance easier. Every
+## header file whose generation is controlled by configure-time tests
+## does NOT need to be removed; instead, force the configure script to
+## accept whatever MinGW has to offer, by defining the appropriate
+## Autoconf variable in the nt/mingw-cfg.site file. Headers that are
+## generated conditionally have the tell-tale "if GL_GENERATE_foo_H"
+## condition before their Makefile snippet in this file. Likewise, do
+## NOT remove gnulib modules which introduce header files that don't
+## exist in MinGW and in nt/inc/, since they cannot possibly clash
+## with anything. Gnulib modules that introduce source *.c files also
+## need not be removed; if they define functions that could clash with
+## the w32 substitutes in Emacs, disable their compilation by defining
+## suitable variables in nt/mingw-cfg.site.
+##
+## Process this file with automake to produce Makefile.in.
+# Copyright (C) 2002-2013 Free Software Foundation, Inc.
+#
+# This file is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This file is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this file. If not, see <http://www.gnu.org/licenses/>.
+#
+# As a special exception to the GNU General Public License,
+# this file may be distributed as part of a program that
+# contains a configuration script generated by Autoconf, under
+# the same distribution terms as the rest of that program.
+#
+# Generated by gnulib-tool.
+# Reproduce by: gnulib-tool --import --dir=. --lib=libgnu --source-base=lib --m4-base=m4 --doc-base=doc --tests-base=tests --aux-dir=build-aux --avoid=dup --avoid=errno --avoid=fchdir --avoid=fcntl --avoid=fstat --avoid=malloc-posix --avoid=msvc-inval --avoid=msvc-nothrow --avoid=open --avoid=openat-die --avoid=opendir --avoid=raise --avoid=save-cwd --avoid=select --avoid=sigprocmask --avoid=sys_types --avoid=threadlib --makefile-name=gnulib.mk --conditional-dependencies --no-libtool --macro-prefix=gl --no-vc-files alloca-opt c-ctype c-strcase careadlinkat close-stream crypto/md5 crypto/sha1 crypto/sha256 crypto/sha512 dtoastr dtotimespec dup2 environ execinfo faccessat fcntl-h fdatasync fdopendir filemode fstatat fsync getloadavg getopt-gnu gettime gettimeofday ignore-value intprops larg
efile lstat manywarnings memrchr mktime pselect pthread_sigmask putenv readlink readlinkat sig2str socklen stat-time stdalign stdarg stdbool stdio strftime strtoimax strtoumax symlink sys_stat sys_t
+
+
+MOSTLYCLEANFILES += core *.stackdump
+
+noinst_LIBRARIES += libgnu.a
+
+libgnu_a_SOURCES =
+libgnu_a_LIBADD = $(gl_LIBOBJS)
+libgnu_a_DEPENDENCIES = $(gl_LIBOBJS)
+EXTRA_libgnu_a_SOURCES =
+
+## begin gnulib module alloca-opt
+
+BUILT_SOURCES += $(ALLOCA_H)
+
+# We need the following in order to create <alloca.h> when the system
+# doesn't have one that works with the given compiler.
+if GL_GENERATE_ALLOCA_H
+alloca.h: alloca.in.h $(top_builddir)/config.status
+ $(AM_V_GEN)rm -f $@-t $@ && \
+ { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
+ cat $(srcdir)/alloca.in.h; \
+ } > $@-t && \
+ mv -f $@-t $@
+else
+alloca.h: $(top_builddir)/config.status
+ rm -f $@
+endif
+MOSTLYCLEANFILES += alloca.h alloca.h-t
+
+EXTRA_DIST += alloca.in.h
+
+## end gnulib module alloca-opt
+
+## begin gnulib module c-ctype
+
+libgnu_a_SOURCES += c-ctype.h c-ctype.c
+
+## end gnulib module c-ctype
+
+## begin gnulib module c-strcase
+
+libgnu_a_SOURCES += c-strcase.h c-strcasecmp.c c-strncasecmp.c
+
+## end gnulib module c-strcase
+
+## begin gnulib module close-stream
+
+libgnu_a_SOURCES += close-stream.c
+
+EXTRA_DIST += close-stream.h
+
+## end gnulib module close-stream
+
+## begin gnulib module crypto/md5
+
+libgnu_a_SOURCES += md5.c
+
+EXTRA_DIST += md5.h
+
+## end gnulib module crypto/md5
+
+## begin gnulib module crypto/sha1
+
+libgnu_a_SOURCES += sha1.c
+
+EXTRA_DIST += sha1.h
+
+## end gnulib module crypto/sha1
+
+## begin gnulib module crypto/sha256
+
+libgnu_a_SOURCES += sha256.c
+
+EXTRA_DIST += sha256.h
+
+## end gnulib module crypto/sha256
+
+## begin gnulib module crypto/sha512
+
+libgnu_a_SOURCES += sha512.c
+
+EXTRA_DIST += sha512.h
+
+## end gnulib module crypto/sha512
+
+## begin gnulib module dosname
+
+if gl_GNULIB_ENABLED_dosname
+
+endif
+EXTRA_DIST += dosname.h
+
+## end gnulib module dosname
+
+## begin gnulib module dtoastr
+
+libgnu_a_SOURCES += dtoastr.c
+
+EXTRA_DIST += ftoastr.c ftoastr.h
+
+EXTRA_libgnu_a_SOURCES += ftoastr.c
+
+## end gnulib module dtoastr
+
+## begin gnulib module dtotimespec
+
+libgnu_a_SOURCES += dtotimespec.c
+
+## end gnulib module dtotimespec
+
+## begin gnulib module dup2
+
+
+EXTRA_DIST += dup2.c
+
+EXTRA_libgnu_a_SOURCES += dup2.c
+
+## end gnulib module dup2
+
+## begin gnulib module euidaccess
+
+if gl_GNULIB_ENABLED_euidaccess
+
+endif
+EXTRA_DIST += euidaccess.c
+
+EXTRA_libgnu_a_SOURCES += euidaccess.c
+
+## end gnulib module euidaccess
+
+## begin gnulib module execinfo
+
+BUILT_SOURCES += $(EXECINFO_H)
+
+# We need the following in order to create <execinfo.h> when the system
+# doesn't have one that works.
+if GL_GENERATE_EXECINFO_H
+execinfo.h: execinfo.in.h $(top_builddir)/config.status
+ $(AM_V_GEN)rm -f $@-t $@ && \
+ { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
+ cat $(srcdir)/execinfo.in.h; \
+ } > $@-t && \
+ mv $@-t $@
+else
+execinfo.h: $(top_builddir)/config.status
+ rm -f $@
+endif
+MOSTLYCLEANFILES += execinfo.h execinfo.h-t
+
+EXTRA_DIST += execinfo.c execinfo.in.h
+
+EXTRA_libgnu_a_SOURCES += execinfo.c
+
+## end gnulib module execinfo
+
+## begin gnulib module faccessat
+
+
+EXTRA_DIST += at-func.c faccessat.c
+
+EXTRA_libgnu_a_SOURCES += at-func.c faccessat.c
+
+## end gnulib module faccessat
+
+## begin gnulib module fdatasync
+
+
+EXTRA_DIST += fdatasync.c
+
+EXTRA_libgnu_a_SOURCES += fdatasync.c
+
+## end gnulib module fdatasync
+
+## begin gnulib module fdopendir
+
+
+EXTRA_DIST += fdopendir.c
+
+EXTRA_libgnu_a_SOURCES += fdopendir.c
+
+## end gnulib module fdopendir
+
+## begin gnulib module filemode
+
+libgnu_a_SOURCES += filemode.c
+
+EXTRA_DIST += filemode.h
+
+## end gnulib module filemode
+
+## begin gnulib module fpending
+
+
+EXTRA_DIST += fpending.c fpending.h
+
+EXTRA_libgnu_a_SOURCES += fpending.c
+
+## end gnulib module fpending
+
+## begin gnulib module fstatat
+
+
+EXTRA_DIST += at-func.c fstatat.c
+
+EXTRA_libgnu_a_SOURCES += at-func.c fstatat.c
+
+## end gnulib module fstatat
+
+## begin gnulib module fsync
+
+
+EXTRA_DIST += fsync.c
+
+EXTRA_libgnu_a_SOURCES += fsync.c
+
+## end gnulib module fsync
+
+## begin gnulib module getgroups
+
+if gl_GNULIB_ENABLED_getgroups
+
+endif
+EXTRA_DIST += getgroups.c
+
+EXTRA_libgnu_a_SOURCES += getgroups.c
+
+## end gnulib module getgroups
+
+## begin gnulib module getloadavg
+
+
+EXTRA_DIST += getloadavg.c
+
+EXTRA_libgnu_a_SOURCES += getloadavg.c
+
+## end gnulib module getloadavg
+
+## begin gnulib module getopt-posix
+
+BUILT_SOURCES += $(GETOPT_H)
+
+# We need the following in order to create <getopt.h> when the system
+# doesn't have one that works with the given compiler.
+getopt.h: getopt.in.h $(top_builddir)/config.status $(ARG_NONNULL_H)
+ $(AM_V_GEN)rm -f $@-t $@ && \
+ { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
+ sed -e 's|@''GUARD_PREFIX''@|GL|g' \
+ -e 's|@''HAVE_GETOPT_H''@|$(HAVE_GETOPT_H)|g' \
+ -e 's|@''INCLUDE_NEXT''@|$(INCLUDE_NEXT)|g' \
+ -e 's|@''PRAGMA_SYSTEM_HEADER''@|@PRAGMA_SYSTEM_HEADER@|g' \
+ -e 's|@''PRAGMA_COLUMNS''@|@PRAGMA_COLUMNS@|g' \
+ -e 's|@''NEXT_GETOPT_H''@|$(NEXT_GETOPT_H)|g' \
+ -e '/definition of _GL_ARG_NONNULL/r $(ARG_NONNULL_H)' \
+ < $(srcdir)/getopt.in.h; \
+ } > $@-t && \
+ mv -f $@-t $@
+MOSTLYCLEANFILES += getopt.h getopt.h-t
+
+EXTRA_DIST += getopt.c getopt.in.h getopt1.c getopt_int.h
+
+EXTRA_libgnu_a_SOURCES += getopt.c getopt1.c
+
+## end gnulib module getopt-posix
+
+## begin gnulib module gettext-h
+
+if gl_GNULIB_ENABLED_be453cec5eecf5731a274f2de7f2db36
+libgnu_a_SOURCES += gettext.h
+
+endif
+## end gnulib module gettext-h
+
+## begin gnulib module gettime
+
+libgnu_a_SOURCES += gettime.c
+
+## end gnulib module gettime
+
+## begin gnulib module gettimeofday
+
+
+EXTRA_DIST += gettimeofday.c
+
+EXTRA_libgnu_a_SOURCES += gettimeofday.c
+
+## end gnulib module gettimeofday
+
+## begin gnulib module group-member
+
+if gl_GNULIB_ENABLED_a9786850e999ae65a836a6041e8e5ed1
+
+endif
+EXTRA_DIST += group-member.c
+
+EXTRA_libgnu_a_SOURCES += group-member.c
+
+## end gnulib module group-member
+
+## begin gnulib module ignore-value
+
+
+EXTRA_DIST += ignore-value.h
+
+## end gnulib module ignore-value
+
+## begin gnulib module intprops
+
+
+EXTRA_DIST += intprops.h
+
+## end gnulib module intprops
+
+## begin gnulib module lstat
+
+
+EXTRA_DIST += lstat.c
+
+EXTRA_libgnu_a_SOURCES += lstat.c
+
+## end gnulib module lstat
+
+## begin gnulib module memrchr
+
+
+EXTRA_DIST += memrchr.c
+
+EXTRA_libgnu_a_SOURCES += memrchr.c
+
+## end gnulib module memrchr
+
+## begin gnulib module mktime
+
+
+EXTRA_DIST += mktime-internal.h mktime.c
+
+EXTRA_libgnu_a_SOURCES += mktime.c
+
+## end gnulib module mktime
+
+## begin gnulib module openat-h
+
+if gl_GNULIB_ENABLED_03e0aaad4cb89ca757653bd367a6ccb7
+
+endif
+EXTRA_DIST += openat.h
+
+## end gnulib module openat-h
+
+## begin gnulib module pathmax
+
+if gl_GNULIB_ENABLED_pathmax
+
+endif
+EXTRA_DIST += pathmax.h
+
+## end gnulib module pathmax
+
+## begin gnulib module pselect
+
+
+EXTRA_DIST += pselect.c
+
+EXTRA_libgnu_a_SOURCES += pselect.c
+
+## end gnulib module pselect
+
+## begin gnulib module pthread_sigmask
+
+
+EXTRA_DIST += pthread_sigmask.c
+
+EXTRA_libgnu_a_SOURCES += pthread_sigmask.c
+
+## end gnulib module pthread_sigmask
+
+## begin gnulib module putenv
+
+
+EXTRA_DIST += putenv.c
+
+EXTRA_libgnu_a_SOURCES += putenv.c
+
+## end gnulib module putenv
+
+## begin gnulib module readlink
+
+
+EXTRA_DIST += readlink.c
+
+EXTRA_libgnu_a_SOURCES += readlink.c
+
+## end gnulib module readlink
+
+## begin gnulib module readlinkat
+
+
+EXTRA_DIST += at-func.c readlinkat.c
+
+EXTRA_libgnu_a_SOURCES += at-func.c readlinkat.c
+
+## end gnulib module readlinkat
+
+## begin gnulib module root-uid
+
+if gl_GNULIB_ENABLED_6099e9737f757db36c47fa9d9f02e88c
+
+endif
+EXTRA_DIST += root-uid.h
+
+## end gnulib module root-uid
+
+## begin gnulib module sig2str
+
+
+EXTRA_DIST += sig2str.c sig2str.h
+
+EXTRA_libgnu_a_SOURCES += sig2str.c
+
+## end gnulib module sig2str
+
+## begin gnulib module snippet/_Noreturn
+
+# Because this Makefile snippet defines a variable used by other
+# gnulib Makefile snippets, it must be present in all Makefile.am that
+# need it. This is ensured by the applicability 'all' defined above.
+
+_NORETURN_H=$(top_srcdir)/build-aux/snippet/_Noreturn.h
+
+EXTRA_DIST += $(top_srcdir)/build-aux/snippet/_Noreturn.h
+
+## end gnulib module snippet/_Noreturn
+
+## begin gnulib module snippet/arg-nonnull
+
+# The BUILT_SOURCES created by this Makefile snippet are not used via #include
+# statements but through direct file reference. Therefore this snippet must be
+# present in all Makefile.am that need it. This is ensured by the applicability
+# 'all' defined above.
+
+BUILT_SOURCES += arg-nonnull.h
+# The arg-nonnull.h that gets inserted into generated .h files is the same as
+# build-aux/snippet/arg-nonnull.h, except that it has the copyright header cut
+# off.
+arg-nonnull.h: $(top_srcdir)/build-aux/snippet/arg-nonnull.h
+ $(AM_V_GEN)rm -f $@-t $@ && \
+ sed -n -e '/GL_ARG_NONNULL/,$$p' \
+ < $(top_srcdir)/build-aux/snippet/arg-nonnull.h \
+ > $@-t && \
+ mv $@-t $@
+MOSTLYCLEANFILES += arg-nonnull.h arg-nonnull.h-t
+
+ARG_NONNULL_H=arg-nonnull.h
+
+EXTRA_DIST += $(top_srcdir)/build-aux/snippet/arg-nonnull.h
+
+## end gnulib module snippet/arg-nonnull
+
+## begin gnulib module snippet/c++defs
+
+# The BUILT_SOURCES created by this Makefile snippet are not used via #include
+# statements but through direct file reference. Therefore this snippet must be
+# present in all Makefile.am that need it. This is ensured by the applicability
+# 'all' defined above.
+
+BUILT_SOURCES += c++defs.h
+# The c++defs.h that gets inserted into generated .h files is the same as
+# build-aux/snippet/c++defs.h, except that it has the copyright header cut off.
+c++defs.h: $(top_srcdir)/build-aux/snippet/c++defs.h
+ $(AM_V_GEN)rm -f $@-t $@ && \
+ sed -n -e '/_GL_CXXDEFS/,$$p' \
+ < $(top_srcdir)/build-aux/snippet/c++defs.h \
+ > $@-t && \
+ mv $@-t $@
+MOSTLYCLEANFILES += c++defs.h c++defs.h-t
+
+CXXDEFS_H=c++defs.h
+
+EXTRA_DIST += $(top_srcdir)/build-aux/snippet/c++defs.h
+
+## end gnulib module snippet/c++defs
+
+## begin gnulib module snippet/warn-on-use
+
+BUILT_SOURCES += warn-on-use.h
+# The warn-on-use.h that gets inserted into generated .h files is the same as
+# build-aux/snippet/warn-on-use.h, except that it has the copyright header cut
+# off.
+warn-on-use.h: $(top_srcdir)/build-aux/snippet/warn-on-use.h
+ $(AM_V_GEN)rm -f $@-t $@ && \
+ sed -n -e '/^.ifndef/,$$p' \
+ < $(top_srcdir)/build-aux/snippet/warn-on-use.h \
+ > $@-t && \
+ mv $@-t $@
+MOSTLYCLEANFILES += warn-on-use.h warn-on-use.h-t
+
+WARN_ON_USE_H=warn-on-use.h
+
+EXTRA_DIST += $(top_srcdir)/build-aux/snippet/warn-on-use.h
+
+## end gnulib module snippet/warn-on-use
+
+## begin gnulib module stat
+
+if gl_GNULIB_ENABLED_stat
+
+endif
+EXTRA_DIST += stat.c
+
+EXTRA_libgnu_a_SOURCES += stat.c
+
+## end gnulib module stat
+
+## begin gnulib module stat-time
+
+libgnu_a_SOURCES += stat-time.c
+
+EXTRA_DIST += stat-time.h
+
+## end gnulib module stat-time
+
+## begin gnulib module stdalign
+
+BUILT_SOURCES += $(STDALIGN_H)
+
+# We need the following in order to create <stdalign.h> when the system
+# doesn't have one that works.
+if GL_GENERATE_STDALIGN_H
+stdalign.h: stdalign.in.h $(top_builddir)/config.status
+ $(AM_V_GEN)rm -f $@-t $@ && \
+ { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
+ cat $(srcdir)/stdalign.in.h; \
+ } > $@-t && \
+ mv $@-t $@
+else
+stdalign.h: $(top_builddir)/config.status
+ rm -f $@
+endif
+MOSTLYCLEANFILES += stdalign.h stdalign.h-t
+
+EXTRA_DIST += stdalign.in.h
+
+## end gnulib module stdalign
+
+## begin gnulib module stdarg
+
+BUILT_SOURCES += $(STDARG_H)
+
+# We need the following in order to create <stdarg.h> when the system
+# doesn't have one that works with the given compiler.
+if GL_GENERATE_STDARG_H
+stdarg.h: stdarg.in.h $(top_builddir)/config.status
+ $(AM_V_GEN)rm -f $@-t $@ && \
+ { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */' && \
+ sed -e 's|@''GUARD_PREFIX''@|GL|g' \
+ -e 's|@''INCLUDE_NEXT''@|$(INCLUDE_NEXT)|g' \
+ -e 's|@''PRAGMA_SYSTEM_HEADER''@|@PRAGMA_SYSTEM_HEADER@|g' \
+ -e 's|@''PRAGMA_COLUMNS''@|@PRAGMA_COLUMNS@|g' \
+ -e 's|@''NEXT_STDARG_H''@|$(NEXT_STDARG_H)|g' \
+ < $(srcdir)/stdarg.in.h; \
+ } > $@-t && \
+ mv $@-t $@
+else
+stdarg.h: $(top_builddir)/config.status
+ rm -f $@
+endif
+MOSTLYCLEANFILES += stdarg.h stdarg.h-t
+
+EXTRA_DIST += stdarg.in.h
+
+## end gnulib module stdarg
+
+## begin gnulib module stdbool
+
+BUILT_SOURCES += $(STDBOOL_H)
+
+# We need the following in order to create <stdbool.h> when the system
+# doesn't have one that works.
+if GL_GENERATE_STDBOOL_H
+stdbool.h: stdbool.in.h $(top_builddir)/config.status
+ $(AM_V_GEN)rm -f $@-t $@ && \
+ { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
+ sed -e 's/@''HAVE__BOOL''@/$(HAVE__BOOL)/g' < $(srcdir)/stdbool.in.h; \
+ } > $@-t && \
+ mv $@-t $@
+else
+stdbool.h: $(top_builddir)/config.status
+ rm -f $@
+endif
+MOSTLYCLEANFILES += stdbool.h stdbool.h-t
+
+EXTRA_DIST += stdbool.in.h
+
+## end gnulib module stdbool
+
+## begin gnulib module stddef
+
+BUILT_SOURCES += $(STDDEF_H)
+
+# We need the following in order to create <stddef.h> when the system
+# doesn't have one that works with the given compiler.
+if GL_GENERATE_STDDEF_H
+stddef.h: stddef.in.h $(top_builddir)/config.status
+ $(AM_V_GEN)rm -f $@-t $@ && \
+ { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */' && \
+ sed -e 's|@''GUARD_PREFIX''@|GL|g' \
+ -e 's|@''INCLUDE_NEXT''@|$(INCLUDE_NEXT)|g' \
+ -e 's|@''PRAGMA_SYSTEM_HEADER''@|@PRAGMA_SYSTEM_HEADER@|g' \
+ -e 's|@''PRAGMA_COLUMNS''@|@PRAGMA_COLUMNS@|g' \
+ -e 's|@''NEXT_STDDEF_H''@|$(NEXT_STDDEF_H)|g' \
+ -e 's|@''HAVE_WCHAR_T''@|$(HAVE_WCHAR_T)|g' \
+ -e 's|@''REPLACE_NULL''@|$(REPLACE_NULL)|g' \
+ < $(srcdir)/stddef.in.h; \
+ } > $@-t && \
+ mv $@-t $@
+else
+stddef.h: $(top_builddir)/config.status
+ rm -f $@
+endif
+MOSTLYCLEANFILES += stddef.h stddef.h-t
+
+EXTRA_DIST += stddef.in.h
+
+## end gnulib module stddef
+
+## begin gnulib module stdint
+
+BUILT_SOURCES += $(STDINT_H)
+
+# We need the following in order to create <stdint.h> when the system
+# doesn't have one that works with the given compiler.
+if GL_GENERATE_STDINT_H
+stdint.h: stdint.in.h $(top_builddir)/config.status
+ $(AM_V_GEN)rm -f $@-t $@ && \
+ { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
+ sed -e 's|@''GUARD_PREFIX''@|GL|g' \
+ -e 's/@''HAVE_STDINT_H''@/$(HAVE_STDINT_H)/g' \
+ -e 's|@''INCLUDE_NEXT''@|$(INCLUDE_NEXT)|g' \
+ -e 's|@''PRAGMA_SYSTEM_HEADER''@|@PRAGMA_SYSTEM_HEADER@|g' \
+ -e 's|@''PRAGMA_COLUMNS''@|@PRAGMA_COLUMNS@|g' \
+ -e 's|@''NEXT_STDINT_H''@|$(NEXT_STDINT_H)|g' \
+ -e 's/@''HAVE_SYS_TYPES_H''@/$(HAVE_SYS_TYPES_H)/g' \
+ -e 's/@''HAVE_INTTYPES_H''@/$(HAVE_INTTYPES_H)/g' \
+ -e 's/@''HAVE_SYS_INTTYPES_H''@/$(HAVE_SYS_INTTYPES_H)/g' \
+ -e 's/@''HAVE_SYS_BITYPES_H''@/$(HAVE_SYS_BITYPES_H)/g' \
+ -e 's/@''HAVE_WCHAR_H''@/$(HAVE_WCHAR_H)/g' \
+ -e 's/@''HAVE_LONG_LONG_INT''@/$(HAVE_LONG_LONG_INT)/g' \
+ -e 's/@''HAVE_UNSIGNED_LONG_LONG_INT''@/$(HAVE_UNSIGNED_LONG_LONG_INT)/g' \
+ -e 's/@''APPLE_UNIVERSAL_BUILD''@/$(APPLE_UNIVERSAL_BUILD)/g' \
+ -e 's/@''BITSIZEOF_PTRDIFF_T''@/$(BITSIZEOF_PTRDIFF_T)/g' \
+ -e 's/@''PTRDIFF_T_SUFFIX''@/$(PTRDIFF_T_SUFFIX)/g' \
+ -e 's/@''BITSIZEOF_SIG_ATOMIC_T''@/$(BITSIZEOF_SIG_ATOMIC_T)/g' \
+ -e 's/@''HAVE_SIGNED_SIG_ATOMIC_T''@/$(HAVE_SIGNED_SIG_ATOMIC_T)/g' \
+ -e 's/@''SIG_ATOMIC_T_SUFFIX''@/$(SIG_ATOMIC_T_SUFFIX)/g' \
+ -e 's/@''BITSIZEOF_SIZE_T''@/$(BITSIZEOF_SIZE_T)/g' \
+ -e 's/@''SIZE_T_SUFFIX''@/$(SIZE_T_SUFFIX)/g' \
+ -e 's/@''BITSIZEOF_WCHAR_T''@/$(BITSIZEOF_WCHAR_T)/g' \
+ -e 's/@''HAVE_SIGNED_WCHAR_T''@/$(HAVE_SIGNED_WCHAR_T)/g' \
+ -e 's/@''WCHAR_T_SUFFIX''@/$(WCHAR_T_SUFFIX)/g' \
+ -e 's/@''BITSIZEOF_WINT_T''@/$(BITSIZEOF_WINT_T)/g' \
+ -e 's/@''HAVE_SIGNED_WINT_T''@/$(HAVE_SIGNED_WINT_T)/g' \
+ -e 's/@''WINT_T_SUFFIX''@/$(WINT_T_SUFFIX)/g' \
+ < $(srcdir)/stdint.in.h; \
+ } > $@-t && \
+ mv $@-t $@
+else
+stdint.h: $(top_builddir)/config.status
+ rm -f $@
+endif
+MOSTLYCLEANFILES += stdint.h stdint.h-t
+
+EXTRA_DIST += stdint.in.h
+
+## end gnulib module stdint
+
+## begin gnulib module strftime
+
+libgnu_a_SOURCES += strftime.c
+
+EXTRA_DIST += strftime.h
+
+## end gnulib module strftime
+
+## begin gnulib module strtoimax
+
+
+EXTRA_DIST += strtoimax.c
+
+EXTRA_libgnu_a_SOURCES += strtoimax.c
+
+## end gnulib module strtoimax
+
+## begin gnulib module strtoll
+
+if gl_GNULIB_ENABLED_strtoll
+
+endif
+EXTRA_DIST += strtol.c strtoll.c
+
+EXTRA_libgnu_a_SOURCES += strtol.c strtoll.c
+
+## end gnulib module strtoll
+
+## begin gnulib module strtoull
+
+if gl_GNULIB_ENABLED_strtoull
+
+endif
+EXTRA_DIST += strtol.c strtoul.c strtoull.c
+
+EXTRA_libgnu_a_SOURCES += strtol.c strtoul.c strtoull.c
+
+## end gnulib module strtoull
+
+## begin gnulib module strtoumax
+
+
+EXTRA_DIST += strtoimax.c strtoumax.c
+
+EXTRA_libgnu_a_SOURCES += strtoimax.c strtoumax.c
+
+## end gnulib module strtoumax
+
+## begin gnulib module symlink
+
+
+EXTRA_DIST += symlink.c
+
+EXTRA_libgnu_a_SOURCES += symlink.c
+
+## end gnulib module symlink
+
+## begin gnulib module time_r
+
+
+EXTRA_DIST += time_r.c
+
+EXTRA_libgnu_a_SOURCES += time_r.c
+
+## end gnulib module time_r
+
+## begin gnulib module timespec
+
+libgnu_a_SOURCES += timespec.c
+
+EXTRA_DIST += timespec.h
+
+## end gnulib module timespec
+
+## begin gnulib module timespec-add
+
+libgnu_a_SOURCES += timespec-add.c
+
+## end gnulib module timespec-add
+
+## begin gnulib module timespec-sub
+
+libgnu_a_SOURCES += timespec-sub.c
+
+## end gnulib module timespec-sub
+
+## begin gnulib module u64
+
+libgnu_a_SOURCES += u64.c
+
+EXTRA_DIST += u64.h
+
+## end gnulib module u64
+
+## begin gnulib module unsetenv
+
+
+EXTRA_DIST += unsetenv.c
+
+EXTRA_libgnu_a_SOURCES += unsetenv.c
+
+## end gnulib module unsetenv
+
+## begin gnulib module utimens
+
+libgnu_a_SOURCES += utimens.c
+
+EXTRA_DIST += utimens.h
+
+## end gnulib module utimens
+
+## begin gnulib module verify
+
+if gl_GNULIB_ENABLED_verify
+
+endif
+EXTRA_DIST += verify.h
+
+## end gnulib module verify
+
+## begin gnulib module xalloc-oversized
+
+if gl_GNULIB_ENABLED_682e609604ccaac6be382e4ee3a4eaec
+
+endif
+EXTRA_DIST += xalloc-oversized.h
+
+## end gnulib module xalloc-oversized
+
+
+mostlyclean-local: mostlyclean-generic
+ @for dir in '' $(MOSTLYCLEANDIRS); do \
+ if test -n "$$dir" && test -d $$dir; then \
+ echo "rmdir $$dir"; rmdir $$dir; \
+ fi; \
+ done; \
+ :
=== modified file 'nt/inc/ms-w32.h'
--- nt/inc/ms-w32.h 2013-03-30 07:10:58 +0000
+++ nt/inc/ms-w32.h 2013-04-01 15:48:30 +0000
@@ -67,7 +67,9 @@ along with GNU Emacs. If not, see <http
#endif
#if (__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 8))
-#define HAVE___BUILTIN_UNWIND_INIT 1
+# ifndef HAVE___BUILTIN_UNWIND_INIT
+# define HAVE___BUILTIN_UNWIND_INIT 1
+# endif
#endif
/* This isn't perfect, as some systems might have the page file in
@@ -99,8 +101,12 @@ along with GNU Emacs. If not, see <http
#endif
#ifdef __GNUC__
-# define restrict __restrict__
+/* config.h may have defined already. */
+# ifndef restrict
+# define restrict __restrict__
+# endif
#else
+ /* FIXME: should we define to __restrict, which MSVC supports? */
# define restrict
#endif
@@ -138,9 +144,6 @@ extern char *getenv ();
/* Make a leaner executable. */
#define WIN32_LEAN_AND_MEAN 1
-#ifdef HAVE_STRINGS_H
-#include "strings.h"
-#endif
#include <sys/types.h>
#ifndef MAXPATHLEN
@@ -148,8 +151,12 @@ extern char *getenv ();
#endif
#ifdef HAVE_NTGUI
-#define HAVE_WINDOW_SYSTEM 1
-#define HAVE_MENUS 1
+# ifndef HAVE_WINDOW_SYSTEM
+# define HAVE_WINDOW_SYSTEM 1
+# endif
+# ifndef HAVE_MENUS
+# define HAVE_MENUS 1
+# endif
#endif
/* Get some redefinitions in place. */
@@ -248,9 +255,6 @@ extern int sys_unlink (const char *);
#define execvp _execvp
#define fdatasync _commit
#define fdopen _fdopen
-#ifndef fileno
-#define fileno _fileno
-#endif
#define fsync _commit
#define ftruncate _chsize
#define getpid _getpid
@@ -266,9 +270,6 @@ typedef int pid_t;
#define popen _popen
#define pclose _pclose
#define umask _umask
-#ifndef _MSC_VER
-#define utimbuf _utimbuf
-#endif
#define strdup _strdup
#define strupr _strupr
#define strnicmp _strnicmp
@@ -285,10 +286,6 @@ int _getpid (void);
array, and triggers an error message. */
#include <time.h>
#define tzname _tzname
-#if !defined (_MSC_VER) || (_MSC_VER < 1400)
-#undef utime
-#define utime _utime
-#endif
/* 'struct timespec' is used by time-related functions in lib/ and
elsewhere, but we don't use lib/time.h where the structure is
@@ -327,6 +324,9 @@ extern struct tm *localtime_r (time_t co
#include <io.h>
#include <stdio.h>
#endif /* !_MSC_VER */
+#ifndef fileno
+#define fileno _fileno
+#endif
/* Defines that we need that aren't in the standard signal.h. */
#define SIGHUP 1 /* Hang up */
@@ -351,9 +351,11 @@ typedef int sigset_t;
typedef int ssize_t;
#endif
-#ifndef _POSIX /* MinGW64 */
+#ifdef _W64 /* MinGW64 */
+#ifndef _POSIX
typedef _sigset_t sigset_t;
#endif
+#endif
typedef void (_CALLBACK_ *signal_handler) (int);
extern signal_handler sys_signal (int, signal_handler);
@@ -389,10 +391,12 @@ extern int sys_kill (int, int);
#define getdefdir(_drv, _buf) _getdcwd (_drv, _buf, MAXPATHLEN)
#endif
+#ifndef EMACS_CONFIGURATION
extern char *get_emacs_configuration (void);
extern char *get_emacs_configuration_options (void);
#define EMACS_CONFIGURATION get_emacs_configuration ()
#define EMACS_CONFIG_OPTIONS get_emacs_configuration_options ()
+#endif
/* Define this so that winsock.h definitions don't get included with
windows.h. For this to have proper effect, config.h must always be
@@ -446,10 +450,14 @@ extern void * memrchr (void const *, int
#if defined (__MINGW32__)
/* Define to 1 if the system has the type `long long int'. */
-# define HAVE_LONG_LONG_INT 1
+# ifndef HAVE_LONG_LONG_INT
+# define HAVE_LONG_LONG_INT 1
+# endif
/* Define to 1 if the system has the type `unsigned long long int'. */
-# define HAVE_UNSIGNED_LONG_LONG_INT 1
+# ifndef HAVE_UNSIGNED_LONG_LONG_INT
+# define HAVE_UNSIGNED_LONG_LONG_INT 1
+# endif
#endif
=== modified file 'nt/inc/sys/socket.h'
--- nt/inc/sys/socket.h 2013-01-02 16:13:04 +0000
+++ nt/inc/sys/socket.h 2013-03-28 17:59:23 +0000
@@ -43,8 +43,9 @@ along with GNU Emacs. If not, see <http
#undef FD_ZERO
#endif
-/* avoid duplicate definition of timeval */
-#ifdef HAVE_TIMEVAL
+/* Avoid duplicate definition of timeval. MinGW uses _TIMEVAL_DEFINED
+ in sys/time.h to avoid that. */
+#if defined (HAVE_TIMEVAL) && defined (_MSC_VER)
#define timeval ws_timeval
#endif
@@ -62,7 +63,9 @@ typedef unsigned short uint16_t;
#undef MUST_REDEF_SELECT
#endif
-/* revert to our version of FD_SET */
+/* Revert to our version of FD_SET, but not when included from test
+ programs run by configure. */
+#ifdef EMACS_CONFIG_H
#undef FD_SET
#undef FD_CLR
#undef FD_ISSET
@@ -71,8 +74,9 @@ typedef unsigned short uint16_t;
/* allow us to provide our own version of fd_set */
#define fd_set ws_fd_set
#include "w32.h"
+#endif /* EMACS_CONFIG_H */
-#ifdef HAVE_TIMEVAL
+#if defined (HAVE_TIMEVAL) && defined (_MSC_VER)
#undef timeval
#endif
=== modified file 'nt/inc/sys/stat.h'
--- nt/inc/sys/stat.h 2013-03-26 13:45:01 +0000
+++ nt/inc/sys/stat.h 2013-04-01 15:22:31 +0000
@@ -83,6 +83,9 @@ along with GNU Emacs. If not, see <http
#define S_TYPEISSHM(p) 0
#define S_TYPEISTMO(p) 0
+#define UTIME_NOW (-1)
+#define UTIME_OMIT (-2)
+
struct stat {
unsigned __int64 st_ino; /* ino_t in sys/types.h is too narrow */
dev_t st_dev;
@@ -99,6 +102,39 @@ struct stat {
char st_gname[260];
};
+/* These are here to avoid compiler warnings when using wchar.h. */
+struct _stat
+{
+ _dev_t st_dev; /* Equivalent to drive number 0=A 1=B ... */
+ _ino_t st_ino; /* Always zero ? */
+ _mode_t st_mode; /* See above constants */
+ short st_nlink; /* Number of links. */
+ short st_uid; /* User: Maybe significant on NT ? */
+ short st_gid; /* Group: Ditto */
+ _dev_t st_rdev; /* Seems useless (not even filled in) */
+ _off_t st_size; /* File size in bytes */
+ time_t st_atime; /* Accessed date (always 00:00 hrs local
+ * on FAT) */
+ time_t st_mtime; /* Modified time */
+ time_t st_ctime; /* Creation time */
+};
+
+#if defined (__MSVCRT__)
+struct _stati64 {
+ _dev_t st_dev;
+ _ino_t st_ino;
+ _mode_t st_mode;
+ short st_nlink;
+ short st_uid;
+ short st_gid;
+ _dev_t st_rdev;
+ __int64 st_size;
+ time_t st_atime;
+ time_t st_mtime;
+ time_t st_ctime;
+};
+#endif
+
/* Internal variable for asking 'stat'/'lstat' to produce accurate
info about owner and group of files. */
extern int w32_stat_get_owner_group;
=== modified file 'nt/inc/sys/time.h'
--- nt/inc/sys/time.h 2013-03-26 08:21:27 +0000
+++ nt/inc/sys/time.h 2013-03-28 20:38:01 +0000
@@ -9,12 +9,23 @@
/* The guards are for MinGW64, which defines these structs on its
system headers which are included by ms-w32.h. */
#ifndef _W64
+/* Allow inclusion of sys/time.h and winsock2.h in any order. Needed
+ for running the configure test, which is only relevant to MinGW. */
+#ifndef _TIMEVAL_DEFINED
+#define _TIMEVAL_DEFINED
struct timeval
{
long tv_sec; /* seconds */
long tv_usec; /* microseconds */
};
-#endif
+#define timerisset(tvp) ((tvp)->tv_sec || (tvp)->tv_usec)
+#define timercmp(tvp, uvp, cmp) \
+ (((tvp)->tv_sec != (uvp)->tv_sec) ? \
+ ((tvp)->tv_sec cmp (uvp)->tv_sec) : \
+ ((tvp)->tv_usec cmp (uvp)->tv_usec))
+#define timerclear(tvp) (tvp)->tv_sec = (tvp)->tv_usec = 0
+#endif /* _TIMEVAL_DEFINED */
+#endif /* _W64 */
#ifndef _TIMEZONE_DEFINED
struct timezone
@@ -24,7 +35,10 @@ struct timezone
};
#endif
-void gettimeofday (struct timeval *, struct timezone *);
+/* This needs to be compatible with Posix signature, in order to pass
+ the configure test for the type of the second argument. See
+ m4/gettimeofday.m4. */
+int gettimeofday (struct timeval *restrict, struct timezone *restrict);
#define ITIMER_REAL 0
#define ITIMER_PROF 1
=== modified file 'nt/inc/unistd.h'
--- nt/inc/unistd.h 2013-03-05 22:35:41 +0000
+++ nt/inc/unistd.h 2013-03-28 17:59:23 +0000
@@ -3,6 +3,9 @@
#ifndef _UNISTD_H
#define _UNISTD_H
+#include <sys/types.h>
+#include <pwd.h>
+
/* On Microsoft platforms, <stdlib.h> declares 'environ'; on POSIX
platforms, <unistd.h> does. Every file in Emacs that includes
<unistd.h> also includes <stdlib.h>, so there's no need to declare
=== modified file 'nt/makefile.w32-in'
--- nt/makefile.w32-in 2013-03-27 10:09:44 +0000
+++ nt/makefile.w32-in 2013-04-15 13:37:10 +0000
@@ -29,6 +29,8 @@ TMP_DIST_DIR = emacs-$(VERSION)
TRES = $(BLD)/emacs.res
CLIENTRES = $(BLD)/emacsclient.res
+LOCAL_FLAGS = -DOLD_PATHS=1
+
XMFLAGS =
ALL = $(BLD)/addpm.exe $(BLD)/ddeclient.exe $(BLD)/runemacs.exe \
=== added file 'nt/mingw-cfg.site'
--- nt/mingw-cfg.site 1970-01-01 00:00:00 +0000
+++ nt/mingw-cfg.site 2013-03-30 09:38:23 +0000
@@ -0,0 +1,74 @@
+#! /bin/sh
+# Site defaults for the MinGW configuration of GNU Emacs.
+
+# We want to use getopt.h from gnulib
+ac_cv_header_getopt_h=no
+
+# Implemented in w32.c
+ac_cv_func_acl_set_file=yes
+# Autoconf's test program is not smart enough, and fails to detect gethostname
+ac_cv_func_gethostname=yes
+# Implemented as sys_select in w32proc.c
+ac_cv_func_select=yes
+ac_cv_func_pselect=yes
+gl_cv_sig_pselect=yes
+gl_cv_func_pselect_detects_ebadf=yes
+# Implemented as sys_shutdown in w32.c
+ac_cv_func_shutdown=yes
+# Implemented in w32proc.c
+ac_cv_func_setitimer=yes
+# Implemented as sys_sendto in w32.c
+ac_cv_func_sendto=yes
+# Implemented as sys_recvfrom in w32.c
+ac_cv_func_recvfrom=yes
+# Implemented as sys_getsockname in w32.c
+ac_cv_func_getsockname=yes
+# Implemented as sys_getpeername in w32.c
+ac_cv_func_getpeername=yes
+# Implemented as sys_socket in w32.c
+ac_cv_func_socket=yes
+# Implemented in w32.c
+ac_cv_func_readlink=yes
+ac_cv_func_symlink=yes
+# Avoid run-time tests of readlink and symlink, which will fail
+gl_cv_func_readlink_works=yes
+gl_cv_func_symlink_works=yes
+ac_cv_func_readlinkat=yes
+ac_cv_func_faccessat=yes
+# We don't need fdopendir
+ac_cv_func_fdopendir="not-needed"
+gl_cv_func_fdopendir_works="no-but-not-needed-so-yes"
+# Implemented in w32.c
+ac_cv_func_lstat=yes
+gl_cv_func_lstat_dereferences_slashed_symlink=yes
+ac_cv_func_fstatat=yes
+gl_cv_func_fstatat_zero_flag=yes
+# Aliased to _commit in ms-w32.h
+ac_cv_func_fsync=yes
+ac_cv_func_fdatasync=yes
+# Implemented in w32proc.c
+ac_cv_func_pthread_sigmask=yes
+# Avoid gnulib replacement
+gl_threads_api=posix
+gl_cv_func_pthread_sigmask_return_works=yes
+gl_cv_func_pthread_sigmask_unblock_works="not relevant"
+# Implemented in w32proc.c
+emacs_cv_langinfo_codeset=yes
+# Declared in ms-w32.h
+ac_cv_have_decl_alarm=yes
+# Avoid including the gnulib dup2 module
+gl_cv_func_dup2_works=yes
+# Defined in w32.c
+ac_cv_func_getloadavg=yes
+# Avoid compiling gnulib mktime
+gl_cv_func_working_mktime=yes
+# Implemented in w32.c
+ac_cv_have_decl_unsetenv=yes
+ac_cv_func_unsetenv=yes
+gt_cv_func_unsetenv_ret='int'
+gl_cv_func_unsetenv_works=yes
+gl_cv_func_stat_dir_slash=yes
+gl_cv_func_stat_file_slash=yes
+ac_cv_func_random=yes
+# Implemented in w32.c as sys_putenv
+gl_cv_func_svid_putenv=yes
=== added file 'nt/msysconfig.sh'
--- nt/msysconfig.sh 1970-01-01 00:00:00 +0000
+++ nt/msysconfig.sh 2013-04-15 14:56:28 +0000
@@ -0,0 +1,39 @@
+#! /bin/sh
+### msysconfig.sh - Run the top-level 'configure' script as approriate
+### for the MinGW/MSYS build of a native MS-Windows port of Emacs.
+
+## Copyright (C) 2013 Free Software Foundation, Inc.
+
+## Author: Eli Zaretskii <eliz@gnu.org>
+
+## This file is part of GNU Emacs.
+
+## GNU Emacs is free software: you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation, either version 3 of the License, or
+## (at your option) any later version.
+
+## GNU Emacs is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+## GNU General Public License for more details.
+
+## You should have received a copy of the GNU General Public License
+## along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>.
+
+### Commentary:
+
+## The Posix 'configure' script needs a few tweaks to produce desired
+## results when running under MSYS with the purpose of configuring
+## Emacs for the MinGW MS-Windows build. Rather than asking users to
+## type these tweaks every time they configure the package, we provide
+## this helper scripts which takes care of the mundane things.
+
+### Code:
+
+srcdir=`dirname "$0"`
+parent=`dirname "$srcdir"`
+
+## The nt/mingw-cfg.site file provides various autoconf variables that
+## are needed for a successful MinGW build.
+CONFIG_SITE="$srcdir/mingw-cfg.site" $parent/configure "$@"
=== modified file 'src/Makefile.in'
--- src/Makefile.in 2013-04-07 06:21:40 +0000
+++ src/Makefile.in 2013-04-14 17:24:40 +0000
@@ -260,10 +260,13 @@ W32_OBJ=@W32_OBJ@
W32_LIBS=@W32_LIBS@
## emacs.res if HAVE_W32
-W32_RES=@W32_RES@
+EMACSRES = @EMACSRES@
+## emacs-*.manifest if HAVE_W32
+EMACS_MANIFEST = @EMACS_MANIFEST@
## If HAVE_W32, compiler arguments for including
## the resource file in the binary.
-## XXX -Wl,-b -Wl,pe-i386 -Wl,emacs.res
+## Cygwin: -Wl,emacs.res
+## MinGW: emacs.res
W32_RES_LINK=@W32_RES_LINK@
## Empty if !HAVE_X_WINDOWS
@@ -272,6 +275,9 @@ W32_RES_LINK=@W32_RES_LINK@
## else xfont.o
FONT_OBJ=@FONT_OBJ@
+## Empty for MinGW, cm.o for the rest.
+CM_OBJ=@CM_OBJ@
+
LIBGPM = @LIBGPM@
## -lresolv, or empty.
@@ -292,6 +298,14 @@ GETLOADAVG_LIBS = @GETLOADAVG_LIBS@
RUN_TEMACS = `/bin/pwd`/temacs
+## Invoke ../nt/addsection for MinGW, ":" elsewhere.
+TEMACS_POST_LINK = @TEMACS_POST_LINK@
+ADDSECTION = @ADDSECTION@
+EMACS_HEAPSIZE = @EMACS_HEAPSIZE@
+MINGW_TEMACS_POST_LINK = \
+ mv temacs$(EXEEXT) temacs.tmp; \
+ ../nt/addsection temacs.tmp temacs$(EXEEXT) EMHEAP $(EMACS_HEAPSIZE)
+
UNEXEC_OBJ = @UNEXEC_OBJ@
CANNOT_DUMP=@CANNOT_DUMP@
@@ -334,7 +348,7 @@ ALL_OBJC_CFLAGS=$(ALL_CFLAGS) $(GNU_OBJC
## be dumped as pure by dump-emacs.
base_obj = dispnew.o frame.o scroll.o xdisp.o menu.o $(XMENU_OBJ) window.o \
charset.o coding.o category.o ccl.o character.o chartab.o bidi.o \
- cm.o term.o terminal.o xfaces.o $(XOBJ) $(GTK_OBJ) $(DBUS_OBJ) \
+ $(CM_OBJ) term.o terminal.o xfaces.o $(XOBJ) $(GTK_OBJ) $(DBUS_OBJ) \
emacs.o keyboard.o macros.o keymap.o sysdep.o \
buffer.o filelock.o insdel.o marker.o \
minibuf.o fileio.o dired.o \
@@ -372,9 +386,9 @@ VMLIMIT_OBJ=@VMLIMIT_OBJ@
## ralloc.o if !SYSTEM_MALLOC && REL_ALLOC, else empty.
RALLOC_OBJ=@RALLOC_OBJ@
-## Empty on Cygwin, lastfile.o elsewhere.
+## Empty on Cygwin and MinGW, lastfile.o elsewhere.
PRE_ALLOC_OBJ=@PRE_ALLOC_OBJ@
-## lastfile.o on Cygwin, empty elsewhere.
+## lastfile.o on Cygwin and MinGW, empty elsewhere.
POST_ALLOC_OBJ=@POST_ALLOC_OBJ@
## List of object files that make-docfile should not be told about.
@@ -382,7 +396,9 @@ otherobj= $(TERMCAP_OBJ) $(PRE_ALLOC_OBJ
$(POST_ALLOC_OBJ) $(WIDGET_OBJ) $(LIBOBJS)
## All object files linked into temacs. $(VMLIMIT_OBJ) should be first.
-ALLOBJS = $(VMLIMIT_OBJ) $(obj) $(otherobj)
+## (On MinGW, firstfile.o should be before vm-limit.o.)
+FIRSTFILE_OBJ=@FIRSTFILE_OBJ@
+ALLOBJS = $(FIRSTFILE_OBJ) $(VMLIMIT_OBJ) $(obj) $(otherobj)
## Configure inserts the file lisp.mk at this point, defining $lisp.
@lisp_frag@
@@ -411,7 +427,8 @@ $(leimdir)/leim-list.el: bootstrap-emacs
## Strictly speaking, emacs does not depend directly on all of $lisp,
## since not all pieces are used on all platforms. But DOC depends
## on all of $lisp, and emacs depends on DOC, so it is ok to use $lisp here.
-emacs$(EXEEXT): temacs$(EXEEXT) $(etc)/DOC $(lisp) $(leimdir)/leim-list.el
+emacs$(EXEEXT): temacs$(EXEEXT) $(ADDSECTION) \
+ $(etc)/DOC $(lisp) $(leimdir)/leim-list.el
if test "$(CANNOT_DUMP)" = "yes"; then \
rm -f emacs$(EXEEXT); \
ln temacs$(EXEEXT) emacs$(EXEEXT); \
@@ -463,10 +480,10 @@ $(lib)/libgnu.a: $(config_h)
cd $(lib) && $(MAKE) libgnu.a
temacs$(EXEEXT): stamp-oldxmenu $(ALLOBJS) \
- $(lib)/libgnu.a $(W32_RES)
+ $(lib)/libgnu.a $(EMACSRES)
$(CC) $(ALL_CFLAGS) $(TEMACS_LDFLAGS) $(LDFLAGS) \
- -o temacs $(ALLOBJS) $(lib)/libgnu.a $(LIBES) \
- $(W32_RES_LINK)
+ -o temacs $(ALLOBJS) $(lib)/libgnu.a $(W32_RES_LINK) $(LIBES)
+ $(TEMACS_POST_LINK)
test "$(CANNOT_DUMP)" = "yes" || \
test "X$(PAXCTL)" = X || $(PAXCTL) -r temacs$(EXEEXT)
@@ -509,8 +526,9 @@ doc.o: buildobj.h
emacs.res: $(ntsource)/emacs.rc \
$(ntsource)/icons/emacs.ico \
- $(ntsource)/emacs-x86.manifest
- $(WINDRES) -O COFF -o $@ $(ntsource)/emacs.rc
+ $(ntsource)/$(EMACS_MANIFEST)
+ $(WINDRES) -O COFF --include-dir=$(srcdir)/../nt \
+ -o $@ $(ntsource)/emacs.rc
ns-app: emacs$(EXEEXT)
cd ../nextstep && $(MAKE) $(MFLAGS) all
=== modified file 'src/unexw32.c'
--- src/unexw32.c 2013-02-02 17:14:24 +0000
+++ src/unexw32.c 2013-04-16 18:06:02 +0000
@@ -159,6 +159,14 @@ open_output_file (file_data *p_file, cha
HANDLE file_mapping;
void *file_base;
+ /* We delete any existing FILENAME because loadup.el will create a
+ hard link to it under the name emacs-XX.YY.ZZ.nn.exe. Evidently,
+ overwriting a file on Unix breaks any hard links to it, but that
+ doesn't happen on Windows. If we don't delete the file before
+ creating it, all the emacs-XX.YY.ZZ.nn.exe end up being hard
+ links to the same file, which defeats the purpose of these hard
+ links: being able to run previous builds. */
+ DeleteFile (filename);
file = CreateFile (filename, GENERIC_READ | GENERIC_WRITE, 0, NULL,
CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0);
if (file == INVALID_HANDLE_VALUE)
=== modified file 'src/w32.c'
--- src/w32.c 2013-03-27 12:01:31 +0000
+++ src/w32.c 2013-04-15 12:53:59 +0000
@@ -65,6 +65,7 @@ along with GNU Emacs. If not, see <http
#undef localtime
#include "lisp.h"
+#include "epaths.h" /* for SHELL */
#include <pwd.h>
#include <grp.h>
@@ -2018,7 +2019,7 @@ init_environment (char ** argv)
{"PRELOAD_WINSOCK", NULL},
{"emacs_dir", "C:/emacs"},
{"EMACSLOADPATH", NULL},
- {"SHELL", "%emacs_dir%/bin/cmdproxy.exe"},
+ {"SHELL", "cmdproxy.exe"}, /* perhaps it is somewhere on PATH */
{"EMACSDATA", NULL},
{"EMACSPATH", NULL},
{"INFOPATH", NULL},
@@ -2094,9 +2095,12 @@ init_environment (char ** argv)
emacs_abort ();
*p = 0;
- if ((p = _mbsrchr (modname, '\\')) && xstrcasecmp (p, "\\bin") == 0)
+ if ((p = _mbsrchr (modname, '\\'))
+ /* From bin means installed Emacs, from src means uninstalled. */
+ && (xstrcasecmp (p, "\\bin") == 0 || xstrcasecmp (p, "\\src") == 0))
{
char buf[SET_ENV_BUF_SIZE];
+ int within_build_tree = xstrcasecmp (p, "\\src") == 0;
*p = 0;
for (p = modname; *p; p = CharNext (p))
@@ -2104,6 +2108,15 @@ init_environment (char ** argv)
_snprintf (buf, sizeof (buf)-1, "emacs_dir=%s", modname);
_putenv (strdup (buf));
+ /* If we are running from the Posix-like build tree, define
+ SHELL to point to our own cmdproxy. The loop below will
+ then disregard PATH_EXEC and the default value. */
+ if (within_build_tree)
+ {
+ _snprintf (buf, sizeof (buf) - 1,
+ "SHELL=%s/nt/cmdproxy.exe", modname);
+ _putenv (strdup (buf));
+ }
}
/* Handle running emacs from the build directory: src/oo-spd/i386/ */
@@ -2139,16 +2152,60 @@ init_environment (char ** argv)
if (!getenv (env_vars[i].name))
{
int dont_free = 0;
+ char bufc[SET_ENV_BUF_SIZE];
if ((lpval = w32_get_resource (env_vars[i].name, &dwType)) == NULL
/* Also ignore empty environment variables. */
|| *lpval == 0)
{
xfree (lpval);
- lpval = env_vars[i].def_value;
- dwType = REG_EXPAND_SZ;
dont_free = 1;
- if (!strcmp (env_vars[i].name, "HOME") && !appdata)
+ if (strcmp (env_vars[i].name, "SHELL") == 0)
+ {
+ /* Look for cmdproxy.exe in every directory in
+ PATH_EXEC. FIXME: This does not find cmdproxy
+ in nt/ when we run uninstalled. */
+ char fname[MAX_PATH];
+ const char *pstart = PATH_EXEC, *pend;
+
+ do {
+ pend = _mbschr (pstart, ';');
+ if (!pend)
+ pend = pstart + strlen (pstart);
+ /* Be defensive against series of ;;; characters. */
+ if (pend > pstart)
+ {
+ strncpy (fname, pstart, pend - pstart);
+ fname[pend - pstart] = '/';
+ strcpy (&fname[pend - pstart + 1], "cmdproxy.exe");
+ ExpandEnvironmentStrings ((LPSTR) fname, bufc,
+ sizeof (bufc));
+ if (check_existing (bufc))
+ {
+ lpval = bufc;
+ dwType = REG_SZ;
+ break;
+ }
+ }
+ if (*pend)
+ pstart = pend + 1;
+ else
+ pstart = pend;
+ if (!*pstart)
+ {
+ /* If not found in any directory, use the
+ default as the last resort. */
+ lpval = env_vars[i].def_value;
+ dwType = REG_EXPAND_SZ;
+ }
+ } while (*pstart);
+ }
+ else
+ {
+ lpval = env_vars[i].def_value;
+ dwType = REG_EXPAND_SZ;
+ }
+ if (strcmp (env_vars[i].name, "HOME") == 0 && !appdata)
Vdelayed_warnings_list
= Fcons (listn (CONSTYPE_HEAP, 2,
intern ("initialization"),
@@ -2394,8 +2451,8 @@ get_emacs_configuration_options (void)
#include <sys/timeb.h>
/* Emulate gettimeofday (Ulrich Leodolter, 1/11/95). */
-void
-gettimeofday (struct timeval *tv, struct timezone *tz)
+int
+gettimeofday (struct timeval *restrict tv, struct timezone *restrict tz)
{
struct _timeb tb;
_ftime (&tb);
@@ -2413,6 +2470,7 @@ gettimeofday (struct timeval *tv, struct
tz->tz_minuteswest = tb.timezone; /* minutes west of Greenwich */
tz->tz_dsttime = tb.dstflag; /* type of dst correction */
}
+ return 0;
}
/* Emulate fdutimens. */
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-16 18:24 MS-Windows build using Posix configury Eli Zaretskii
@ 2013-04-16 18:40 ` Eli Zaretskii
2013-04-16 20:13 ` Stefan Monnier
` (7 subsequent siblings)
8 siblings, 0 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-16 18:40 UTC (permalink / raw)
To: emacs-devel
> Date: Tue, 16 Apr 2013 21:24:29 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> I would appreciate it very much if Autotools gurus here could take a
> look at my tweaking of the configury; the diffs against the current
> trunk are below.
Forgot to tell: there are no ChangeLog entries yet in the diffs; these
will be added when I merge to the trunk.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-16 18:24 MS-Windows build using Posix configury Eli Zaretskii
2013-04-16 18:40 ` Eli Zaretskii
@ 2013-04-16 20:13 ` Stefan Monnier
2013-04-17 2:53 ` Eli Zaretskii
2013-04-16 21:17 ` Glenn Morris
` (6 subsequent siblings)
8 siblings, 1 reply; 116+ messages in thread
From: Stefan Monnier @ 2013-04-16 20:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
> This job is finished, as far as my todo list and debugging are
> concerned: Emacs and all the auxiliary programs build, get installed,
> and seem to work. I performed a full bootstrap several times and also
> several partial builds, including a few parallel builds. "make
> install" likewise works.
Great, thank you Eli.
I'm not an autoconf or w32 guru, so I'll keep my comments/questions to
the minimum below.
> -OPTION_DEFAULT_OFF([w32], [use native MS Windows GUI])
> +OPTION_DEFAULT_OFF([w32], [use native MS Windows GUI in a Cygwin build])
Why is it only for Cygwin builds?
> +LN_EMACS="\$(LN_S)"
> +if test "$opsys" = "mingw32"; then
> + LN_EMACS="ln"
> +fi
> +AC_SUBST(LN_EMACS)
Could we run `ln' to see if it handles -s, instead of testing $opsys?
> + Do not use these instructions with MSYS encironment. For building
^^^^^^^^^^^
> + You are almost there, hand on.
^^^^
hang
> --- nt/gnulib.mk 1970-01-01 00:00:00 +0000
> +++ nt/gnulib.mk 2013-03-31 13:14:54 +0000
> @@ -0,0 +1,858 @@
> +## This file is an edited copy if ../lib/gnulib.mk.
Could we auto-generate this file, based on a new nt/gnulib.mkdiff script?
Stefan
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-16 18:24 MS-Windows build using Posix configury Eli Zaretskii
2013-04-16 18:40 ` Eli Zaretskii
2013-04-16 20:13 ` Stefan Monnier
@ 2013-04-16 21:17 ` Glenn Morris
2013-04-17 2:56 ` Eli Zaretskii
2013-04-17 0:42 ` Glenn Morris
` (5 subsequent siblings)
8 siblings, 1 reply; 116+ messages in thread
From: Glenn Morris @ 2013-04-16 21:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii wrote:
> LN_S = @LN_S@
> +# Used in "make install". Usually, $(LN_S), but MS-Windows uses hard links.
> +LN_EMACS = @LN_EMACS@
I think it would be better if you just set LN_S=ln.
That's already what configure does on platforms where 'ln -s' doesn't
work (if there are any relevant to Emacs; it can even degrade further to
cp -p).
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-16 18:24 MS-Windows build using Posix configury Eli Zaretskii
` (2 preceding siblings ...)
2013-04-16 21:17 ` Glenn Morris
@ 2013-04-17 0:42 ` Glenn Morris
2013-04-17 2:57 ` Eli Zaretskii
2013-04-17 3:33 ` Paul Eggert
` (4 subsequent siblings)
8 siblings, 1 reply; 116+ messages in thread
From: Glenn Morris @ 2013-04-17 0:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii wrote:
> gnu-linux|freebsd|netbsd)
> AC_DEFINE(HAVE_SOUND, 1, [Define to 1 if you have sound support.])
> ;;
> + mingw32)
> + AC_DEFINE(HAVE_SOUND, 1, [Define to 1 if you have sound support.])
> + ;;
[...]
> +if test "${opsys}" = "mingw32"; then
> + AC_DEFINE(NULL_DEVICE, ["NUL:"], [Name of the file to open to get
> + a null file, or a data sink.])
> +else
> + AC_DEFINE(NULL_DEVICE, ["/dev/null"], [Name of the file to open to get
> + a null file, or a data sink.])
> +fi
>
> -AC_DEFINE(SEPCHAR, [':'], [Character that separates PATH elements.])
> +if test "${opsys}" = "mingw32"; then
> + AC_DEFINE(SEPCHAR, [';'], [Character that separates PATH elements.])
> +else
> + AC_DEFINE(SEPCHAR, [':'], [Character that separates PATH elements.])
> +fi
With things like this, I think it is better to have a single
unconditional AH_TEMPLATE that gives the doc string, then as many
AC_DEFINEs as needed that just set the value and don't duplicate the doc.
(There are probably other instances of this.)
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-16 20:13 ` Stefan Monnier
@ 2013-04-17 2:53 ` Eli Zaretskii
0 siblings, 0 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-17 2:53 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Tue, 16 Apr 2013 16:13:46 -0400
>
> > -OPTION_DEFAULT_OFF([w32], [use native MS Windows GUI])
> > +OPTION_DEFAULT_OFF([w32], [use native MS Windows GUI in a Cygwin build])
>
> Why is it only for Cygwin builds?
Because for the native build, that's not an option: you cannot NOT use
it.
> > +LN_EMACS="\$(LN_S)"
> > +if test "$opsys" = "mingw32"; then
> > + LN_EMACS="ln"
> > +fi
> > +AC_SUBST(LN_EMACS)
>
> Could we run `ln' to see if it handles -s, instead of testing $opsys?
The configure script already does, and it sets LN_S to "cp -p" as
result. Which is fine everywhere, except when installing Emacs, where
I prefer a hard link, which wastes less disk space.
> > + Do not use these instructions with MSYS encironment. For building
> ^^^^^^^^^^^
> > + You are almost there, hand on.
> ^^^^
> hang
Oops.
> > --- nt/gnulib.mk 1970-01-01 00:00:00 +0000
> > +++ nt/gnulib.mk 2013-03-31 13:14:54 +0000
> > @@ -0,0 +1,858 @@
> > +## This file is an edited copy if ../lib/gnulib.mk.
>
> Could we auto-generate this file, based on a new nt/gnulib.mkdiff script?
We could, but I'd like more time to pass to see whether this is needed
and how best to generate that (e.g., Sed or Patch).
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-16 21:17 ` Glenn Morris
@ 2013-04-17 2:56 ` Eli Zaretskii
2013-04-17 6:25 ` Glenn Morris
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-17 2:56 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 16 Apr 2013 17:17:27 -0400
>
> Eli Zaretskii wrote:
>
> > LN_S = @LN_S@
> > +# Used in "make install". Usually, $(LN_S), but MS-Windows uses hard links.
> > +LN_EMACS = @LN_EMACS@
>
> I think it would be better if you just set LN_S=ln.
> That's already what configure does on platforms where 'ln -s' doesn't
> work (if there are any relevant to Emacs; it can even degrade further to
> cp -p).
On Windows, the configure script sets LN_S to "cp -p" already. I see
no reason to override that, because this is OK elsewhere in the build.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 0:42 ` Glenn Morris
@ 2013-04-17 2:57 ` Eli Zaretskii
2013-04-17 6:24 ` Glenn Morris
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-17 2:57 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 16 Apr 2013 20:42:54 -0400
>
> Eli Zaretskii wrote:
>
> > gnu-linux|freebsd|netbsd)
> > AC_DEFINE(HAVE_SOUND, 1, [Define to 1 if you have sound support.])
> > ;;
> > + mingw32)
> > + AC_DEFINE(HAVE_SOUND, 1, [Define to 1 if you have sound support.])
> > + ;;
> [...]
> > +if test "${opsys}" = "mingw32"; then
> > + AC_DEFINE(NULL_DEVICE, ["NUL:"], [Name of the file to open to get
> > + a null file, or a data sink.])
> > +else
> > + AC_DEFINE(NULL_DEVICE, ["/dev/null"], [Name of the file to open to get
> > + a null file, or a data sink.])
> > +fi
> >
> > -AC_DEFINE(SEPCHAR, [':'], [Character that separates PATH elements.])
> > +if test "${opsys}" = "mingw32"; then
> > + AC_DEFINE(SEPCHAR, [';'], [Character that separates PATH elements.])
> > +else
> > + AC_DEFINE(SEPCHAR, [':'], [Character that separates PATH elements.])
> > +fi
>
> With things like this, I think it is better to have a single
> unconditional AH_TEMPLATE that gives the doc string, then as many
> AC_DEFINEs as needed that just set the value and don't duplicate the doc.
Sorry, I don't follow: what doc is duplicated? (I'm an autoconf
newbie.) Could you show an example of what you suggest?
Thanks.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-16 18:24 MS-Windows build using Posix configury Eli Zaretskii
` (3 preceding siblings ...)
2013-04-17 0:42 ` Glenn Morris
@ 2013-04-17 3:33 ` Paul Eggert
2013-04-17 17:00 ` Eli Zaretskii
2013-04-17 6:27 ` Glenn Morris
` (3 subsequent siblings)
8 siblings, 1 reply; 116+ messages in thread
From: Paul Eggert @ 2013-04-17 3:33 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Thanks for getting this to work.
On 04/16/13 11:24, Eli Zaretskii wrote:
> +lib-src/emacsclient.res
> ...
> +nt/emacs.res
> +src/temacs.map
> +src/temacs.tmp
How about adding *.res, *.map, *.tmp instead? That should simplify
future maintenance.
> - cd $(DESTDIR)${bindir} && $(LN_S) $(EMACSFULL) $(EMACS); \
> + cd $(DESTDIR)${bindir} && $(LN_EMACS) $(EMACSFULL) $(EMACS); \
Why prefer hard links on Windows but not everywhere else?
How about something like the following instead?
cd $(DESTDIR)${bindir} && { \
ln $(EMACSFULL) $(EMACS) 2>/dev/null || $(LN_S) $(EMACSFULL) $(EMACS); \
}; \
That way, we don't need LN_EMACS.
> + if test "x$(NTDIR)" != "x"; then \
> + cd $(NTDIR) && \
> + $(MAKE) install $(MFLAGS) prefix=${prefix} \
> + exec_prefix=${exec_prefix} bindir=${bindir} \
> + libexecdir=${libexecdir} archlibdir=${archlibdir} \
> + INSTALL_STRIP=${INSTALL_STRIP}; \
> + fi
How about breaking this out into a separate rule (install-arch-dep-nt,
say) and executing only on nt platforms? That will cause the output
of 'make' to be shorter on non-mingw platforms. It could be
implemented something like this, say:
install-arch-dep: install-arch-dep-$(NTDIR)
install-arch-dep-:
install-arch-dep-nt:
cd $(NTDIR) && ...
> + if test "x$(NTDIR)" != "x"; then \
> + cd $(NTDIR) && \
> + $(MAKE) $(MFLAGS) uninstall \
> + prefix=${prefix} exec_prefix=${exec_prefix} \
> + bindir=${bindir} libexecdir=${libexecdir} archlibdir=${archlibdir}; \
> + fi
Similarly, this should be broken out into a rule uninstall-nt.
> gnu-linux|freebsd|netbsd)
> AC_DEFINE(HAVE_SOUND, 1, [Define to 1 if you have sound support.])
> ;;
> + mingw32)
> + AC_DEFINE(HAVE_SOUND, 1, [Define to 1 if you have sound support.])
> + ;;
The two cases should be combined, by appending "|mingw32" to the
previous case.
> if test "${opsys}" != "cygwin"; then
> - AC_MSG_ERROR([Using w32 with an autotools build is only supported for Cygwin.])
> + if test "${opsys}" != "mingw32"; then
> + AC_MSG_ERROR([Using w32 with an autotools build is only supported for Cygwin and MinGW32.])
> + fi
> fi
Please turn this into a "case" instead of a nested "if", as
"case" is easier to read for this sort of thing.
> + AC_CHECK_HEADER([windows.h], [HAVE_W32=yes],
> + [AC_MSG_ERROR([The windows.h header file is required,
> + but cannot be found.])])
This code is redundant and can be removed; the next test checks that
windows.h compiles, which is a stronger test anyway. Also, there's an
earlier AC_CHECK_HEADER([windows.h]...) test that is already there;
perhaps it can be removed too?
> +if test "${opsys}" = "mingw32"; then
> + if test "${with_xpm}" != "no"; then
> + AC_CHECK_HEADER(X11/xpm.h, HAVE_XPM=yes, HAVE_XPM=no, [
> +#define FOR_MSW 1])
> + fi
> +
> + if test "${HAVE_XPM}" = "yes"; then
> + AC_DEFINE(HAVE_XPM, 1, [Define to 1 if you have the Xpm library (-lXpm).])
> + fi
> +fi
There are a number of instances of code like this, where a reasonably
large amount of code is duplicated and surrounded by "if test
"${opsys}" = "mingw32". It'd be better to duplicate less code and do
the mingw32-specific stuff more compactly. Perhaps this is too much
to do right now, but at least this deserves a FIXME, as in the long
run this is increasing maintenance effort.
> +if test "${opsys}" = "mingw32"; then
> + AC_DEFINE(NULL_DEVICE, ["NUL:"], [Name of the file to open to get
> + a null file, or a data sink.])
> +else
> + AC_DEFINE(NULL_DEVICE, ["/dev/null"], [Name of the file to open to get
> + a null file, or a data sink.])
> +fi
For stuff like this, how about putting it into conf_post.h instead?
That'll be clearer and will help 'configure' run faster. E.g.,
something like this in conf_post.h:
/* Override the default definitions. */
#ifdef __MINGW32__
# define NULL_DEVICE "NUL:"
# define IS_DIRECTORY_SEP(c) ((c) == '/' || c == '\')
...
#endif
/* Default definitions, suitable for GNU and POSIXish platforms. */
/* Name of the file to open to get a empty input file,
or a data sink output file. */
#ifndef NULL_DEVICE
# define NULL_DEVICE "/dev/null"
#endif
/* Return true if C is a directory separator in file names. */
#ifndef IS_DIRECTORY_SEP
# define IS_DIRECTORY_SEP(c) ((c) == '/')
#endif
and remove all that stuff from configure.ac.
> - regex.o $(LOADLIBES) -o etags
> + regex.o $(LOADLIBES) $(NTLIB) -o etags${EXEEXT}
> ...
> - ${srcdir}/ebrowse.c $(LOADLIBES) -o ebrowse
> + ${srcdir}/ebrowse.c $(LOADLIBES) $(NTLIB) -o ebrowse${EXEEXT}
> ... etc ...
Perhaps append $(NTLIB) to LOADLIBES's value instead?
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 2:57 ` Eli Zaretskii
@ 2013-04-17 6:24 ` Glenn Morris
0 siblings, 0 replies; 116+ messages in thread
From: Glenn Morris @ 2013-04-17 6:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii wrote:
>> With things like this, I think it is better to have a single
>> unconditional AH_TEMPLATE that gives the doc string, then as many
>> AC_DEFINEs as needed that just set the value and don't duplicate the doc.
>
> Sorry, I don't follow: what doc is duplicated? (I'm an autoconf
> newbie.) Could you show an example of what you suggest?
AH_TEMPLATE(NULL_DEVICE, [Name of the file to open to get
a null file, or a data sink.])
if test "${opsys}" = "mingw32"; then
AC_DEFINE(NULL_DEVICE, ["NUL:"])
else
AC_DEFINE(NULL_DEVICE, ["/dev/null"])
fi
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 2:56 ` Eli Zaretskii
@ 2013-04-17 6:25 ` Glenn Morris
2013-04-17 16:48 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Glenn Morris @ 2013-04-17 6:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii wrote:
> On Windows, the configure script sets LN_S to "cp -p" already. I see
> no reason to override that, because this is OK elsewhere in the build.
Why doesn't configure set LN_S to ln, if ln is usable?
If ln isn't usable, why do you use it unconditionally?
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-16 18:24 MS-Windows build using Posix configury Eli Zaretskii
` (4 preceding siblings ...)
2013-04-17 3:33 ` Paul Eggert
@ 2013-04-17 6:27 ` Glenn Morris
2013-04-17 6:31 ` Glenn Morris
` (2 subsequent siblings)
8 siblings, 0 replies; 116+ messages in thread
From: Glenn Morris @ 2013-04-17 6:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii wrote:
> +(defun set-generated-custom-dependencies-file (file)
[...]
> +(defun set-generated-autoload-file (file)
[...]
> +(defun set-generated-finder-keywords-file (file)
I did not look at the details, but is it possible to have one new defun
rather than three? Eg
(defun set-generated-filename (type file)
(cond ((eq type 'autoload) ...)
...))
?
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-16 18:24 MS-Windows build using Posix configury Eli Zaretskii
` (5 preceding siblings ...)
2013-04-17 6:27 ` Glenn Morris
@ 2013-04-17 6:31 ` Glenn Morris
2013-04-18 19:32 ` Dani Moncayo
2013-04-19 3:05 ` Ken Brown
8 siblings, 0 replies; 116+ messages in thread
From: Glenn Morris @ 2013-04-17 6:31 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii wrote:
> -if test "${HAVE_X11}" = "yes" || test "${HAVE_NS}" = "yes"; then
> +if test "${HAVE_X11}" = "yes" || test "${HAVE_NS}" = "yes" || test "${opsys}" = "mingw32"; then
Can we abstract this kind of thing into
DISPLAY_GRAPHIC_P=no
test "${HAVE_X11}" = "yes" || test "${HAVE_NS}" = "yes" || \
test "${opsys}" = "mingw32" && DISPLAY_GRAPHIC_P=yes
if test "${DISPLAY_GRAPHIC_P}" = "yes"; then...
Sometimes it seems to be test "${HAVE_W32}" = "yes" instead, so maybe
there are not enough common patterns for it to be worthwhile.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 6:25 ` Glenn Morris
@ 2013-04-17 16:48 ` Eli Zaretskii
2013-04-17 17:11 ` Glenn Morris
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-17 16:48 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 17 Apr 2013 02:25:41 -0400
>
> Eli Zaretskii wrote:
>
> > On Windows, the configure script sets LN_S to "cp -p" already. I see
> > no reason to override that, because this is OK elsewhere in the build.
>
> Why doesn't configure set LN_S to ln, if ln is usable?
> If ln isn't usable, why do you use it unconditionally?
'ln' does work on Windows, but evidently not good enough for
Autoconf. From the configure script:
rm -f conf$$ conf$$.exe conf$$.file
if test -d conf$$.dir; then
rm -f conf$$.dir/conf$$.file
else
rm -f conf$$.dir
mkdir conf$$.dir 2>/dev/null
fi
if (echo >conf$$.file) 2>/dev/null; then
if ln -s conf$$.file conf$$ 2>/dev/null; then
as_ln_s='ln -s'
# ... but there are two gotchas:
>>>> # 1) On MSYS, both `ln -s file dir' and `ln file dir' fail. <<<<<<<<<<<<
# 2) DJGPP < 2.04 has no symlinks; `ln -s' creates a wrapper executable.
# In both cases, we have to default to `cp -p'.
ln -s conf$$.file conf$$.dir 2>/dev/null && test ! -f conf$$.exe ||
as_ln_s='cp -p'
elif ln conf$$.file conf$$ 2>/dev/null; then
as_ln_s=ln
else
as_ln_s='cp -p'
fi
else
as_ln_s='cp -p'
And indeed, the Windows documentation clearly says that hard links to
directories are not supported.
I could, of course, force LN_S to be 'ln' for the Windows build, but
then what if one day we will need to make a hard link to a directory?
OTOH, Paul suggested to use 'ln' on all platforms when installing
Emacs (which is the only place where this issue arises), in which case
this is a moot point.
On the third hand, there's talk about not creating any links as part
of "make install" (see
http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00450.html).
So I'm not sure this is worth any effort.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 3:33 ` Paul Eggert
@ 2013-04-17 17:00 ` Eli Zaretskii
2013-04-17 18:48 ` Paul Eggert
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-17 17:00 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
> Date: Tue, 16 Apr 2013 20:33:18 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
>
> Thanks for getting this to work.
Thanks for reviewing the changes.
> > - cd $(DESTDIR)${bindir} && $(LN_S) $(EMACSFULL) $(EMACS); \
> > + cd $(DESTDIR)${bindir} && $(LN_EMACS) $(EMACSFULL) $(EMACS); \
>
> Why prefer hard links on Windows but not everywhere else?
I don't know why we moved to symlinks here. Perhaps Glenn could
comment on that.
> How about something like the following instead?
>
> cd $(DESTDIR)${bindir} && { \
> ln $(EMACSFULL) $(EMACS) 2>/dev/null || $(LN_S) $(EMACSFULL) $(EMACS); \
> }; \
>
> That way, we don't need LN_EMACS.
Right, fine with me. But see also my other mail on this issue.
> > +if test "${opsys}" = "mingw32"; then
> > + if test "${with_xpm}" != "no"; then
> > + AC_CHECK_HEADER(X11/xpm.h, HAVE_XPM=yes, HAVE_XPM=no, [
> > +#define FOR_MSW 1])
> > + fi
> > +
> > + if test "${HAVE_XPM}" = "yes"; then
> > + AC_DEFINE(HAVE_XPM, 1, [Define to 1 if you have the Xpm library (-lXpm).])
> > + fi
> > +fi
>
> There are a number of instances of code like this, where a reasonably
> large amount of code is duplicated and surrounded by "if test
> "${opsys}" = "mingw32". It'd be better to duplicate less code and do
> the mingw32-specific stuff more compactly. Perhaps this is too much
> to do right now, but at least this deserves a FIXME, as in the long
> run this is increasing maintenance effort.
Right. For the record, the reason why I didn't bring these instances
together is that they test for optional libraries one by one, and I
thought keeping the tests related to each library together was more
important than avoiding some code duplication.
> > +if test "${opsys}" = "mingw32"; then
> > + AC_DEFINE(NULL_DEVICE, ["NUL:"], [Name of the file to open to get
> > + a null file, or a data sink.])
> > +else
> > + AC_DEFINE(NULL_DEVICE, ["/dev/null"], [Name of the file to open to get
> > + a null file, or a data sink.])
> > +fi
>
> For stuff like this, how about putting it into conf_post.h instead?
Fine with me. However, Glenn suggested another solution, one that
involves other similar macros (like SEPCHAR). Which way to use?
Thanks for the other suggestions, I will implement them all.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 16:48 ` Eli Zaretskii
@ 2013-04-17 17:11 ` Glenn Morris
2013-04-17 17:34 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Glenn Morris @ 2013-04-17 17:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii wrote:
> 'ln' does work on Windows, but evidently not good enough for Autoconf.
Sounds like an autoconf bug that should be reported.
> And indeed, the Windows documentation clearly says that hard links to
> directories are not supported.
>
> I could, of course, force LN_S to be 'ln' for the Windows build, but
> then what if one day we will need to make a hard link to a directory?
This isn't portable, so we should never do this.
For example, on the AFS file system, hard links cannot span directories.
We should only ever use links in the way that we currently do, between
files in the same directory. From the autoconf manual:
If you make a link in a directory other than the current
directory, its meaning depends on whether `ln' or `ln -s' is used.
To safely create links using `$(LN_S)', either find out which form
is used and adjust the arguments, or always invoke `ln' in the
directory where the link is to be created.
So it is totally fine for you to just set LN_S=ln on MS Windows until
autoconf gets fixed to do this anyway.
> OTOH, Paul suggested to use 'ln' on all platforms when installing
> Emacs (which is the only place where this issue arises), in which case
> this is a moot point.
I already said that symlinks are better here IMO.
http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00230.html
> On the third hand, there's talk about not creating any links as part
> of "make install" (see
> http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00450.html).
We'll always have the emacs-XX.YY -> emacs link.
> So I'm not sure this is worth any effort.
The least effort, and the right thing IMO is for you to just set
LN_S=ln. If ln works, we never want to use "cp -p".
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 17:11 ` Glenn Morris
@ 2013-04-17 17:34 ` Eli Zaretskii
2013-04-17 17:53 ` Glenn Morris
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-17 17:34 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 17 Apr 2013 13:11:55 -0400
>
> Eli Zaretskii wrote:
>
> > 'ln' does work on Windows, but evidently not good enough for Autoconf.
>
> Sounds like an autoconf bug that should be reported.
If Paul says I won't be laughed at ;-) Paul?
> So it is totally fine for you to just set LN_S=ln on MS Windows until
> autoconf gets fixed to do this anyway.
Fine, will do.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 17:34 ` Eli Zaretskii
@ 2013-04-17 17:53 ` Glenn Morris
2013-04-17 18:15 ` Glenn Morris
0 siblings, 1 reply; 116+ messages in thread
From: Glenn Morris @ 2013-04-17 17:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii wrote:
>> Sounds like an autoconf bug that should be reported.
>
> If Paul says I won't be laughed at ;-) Paul?
Oh, hmph, I actually bothered to read the configure code this time...
So they are explicitly testing if links to directories work, which will
handle the AFS case as well. So if we are only interested in links to
_files_ (in the same directory) rather than directories as well, LN_S is
too strict for us. Looks like there is no existing autoconf test for
"portable link to a file within the same directory".
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 17:53 ` Glenn Morris
@ 2013-04-17 18:15 ` Glenn Morris
2013-04-17 18:44 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Glenn Morris @ 2013-04-17 18:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Glenn Morris wrote:
> Oh, hmph, I actually bothered to read the configure code this time...
> So they are explicitly testing if links to directories work, which will
> handle the AFS case as well. So if we are only interested in links to
> _files_ (in the same directory) rather than directories as well, LN_S is
> too strict for us. Looks like there is no existing autoconf test for
> "portable link to a file within the same directory".
So probably we should just go back to using "ln", and forget about
AC_PROG_LN_S, sigh. (Or write our own test for the features of ln -s
that we want to use). In any case, it's not something you should have
had to worry about as part of your changes, sorry.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 18:15 ` Glenn Morris
@ 2013-04-17 18:44 ` Eli Zaretskii
0 siblings, 0 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-17 18:44 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 17 Apr 2013 14:15:14 -0400
>
> So probably we should just go back to using "ln", and forget about
> AC_PROG_LN_S, sigh. (Or write our own test for the features of ln -s
> that we want to use). In any case, it's not something you should have
> had to worry about as part of your changes, sorry.
OK, thanks.
So I will see what happens on the mainline, and take it from there.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 17:00 ` Eli Zaretskii
@ 2013-04-17 18:48 ` Paul Eggert
2013-04-17 19:15 ` Glenn Morris
0 siblings, 1 reply; 116+ messages in thread
From: Paul Eggert @ 2013-04-17 18:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 04/17/13 10:00, Eli Zaretskii wrote:
> Glenn suggested another solution, one that
> involves other similar macros (like SEPCHAR). Which way to use?
My way (of course :-). The main idea is to move this out of
configure.ac, because the full power and high cost of Autoconf
isn't needed here.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 18:48 ` Paul Eggert
@ 2013-04-17 19:15 ` Glenn Morris
2013-04-17 19:45 ` Eli Zaretskii
2013-04-17 21:19 ` Paul Eggert
0 siblings, 2 replies; 116+ messages in thread
From: Glenn Morris @ 2013-04-17 19:15 UTC (permalink / raw)
To: Paul Eggert; +Cc: Eli Zaretskii, emacs-devel
Paul Eggert wrote:
> My way (of course :-). The main idea is to move this out of
> configure.ac, because the full power and high cost of Autoconf
> isn't needed here.
This has never been a consideration in my mind when converting things
from old-school Emacs build-style to autoconf. There's probably tons of
stuff that falls into the above category. I have never considered the
speed of configure an issue. Why is MS Windows any different to eg AIX,
unixware, or any of the other platforms that almost no-one uses but
configure.ac handles? I don't know how many people will end up using
configure on MS Windows, but if it is > 1 it probably still beats AIX...
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 19:15 ` Glenn Morris
@ 2013-04-17 19:45 ` Eli Zaretskii
2013-04-17 20:43 ` Glenn Morris
2013-04-17 21:19 ` Paul Eggert
1 sibling, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-17 19:45 UTC (permalink / raw)
To: Glenn Morris; +Cc: eggert, emacs-devel
> From: Glenn Morris <rgm@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Wed, 17 Apr 2013 15:15:38 -0400
>
> I don't know how many people will end up using configure on MS
> Windows
The plan is to move them all (i.e. all those who build Emacs
themselves) to using the Posix configury, and deprecate the current
nt/confugure.bat and makefile.w32-in files. That's why I made this
possible in the first place.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 19:45 ` Eli Zaretskii
@ 2013-04-17 20:43 ` Glenn Morris
0 siblings, 0 replies; 116+ messages in thread
From: Glenn Morris @ 2013-04-17 20:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii wrote:
> The plan is to move them all (i.e. all those who build Emacs
> themselves) to using the Posix configury, and deprecate the current
> nt/confugure.bat and makefile.w32-in files. That's why I made this
> possible in the first place.
Fantastic! Thank you.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 19:15 ` Glenn Morris
2013-04-17 19:45 ` Eli Zaretskii
@ 2013-04-17 21:19 ` Paul Eggert
2013-04-17 22:38 ` Glenn Morris
1 sibling, 1 reply; 116+ messages in thread
From: Paul Eggert @ 2013-04-17 21:19 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
On 04/17/13 12:15, Glenn Morris wrote:
> I have never considered the
> speed of configure an issue. Why is MS Windows any different
It's not. 'configure' is too slow on GNU/Linux,
it's too slow on Solaris, and it'll be too slow
on MS-Windows.
On my two-year-old desktop (GNU/Linux, AMD Phenom II X4 910e)
'configure' takes 65 seconds, whereas 'rm */*.o; make -j4'
takes 45 seconds. 'configure' is a major bottleneck in building,
and where it's easy (as it is here) we should strive to have
'configure' run faster.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 21:19 ` Paul Eggert
@ 2013-04-17 22:38 ` Glenn Morris
2013-04-18 0:52 ` Paul Eggert
0 siblings, 1 reply; 116+ messages in thread
From: Glenn Morris @ 2013-04-17 22:38 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
Paul Eggert wrote:
> On my two-year-old desktop (GNU/Linux, AMD Phenom II X4 910e)
> 'configure' takes 65 seconds, whereas 'rm */*.o; make -j4' takes 45
> seconds. 'configure' is a major bottleneck in building, and where it's
> easy (as it is here) we should strive to have 'configure' run faster.
And when you apply Eli's proposed patch, what does the 65 seconds change
to?
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-17 22:38 ` Glenn Morris
@ 2013-04-18 0:52 ` Paul Eggert
2013-04-18 5:29 ` Glenn Morris
0 siblings, 1 reply; 116+ messages in thread
From: Paul Eggert @ 2013-04-18 0:52 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
On 04/17/2013 03:38 PM, Glenn Morris wrote:
> when you apply Eli's proposed patch, what does the 65 seconds change
> to?
Doesn't add much: 0.9 seconds in one test run,
and that's probably at the noise level. But
regardless of speed it's better to avoid the
complexity of Autoconf and stick to straightforward
C code when it's easy to do so, as it is here.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-18 0:52 ` Paul Eggert
@ 2013-04-18 5:29 ` Glenn Morris
2013-04-18 16:11 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Glenn Morris @ 2013-04-18 5:29 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
Paul Eggert wrote:
> Doesn't add much: 0.9 seconds in one test run, and that's probably at
> the noise level. But regardless of speed it's better to avoid the
> complexity of Autoconf and stick to straightforward C code when it's
> easy to do so, as it is here.
It would be surprising if it weren't noise, since a few more if/elses
here and there shouldn't make any measurable difference. I don't think
Eli should feel any obligation to redo his work in a different style to
the vast majority of the existing auto-configuration stuff before
installing it. If he or anyone else wants to, by all means let's try and
speed up configure as an independent project though.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-18 5:29 ` Glenn Morris
@ 2013-04-18 16:11 ` Eli Zaretskii
0 siblings, 0 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-18 16:11 UTC (permalink / raw)
To: Glenn Morris; +Cc: eggert, emacs-devel
> From: Glenn Morris <rgm@gnu.org>
> Date: Thu, 18 Apr 2013 01:29:42 -0400
> Cc: emacs-devel@gnu.org
>
> Paul Eggert wrote:
>
> > Doesn't add much: 0.9 seconds in one test run, and that's probably at
> > the noise level. But regardless of speed it's better to avoid the
> > complexity of Autoconf and stick to straightforward C code when it's
> > easy to do so, as it is here.
>
> It would be surprising if it weren't noise, since a few more if/elses
> here and there shouldn't make any measurable difference. I don't think
> Eli should feel any obligation to redo his work in a different style to
> the vast majority of the existing auto-configuration stuff before
> installing it. If he or anyone else wants to, by all means let's try and
> speed up configure as an independent project though.
I agree.
Paul, I see where are you coming from, and I do agree with your
reasoning. But as Glenn points out, it doesn't make sense to do this
for one or two settings, only if we are going to move most or all of
these out of configure.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-16 18:24 MS-Windows build using Posix configury Eli Zaretskii
` (6 preceding siblings ...)
2013-04-17 6:31 ` Glenn Morris
@ 2013-04-18 19:32 ` Dani Moncayo
2013-04-18 20:27 ` Dani Moncayo
2013-04-18 21:20 ` Eli Zaretskii
2013-04-19 3:05 ` Ken Brown
8 siblings, 2 replies; 116+ messages in thread
From: Dani Moncayo @ 2013-04-18 19:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
> Windows users are encouraged to try this. The diffs below will create
> a file nt/INSTALL.MSYS with detailed instructions for how to build
> this way; please read it before you try the build. (Actually, about
> 85% of the job is just to set up a working MSYS installation, which
> therefore takes the lion's share of the instructions.)
Thanks Eli.
I've applied your patch to a local branch, and tried to follow the
instructions in nt/INSTALL.MSYS, but I've failed to build Emacs.
I've installed the MinGW using the "mingw-get" installer and, besides
the default packages it installs by default, I've installed these two:
* msys-base
* mingw-developer-toolkit
I think that, with this, I should have all the required packages you
mention in INSTALL.MSYS.
I've also verified that I have the MinGW "bin" directory on PATH, but
not the MSYS "bin" directory.
But when I go to the root of my local branch and do "./autogen.sh", I
get this error:
Checking whether you have the necessary tools...
(Read INSTALL.BZR for more details on building Emacs)
Checking for autoconf (need at least version 2.65)...
ok
Checking for automake (need at least version 1.11)...
ok
Your system has the required tools, running autoreconf...
Can't locate Autom4te/ChannelDefs.pm in @INC (@INC contains:
/mingw/share/autoconf /usr/lib/perl5/5.8/msys /usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/msys /usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/msys
/usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at
/c/MinGW/bin/autoreconf-2.68 line 40.
BEGIN failed--compilation aborted at /c/MinGW/bin/autoreconf-2.68 line 40.
Do you know what's the problem here?
TIA.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-18 19:32 ` Dani Moncayo
@ 2013-04-18 20:27 ` Dani Moncayo
2013-04-18 21:20 ` Eli Zaretskii
1 sibling, 0 replies; 116+ messages in thread
From: Dani Moncayo @ 2013-04-18 20:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
> But when I go to the root of my local branch and do "./autogen.sh", I
> get this error:
>
> Checking whether you have the necessary tools...
> (Read INSTALL.BZR for more details on building Emacs)
>
> Checking for autoconf (need at least version 2.65)...
> ok
> Checking for automake (need at least version 1.11)...
> ok
> Your system has the required tools, running autoreconf...
> Can't locate Autom4te/ChannelDefs.pm in @INC (@INC contains:
> /mingw/share/autoconf /usr/lib/perl5/5.8/msys /usr/lib/perl5/5.8
> /usr/lib/perl5/site_perl/5.8/msys /usr/lib/perl5/site_perl/5.8
> /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/msys
> /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at
> /c/MinGW/bin/autoreconf-2.68 line 40.
> BEGIN failed--compilation aborted at /c/MinGW/bin/autoreconf-2.68 line 40.
>
>
> Do you know what's the problem here?
FWIW: I've just downloaded the last build from [1], uncompressed it,
stated a bash shell (by invoking `msys.bat', as usual), and the above
error doesn't appear now:
$ ./autogen.sh
Checking whether you have the necessary tools...
(Read INSTALL.BZR for more details on building Emacs)
Checking for autoconf (need at least version 2.65)...
ok
Checking for automake (need at least version 1.11)...
ok
Your system has the required tools, running autoreconf...
configure.ac:598: installing 'build-aux/compile'
configure.ac:399: installing 'build-aux/config.guess'
configure.ac:399: installing 'build-aux/config.sub'
configure.ac:45: installing 'build-aux/install-sh'
configure.ac:45: installing 'build-aux/missing'
lib/Makefile.am: installing 'build-aux/depcomp'
You can now run `./configure'.
So I'll try to complete the build process from this newer version of MSYS.
--- Footnotes ---
[1] http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-18 19:32 ` Dani Moncayo
2013-04-18 20:27 ` Dani Moncayo
@ 2013-04-18 21:20 ` Eli Zaretskii
2013-04-18 22:03 ` Dani Moncayo
1 sibling, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-18 21:20 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Thu, 18 Apr 2013 21:32:12 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> But when I go to the root of my local branch and do "./autogen.sh", I
> get this error:
>
> Checking whether you have the necessary tools...
> (Read INSTALL.BZR for more details on building Emacs)
>
> Checking for autoconf (need at least version 2.65)...
> ok
> Checking for automake (need at least version 1.11)...
> ok
> Your system has the required tools, running autoreconf...
> Can't locate Autom4te/ChannelDefs.pm in @INC (@INC contains:
> /mingw/share/autoconf /usr/lib/perl5/5.8/msys /usr/lib/perl5/5.8
> /usr/lib/perl5/site_perl/5.8/msys /usr/lib/perl5/site_perl/5.8
> /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/msys
> /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at
> /c/MinGW/bin/autoreconf-2.68 line 40.
> BEGIN failed--compilation aborted at /c/MinGW/bin/autoreconf-2.68 line 40.
> ^^^^^^^^^^^^^^^
>
> Do you know what's the problem here?
Yes: you didn't follow the instructions to the letter ;-) As result
you seem to have a botched Autoconf installation which lacks this
file.
INSTALL.MSYS points to specific distributions of Autoconf and
Automake. I did that (and actually prepared those distributions)
precisely because I know they work for me. You are using a different
version of Autoconf, probably downloaded from somewhere else.
I see that you fixed that in the mean time, but I also see that you
still use a different version of Autoconf from the one to which I
pointed. You may consider uninstalling what you have and installing
the versions I provided (assuming that mingw-get supports uninstalling
well enough -- I don't know because I never used that tool). Please
note that the version I provided is exactly the one used by Glenn to
generate the files in autogen/ subdirectory -- which is the reason
that I used those very versions of autotools.
Also, I see that your Autoconf is installed in the MinGW tree, not in
the MSYS tree, probably because you installed MinGW packages for
Autoconf and Automake (tyere are no MSYS packages, AFAICS). Again, I
advise not to do that. Use my packages, and install them from the
root of the MSYS tree. Separating MinGW from MSYS is another advice
in INSTALL.MSYS I suggest that you follow to the letter.
Having MinGW and MSYS installed correctly and in perfect working order
gets you 99% of the way of being able to build Emacs -- all the rest
"just works".
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-18 21:20 ` Eli Zaretskii
@ 2013-04-18 22:03 ` Dani Moncayo
2013-04-19 6:34 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-04-18 22:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
>> Do you know what's the problem here?
>
> Yes: you didn't follow the instructions to the letter ;-) As result
> you seem to have a botched Autoconf installation which lacks this
> file.
Sorry, I just tried to avoid manual installation of packages, and use
(exclusively) the mingw-get package manager instead (which seems more
convenient to me).
When I have time, I'll try to manually install the distributions of
Automake and Autoconf that you mention in INSTALL.MSYS.
Thank you.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-16 18:24 MS-Windows build using Posix configury Eli Zaretskii
` (7 preceding siblings ...)
2013-04-18 19:32 ` Dani Moncayo
@ 2013-04-19 3:05 ` Ken Brown
2013-04-19 6:35 ` Eli Zaretskii
8 siblings, 1 reply; 116+ messages in thread
From: Ken Brown @ 2013-04-19 3:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 4/16/2013 2:24 PM, Eli Zaretskii wrote:
> Also, if people could apply the diffs and try building Emacs on their
> platforms, I'd appreciate. Of special interest are the Cygwin w32
> build and any Unix system. (I tested this on one GNU/Linux box, but I
> have no access to other Posix systems.)
I didn't find any problem with the Cygwin w32 build. I checked both
32-bit and 64-bit Cygwin.
Ken
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-18 22:03 ` Dani Moncayo
@ 2013-04-19 6:34 ` Eli Zaretskii
2013-04-19 20:17 ` Dani Moncayo
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-19 6:34 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Fri, 19 Apr 2013 00:03:38 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> >> Do you know what's the problem here?
> >
> > Yes: you didn't follow the instructions to the letter ;-) As result
> > you seem to have a botched Autoconf installation which lacks this
> > file.
>
> Sorry, I just tried to avoid manual installation of packages, and use
> (exclusively) the mingw-get package manager instead (which seems more
> convenient to me).
Yes, I can understand that.
> When I have time, I'll try to manually install the distributions of
> Automake and Autoconf that you mention in INSTALL.MSYS.
If you succeeded in building Emacs in the meantime, perhaps wait with
uninstalling until (and unless) you actually bump into problems. I
did some minimal testing with the latest versions of autotools (which
you seem to have) as well, and didn't see any trouble. So it is
possible that your current setup is OK as it is. I just cannot vouch
for those versions as well as I can for the versions I mentioned in
INSTALL.MSYS.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-19 3:05 ` Ken Brown
@ 2013-04-19 6:35 ` Eli Zaretskii
0 siblings, 0 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-19 6:35 UTC (permalink / raw)
To: Ken Brown; +Cc: emacs-devel
> Date: Thu, 18 Apr 2013 23:05:39 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: emacs-devel@gnu.org
>
> On 4/16/2013 2:24 PM, Eli Zaretskii wrote:
> > Also, if people could apply the diffs and try building Emacs on their
> > platforms, I'd appreciate. Of special interest are the Cygwin w32
> > build and any Unix system. (I tested this on one GNU/Linux box, but I
> > have no access to other Posix systems.)
>
> I didn't find any problem with the Cygwin w32 build. I checked both
> 32-bit and 64-bit Cygwin.
Thanks, that's very good news.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-19 6:34 ` Eli Zaretskii
@ 2013-04-19 20:17 ` Dani Moncayo
2013-04-20 6:34 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-04-19 20:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
>> I just tried to avoid manual installation of packages, and use
>> (exclusively) the mingw-get package manager instead (which seems more
>> convenient to me).
>
> Yes, I can understand that.
I've played a bit more, and I think I'm close to build Emacs with a
MinGW environment set up exclusively with its package manager (that
would be nice!).
The packages I've installed (with "mingw-get install <package>"), in
addition to the ones installed by default, are:
* msys-base
* mingw-developer-toolkit
* msys-automake
Once I've done that, the "./autogen.sh" command is successful:
$ ./autogen.sh
Checking whether you have the necessary tools...
(Read INSTALL.BZR for more details on building Emacs)
Checking for autoconf (need at least version 2.65)...
ok
Checking for automake (need at least version 1.11)...
ok
Your system has the required tools, running autoreconf...
You can now run `./configure'.
The configuration command is successful too:
$ CPPFLAGS='-DGLYPH_DEBUG=1' CFLAGS='-O0 -g3'
../mybranch/nt/msysconfig.sh --prefix=c:/usr --enable-checking
--without-all
[...]
Configured for `i686-pc-mingw32'.
Where should the build process find the source code? /c/emacs/mybranch
What compiler should emacs be built with? gcc
-std=gnu99 -O0 -g
3
Should Emacs use the GNU version of malloc? yes
Should Emacs use a relocating allocator for buffers? yes
Should Emacs use mmap(2) for buffer allocation? no
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? no
Does Emacs use -ltiff? no
Does Emacs use a gif library? no
Does Emacs use -lpng? no
Does Emacs use -lrsvg-2? no
Does Emacs use imagemagick? no
Does Emacs use -lgpm? no
Does Emacs use -ldbus? no
Does Emacs use -lgconf? no
Does Emacs use GSettings? no
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 use toolkit scroll bars? no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating lib/Makefile
config.status: creating lib-src/Makefile
config.status: creating oldXMenu/Makefile
config.status: creating doc/emacs/Makefile
config.status: creating doc/misc/Makefile
config.status: creating doc/lispintro/Makefile
config.status: creating doc/lispref/Makefile
config.status: creating src/Makefile
config.status: creating lwlib/Makefile
config.status: creating lisp/Makefile
config.status: creating leim/Makefile
config.status: creating nextstep/Makefile
config.status: creating nt/Makefile
config.status: creating test/automated/Makefile
config.status: creating admin/unidata/Makefile
config.status: creating src/config.h
config.status: executing depfiles commands
config.status: executing mkdirs commands
config.status: executing epaths commands
creating src/epaths.h
config.status: executing gdbinit commands
creating src/.gdbinit
But then, the "bootstrap" target ends up failing here:
make[3]: Leaving directory `/c/emacs/build/doc/misc'
make[2]: Leaving directory `/c/emacs/build'
cd nt && make all -w \
CC='gcc -std=gnu99' CFLAGS='-O0 -g3'
CPPFLAGS='-mtune=pentium4 -DGLY
PH_DEBUG=1 -DUSE_CRT_DLL=1 -I /c/emacs/mybranch/nt/inc' \
LDFLAGS='' MAKE='make'
make[2]: Entering directory `/c/emacs/build/nt'
windres -O coff -o emacs.res emacs.rc
gcc: error: emacs.rc: No such file or directory
gcc: warning: '-x c' after last input file has no effect
gcc: fatal error: no input files
compilation terminated.
c:\MinGW\bin\windres.exe: preprocessing failed.
make[2]: *** [emacs.res] Error 1
make[2]: Leaving directory `/c/emacs/build/nt'
make[1]: *** [nt] Error 2
make[1]: Leaving directory `/c/emacs/build'
make: *** [bootstrap] Error 2
What might the problem be?
TIA
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-19 20:17 ` Dani Moncayo
@ 2013-04-20 6:34 ` Eli Zaretskii
2013-04-20 7:35 ` Dani Moncayo
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-20 6:34 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Fri, 19 Apr 2013 22:17:40 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> The packages I've installed (with "mingw-get install <package>"), in
> addition to the ones installed by default, are:
> * msys-base
> * mingw-developer-toolkit
> * msys-automake
What do you mean by "installed by default"? If we want the
instructions to be comprehensive, we need to spell out _all_ of the
packages, including those installed by default.
> The configuration command is successful too:
> $ CPPFLAGS='-DGLYPH_DEBUG=1' CFLAGS='-O0 -g3'
> ../mybranch/nt/msysconfig.sh --prefix=c:/usr --enable-checking
> --without-all
Why --without-all? You do have the image libraries, right?
> make[2]: Entering directory `/c/emacs/build/nt'
> windres -O coff -o emacs.res emacs.rc
> gcc: error: emacs.rc: No such file or directory
> gcc: warning: '-x c' after last input file has no effect
> gcc: fatal error: no input files
> compilation terminated.
> c:\MinGW\bin\windres.exe: preprocessing failed.
> make[2]: *** [emacs.res] Error 1
> make[2]: Leaving directory `/c/emacs/build/nt'
> make[1]: *** [nt] Error 2
> make[1]: Leaving directory `/c/emacs/build'
> make: *** [bootstrap] Error 2
>
>
> What might the problem be?
It's a bug (I didn't yet try to build outside of the source tree, so I
didn't hit it). Change this line in nt/Makefile.in:
${WINDRES} -O coff -o emacs.res emacs.rc
to say this instead:
${WINDRES} -O coff -o emacs.res ${srcdir}/emacs.rc
Btw, you don't need to say "make bootstrap" with this setup, unless
you want to force a bootstrap. Just "make" will do whatever it takes
to build Emacs, and will bootstrap if needed.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-20 6:34 ` Eli Zaretskii
@ 2013-04-20 7:35 ` Dani Moncayo
2013-04-20 7:56 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-04-20 7:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
>> The packages I've installed (with "mingw-get install <package>"), in
>> addition to the ones installed by default, are:
>> * msys-base
>> * mingw-developer-toolkit
>> * msys-automake
>
> What do you mean by "installed by default"? If we want the
> instructions to be comprehensive, we need to spell out _all_ of the
> packages, including those installed by default.
By "packages installed by default", I mean the packages that get
installed if you install MinGW (with the "mingw-get-inst-20120426.exe"
installer) and accept the default options in the wizard.
Sorry, I've not found a way to get the list of installed packages
(AFAICT, the package manager currently lacks such a feature).
>> The configuration command is successful too:
>> $ CPPFLAGS='-DGLYPH_DEBUG=1' CFLAGS='-O0 -g3'
>> ../mybranch/nt/msysconfig.sh --prefix=c:/usr --enable-checking
>> --without-all
>
> Why --without-all? You do have the image libraries, right?
Yes, I have image libraries, but I wanted to try first a simple build,
to make sure that a botched library setup is not the culprit of any
build failure.
>> make[2]: Entering directory `/c/emacs/build/nt'
>> windres -O coff -o emacs.res emacs.rc
>> gcc: error: emacs.rc: No such file or directory
>> gcc: warning: '-x c' after last input file has no effect
>> gcc: fatal error: no input files
>> compilation terminated.
>> c:\MinGW\bin\windres.exe: preprocessing failed.
>> make[2]: *** [emacs.res] Error 1
>> make[2]: Leaving directory `/c/emacs/build/nt'
>> make[1]: *** [nt] Error 2
>> make[1]: Leaving directory `/c/emacs/build'
>> make: *** [bootstrap] Error 2
>>
>>
>> What might the problem be?
>
> It's a bug (I didn't yet try to build outside of the source tree, so I
> didn't hit it). Change this line in nt/Makefile.in:
>
> ${WINDRES} -O coff -o emacs.res emacs.rc
>
> to say this instead:
>
> ${WINDRES} -O coff -o emacs.res ${srcdir}/emacs.rc
>
> Btw, you don't need to say "make bootstrap" with this setup, unless
> you want to force a bootstrap. Just "make" will do whatever it takes
> to build Emacs, and will bootstrap if needed.
Ok, I've done the above change, and now a plain "make" ends up failing here:
[...]
creating src/epaths.h
make[1]: Entering directory `/c/emacs/build'
make[1]: Leaving directory `/c/emacs/build'
config.status: executing gdbinit commands
[ -r "/c/emacs/mybranch/src/config.in" ] || ( cd /c/emacs/mybranch
&& autoheader
)
cd nt && make all \
CC='gcc -std=gnu99' CFLAGS='-O0 -g3'
CPPFLAGS='-mtune=pentium4 -DGLY
PH_DEBUG=1 -DUSE_CRT_DLL=1 -I /c/emacs/mybranch/nt/inc' \
LDFLAGS='' MAKE='make'
make[1]: Entering directory `/c/emacs/build/nt'
windres -O coff -o emacs.res /c/emacs/mybranch/nt/emacs.rc
gcc -std=gnu99 -mtune=pentium4 -I. -I/c/emacs/mybranch/nt
-mtune=pentium4
-DGLYPH_DEBUG=1 -DUSE_CRT_DLL=1 -I /c/emacs/mybranch/nt/inc -O0 -g3
/c/emacs/my
branch/nt/runemacs.c emacs.res \
-o runemacs.exe
make[1]: *** No rule to make target
`/c/emacs/mybranch/nt/../src/epaths.h', need
ed by `addpm.exe'. Stop.
make[1]: Leaving directory `/c/emacs/build/nt'
make: *** [nt] Error 2
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-20 7:35 ` Dani Moncayo
@ 2013-04-20 7:56 ` Eli Zaretskii
2013-04-20 17:18 ` Dani Moncayo
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-20 7:56 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Sat, 20 Apr 2013 09:35:13 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> >> The packages I've installed (with "mingw-get install <package>"), in
> >> addition to the ones installed by default, are:
> >> * msys-base
> >> * mingw-developer-toolkit
> >> * msys-automake
> >
> > What do you mean by "installed by default"? If we want the
> > instructions to be comprehensive, we need to spell out _all_ of the
> > packages, including those installed by default.
>
> By "packages installed by default", I mean the packages that get
> installed if you install MinGW (with the "mingw-get-inst-20120426.exe"
> installer) and accept the default options in the wizard.
>
> Sorry, I've not found a way to get the list of installed packages
> (AFAICT, the package manager currently lacks such a feature).
That's OK; the above description about accepting the default options
should be good enough. Could you provide a list of those default
options, so I could list them in the instructions?
> make[1]: Entering directory `/c/emacs/build/nt'
> windres -O coff -o emacs.res /c/emacs/mybranch/nt/emacs.rc
> gcc -std=gnu99 -mtune=pentium4 -I. -I/c/emacs/mybranch/nt -mtune=pentium4 -DGLYPH_DEBUG=1 -DUSE_CRT_DLL=1 -I /c/emacs/mybranch/nt/inc -O0 -g3 /c/emacs/my branch/nt/runemacs.c emacs.res \
> -o runemacs.exe
> make[1]: *** No rule to make target `/c/emacs/mybranch/nt/../src/epaths.h', needed by `addpm.exe'. Stop.
> make[1]: Leaving directory `/c/emacs/build/nt'
> make: *** [nt] Error 2
That's a bug in the opposite direction. Change this line in
nt/Makefile.in:
addpm${EXEEXT}: ${srcdir}/addpm.c ${srcdir}/../src/epaths.h
to say this instead:
addpm${EXEEXT}: ${srcdir}/addpm.c ../src/epaths.h
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-20 7:56 ` Eli Zaretskii
@ 2013-04-20 17:18 ` Dani Moncayo
2013-04-20 18:30 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-04-20 17:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
>> >> The packages I've installed (with "mingw-get install <package>"), in
>> >> addition to the ones installed by default, are:
>> >> * msys-base
>> >> * mingw-developer-toolkit
>> >> * msys-automake
>> >
>> > What do you mean by "installed by default"? If we want the
>> > instructions to be comprehensive, we need to spell out _all_ of the
>> > packages, including those installed by default.
>>
>> By "packages installed by default", I mean the packages that get
>> installed if you install MinGW (with the "mingw-get-inst-20120426.exe"
>> installer) and accept the default options in the wizard.
>>
>> Sorry, I've not found a way to get the list of installed packages
>> (AFAICT, the package manager currently lacks such a feature).
>
> That's OK; the above description about accepting the default options
> should be good enough. Could you provide a list of those default
> options, so I could list them in the instructions?
The wizard has several screens, one of which is titled "Select
Components". As its name suggests, that screen allows the user to
choose the initial components to install. By default, only the "C
Compiler" option (under "MinGW Compiler Suite") is checked.
>> make[1]: Entering directory `/c/emacs/build/nt'
>> windres -O coff -o emacs.res /c/emacs/mybranch/nt/emacs.rc
>> gcc -std=gnu99 -mtune=pentium4 -I. -I/c/emacs/mybranch/nt -mtune=pentium4 -DGLYPH_DEBUG=1 -DUSE_CRT_DLL=1 -I /c/emacs/mybranch/nt/inc -O0 -g3 /c/emacs/my branch/nt/runemacs.c emacs.res \
>> -o runemacs.exe
>> make[1]: *** No rule to make target `/c/emacs/mybranch/nt/../src/epaths.h', needed by `addpm.exe'. Stop.
>> make[1]: Leaving directory `/c/emacs/build/nt'
>> make: *** [nt] Error 2
>
> That's a bug in the opposite direction. Change this line in
> nt/Makefile.in:
>
> addpm${EXEEXT}: ${srcdir}/addpm.c ${srcdir}/../src/epaths.h
>
> to say this instead:
>
> addpm${EXEEXT}: ${srcdir}/addpm.c ../src/epaths.h
After doing that change and run "make" anew, the build process gets
stuck at this point:
Updating c:/emacs/build/leim/leim-list.el ...
c:/c/emacs/mybranch/leim doesn't have `quail' subdirectory, just ignored
Checking c:/emacs/build/leim/quail/ZOZY.el ...
Checking c:/emacs/build/leim/quail/ZIRANMA.el ...
Checking c:/emacs/build/leim/quail/tsang-cns.el ...
Checking c:/emacs/build/leim/quail/tsang-b5.el ...
Checking c:/emacs/build/leim/quail/TONEPY.el ...
Checking c:/emacs/build/leim/quail/SW.el ...
Checking c:/emacs/build/leim/quail/quick-cns.el ...
Checking c:/emacs/build/leim/quail/quick-b5.el ...
Checking c:/emacs/build/leim/quail/QJ.el ...
Checking c:/emacs/build/leim/quail/QJ-b5.el ...
Checking c:/emacs/build/leim/quail/PY.el ...
Checking c:/emacs/build/leim/quail/PY-b5.el ...
Checking c:/emacs/build/leim/quail/Punct.el ...
Checking c:/emacs/build/leim/quail/Punct-b5.el ...
Checking c:/emacs/build/leim/quail/ETZY.el ...
Checking c:/emacs/build/leim/quail/ECDICT.el ...
Checking c:/emacs/build/leim/quail/CTLau.el ...
Checking c:/emacs/build/leim/quail/CTLau-b5.el ...
Checking c:/emacs/build/leim/quail/CCDOSPY.el ...
Checking c:/emacs/build/leim/quail/ARRAY30.el ...
Checking c:/emacs/build/leim/quail/4Corner.el ...
I see no new input after a good while, and when I look at the task
manager, I see a process called "bootstrap-emacs.exe" that is taking a
constant portion of 25% of the CPU time.
I've cancelled the build process after more than 47 minutes. :(
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-20 17:18 ` Dani Moncayo
@ 2013-04-20 18:30 ` Eli Zaretskii
2013-04-20 20:21 ` Dani Moncayo
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-20 18:30 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Sat, 20 Apr 2013 19:18:31 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> Checking c:/emacs/build/leim/quail/ARRAY30.el ...
> Checking c:/emacs/build/leim/quail/4Corner.el ...
>
>
> I see no new input after a good while, and when I look at the task
> manager, I see a process called "bootstrap-emacs.exe" that is taking a
> constant portion of 25% of the CPU time.
>
> I've cancelled the build process after more than 47 minutes. :(
I think I see the problem. Try replacing this line from
leim/Makefile.in:
--eval "(update-leim-list-file \".\" \"${srcdir}\")" ; \
with this:
--eval "(update-leim-list-file \".\" (reveal-filename \"${srcdir}\"))" ; \
and also add the following function to subr.el:
(defun reveal-filename (file)
"Produce the real file name for FILE.
On systems other than MS-Windows, just returns FILE.
On MS-Windows, converts /d/foo/bar form of file names
passed by MSYS Make into d:/foo/bar that Emacs can grok.
This function is called from lisp/Makefile."
(when (and (eq system-type 'windows-nt)
(string-match "\\`/[a-zA-Z]/" file))
(setq file (concat (substring file 1 2) ":" (substring file 2))))
file)
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-20 18:30 ` Eli Zaretskii
@ 2013-04-20 20:21 ` Dani Moncayo
2013-04-21 15:12 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-04-20 20:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
>> Checking c:/emacs/build/leim/quail/ARRAY30.el ...
>> Checking c:/emacs/build/leim/quail/4Corner.el ...
>>
>>
>> I see no new input after a good while, and when I look at the task
>> manager, I see a process called "bootstrap-emacs.exe" that is taking a
>> constant portion of 25% of the CPU time.
>>
>> I've cancelled the build process after more than 47 minutes. :(
>
> I think I see the problem. Try replacing this line from
> leim/Makefile.in:
>
> --eval "(update-leim-list-file \".\" \"${srcdir}\")" ; \
>
> with this:
>
> --eval "(update-leim-list-file \".\" (reveal-filename \"${srcdir}\"))" ; \
>
> and also add the following function to subr.el:
>
> (defun reveal-filename (file)
> "Produce the real file name for FILE.
>
> On systems other than MS-Windows, just returns FILE.
> On MS-Windows, converts /d/foo/bar form of file names
> passed by MSYS Make into d:/foo/bar that Emacs can grok.
>
> This function is called from lisp/Makefile."
> (when (and (eq system-type 'windows-nt)
> (string-match "\\`/[a-zA-Z]/" file))
> (setq file (concat (substring file 1 2) ":" (substring file 2))))
> file)
With the above changes, "make" now completes its work successfully. (good!)
I've also done a "make install", and it has been successful too, apparently.
I've done a quick test, and the newly built Emacs seems to work well.
The only strange thing I've noticed so far is that double-clicking on
"runemacs.exe" brings up the Emacs frame, but the text terminal is
also visible, exactly as if I were clicked on "emacs.exe" instead of
"runemacs.exe".
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-20 20:21 ` Dani Moncayo
@ 2013-04-21 15:12 ` Eli Zaretskii
2013-04-21 19:53 ` Dani Moncayo
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-04-21 15:12 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Sat, 20 Apr 2013 22:21:36 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> I've done a quick test, and the newly built Emacs seems to work well.
> The only strange thing I've noticed so far is that double-clicking on
> "runemacs.exe" brings up the Emacs frame, but the text terminal is
> also visible, exactly as if I were clicked on "emacs.exe" instead of
> "runemacs.exe".
This should fix that:
=== modified file 'nt/Makefile.in'
--- nt/Makefile.in 2013-04-20 07:59:36 +0000
+++ nt/Makefile.in 2013-04-21 15:08:33 +0000
@@ -205,7 +205,7 @@ cmdproxy${EXEEXT}: ${srcdir}/cmdproxy.c
$(CC) ${ALL_CFLAGS} ${srcdir}/cmdproxy.c -o cmdproxy${EXEEXT}
runemacs${EXEEXT}: ${srcdir}/runemacs.c $(EMACSRES)
- $(CC) ${ALL_CFLAGS} ${srcdir}/runemacs.c $(EMACSRES) \
+ $(CC) ${ALL_CFLAGS} ${srcdir}/runemacs.c $(EMACSRES) -mwindows \
-o runemacs${EXEEXT}
emacs.res: ${srcdir}/emacs.rc ${srcdir}/icons/emacs.ico ${srcdir}/$(EMACS_MANIFEST)
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-21 15:12 ` Eli Zaretskii
@ 2013-04-21 19:53 ` Dani Moncayo
2013-05-01 15:30 ` Dani Moncayo
0 siblings, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-04-21 19:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
>> I've done a quick test, and the newly built Emacs seems to work well.
>> The only strange thing I've noticed so far is that double-clicking on
>> "runemacs.exe" brings up the Emacs frame, but the text terminal is
>> also visible, exactly as if I was clicked on "emacs.exe" instead of
>> "runemacs.exe".
>
> This should fix that:
>
> === modified file 'nt/Makefile.in'
> --- nt/Makefile.in 2013-04-20 07:59:36 +0000
> +++ nt/Makefile.in 2013-04-21 15:08:33 +0000
> @@ -205,7 +205,7 @@ cmdproxy${EXEEXT}: ${srcdir}/cmdproxy.c
> $(CC) ${ALL_CFLAGS} ${srcdir}/cmdproxy.c -o cmdproxy${EXEEXT}
>
> runemacs${EXEEXT}: ${srcdir}/runemacs.c $(EMACSRES)
> - $(CC) ${ALL_CFLAGS} ${srcdir}/runemacs.c $(EMACSRES) \
> + $(CC) ${ALL_CFLAGS} ${srcdir}/runemacs.c $(EMACSRES) -mwindows \
> -o runemacs${EXEEXT}
>
> emacs.res: ${srcdir}/emacs.rc ${srcdir}/icons/emacs.ico ${srcdir}/$(EMACS_MANIFEST)
Yes, the above patch fixes the problem.
Thank you!
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-04-21 19:53 ` Dani Moncayo
@ 2013-05-01 15:30 ` Dani Moncayo
2013-05-01 16:30 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-05-01 15:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
Hello Eli,
I've been trying to build the latest trunk (plus your patch) from my
MSYS environment, with support for the libraries I use to successfully
include in my w32 builds (configured with "configure.bat"): XPM, JPEG,
TIFF, GIF, PNG, GNUTLS and XML.
The configure script successfully detects them, except for the last
two (GNUTLS and XML), and for now I've failed to see what the problem
is.
I'm invoking the configure script from a clean "build" directory, and
this is the last call I've tried (I've also tried other combinations):
$ CPPFLAGS='-DGLYPH_DEBUG=1 -Ic:/usr/include/gnutls
-Ic:/usr/include/noX -Ic:/usr/include' CFLAGS='-O0 -g3'
../mybranch/nt/msysconfig.sh --prefix=c:/usr --enable-checking
I'm attaching the "config.log" file generated.
Please could you help me? Do you see what I'm doing wrong or where is
the problem now?
TIA
--
Dani Moncayo
[-- Attachment #2: config.zip --]
[-- Type: application/zip, Size: 41751 bytes --]
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-01 15:30 ` Dani Moncayo
@ 2013-05-01 16:30 ` Eli Zaretskii
2013-05-01 19:30 ` Dani Moncayo
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-01 16:30 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Wed, 1 May 2013 17:30:28 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> I've been trying to build the latest trunk (plus your patch) from my
> MSYS environment, with support for the libraries I use to successfully
> include in my w32 builds (configured with "configure.bat"): XPM, JPEG,
> TIFF, GIF, PNG, GNUTLS and XML.
>
> The configure script successfully detects them, except for the last
> two (GNUTLS and XML), and for now I've failed to see what the problem
> is.
I think it's because you didn't install pkg-config, or maybe it is not
on PATH. The configure script uses it (for some of the optional
libraries, not for all of them) to find out which compiler and linker
switches to use for each of these packages. And configure thinks you
don't have pkg-config, as this fragment from config.log shows:
configure:8730: checking for pkg-config
configure:8761: result: no
Without pkg-config, configure uses the wrong compiler switches to try
compiling test programs, which therefore fail, causing the configure
script to decide you don't have these libraries.
You can find a URL from which you can download pkg-config in
INSTALL.MSYS. Note: this is a native Windows port, so install it in
the MinGW tree, not in the MSYS tree.
Also note that when you install GnuTLS and libxml2 from my ports, they
also install *.pc files in lib/pkg-config/. These are the files that
pkg-config will consult when the configure script invokes it.
Therefore, I suggest that you keep the directory tree in my zip files
intact, or else you will need to manually edit these *.pc files to
match your installation. I'm saying that because this:
> $ CPPFLAGS='-DGLYPH_DEBUG=1 -Ic:/usr/include/gnutls
> -Ic:/usr/include/noX -Ic:/usr/include' CFLAGS='-O0 -g3'
> ../mybranch/nt/msysconfig.sh --prefix=c:/usr --enable-checking
clearly shows that you moved the GnuTLS headers into
usr/include/gnutls, which is not what gnutls.pc file says. Likewise
with the lib*.a static and import libraries: you need to have them in
the same place where the corresponding .pc says they can be found.
As I wrote in INSTALL.MSYS, I suggest to install everything into a
single tree, preserving the directories recorded in the zip. Just
unzip everything from the same parent directory, and you should be
fine.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-01 16:30 ` Eli Zaretskii
@ 2013-05-01 19:30 ` Dani Moncayo
2013-05-01 19:40 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-05-01 19:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
>> I've been trying to build the latest trunk (plus your patch) from my
>> MSYS environment, with support for the libraries I use to successfully
>> include in my w32 builds (configured with "configure.bat"): XPM, JPEG,
>> TIFF, GIF, PNG, GNUTLS and XML.
>>
>> The configure script successfully detects them, except for the last
>> two (GNUTLS and XML), and for now I've failed to see what the problem
>> is.
>
> I think it's because you didn't install pkg-config, or maybe it is not
> on PATH. The configure script uses it (for some of the optional
> libraries, not for all of them) to find out which compiler and linker
> switches to use for each of these packages. And configure thinks you
> don't have pkg-config, as this fragment from config.log shows:
>
> configure:8730: checking for pkg-config
> configure:8761: result: no
>
> Without pkg-config, configure uses the wrong compiler switches to try
> compiling test programs, which therefore fail, causing the configure
> script to decide you don't have these libraries.
>
> You can find a URL from which you can download pkg-config in
> INSTALL.MSYS. Note: this is a native Windows port, so install it in
> the MinGW tree, not in the MSYS tree.
Indeed, I didn't have pkg-config installed, sorry (I thought that the
packages auto-installed by mingw-get were enough already).
I've downloaded and installed that package, and the configure script
does find it:
configure:8730: checking for pkg-config
configure:8748: found /c/usr/bin/pkg-config
configure:8761: result: /c/usr/bin/pkg-config
> Also note that when you install GnuTLS and libxml2 from my ports, they
> also install *.pc files in lib/pkg-config/. These are the files that
> pkg-config will consult when the configure script invokes it.
> Therefore, I suggest that you keep the directory tree in my zip files
> intact, or else you will need to manually edit these *.pc files to
> match your installation. I'm saying that because this:
>
>> $ CPPFLAGS='-DGLYPH_DEBUG=1 -Ic:/usr/include/gnutls
>> -Ic:/usr/include/noX -Ic:/usr/include' CFLAGS='-O0 -g3'
>> ../mybranch/nt/msysconfig.sh --prefix=c:/usr --enable-checking
>
> clearly shows that you moved the GnuTLS headers into
> usr/include/gnutls, which is not what gnutls.pc file says. Likewise
> with the lib*.a static and import libraries: you need to have them in
> the same place where the corresponding .pc says they can be found.
No, I didn't move any file of the libraries or packages from their
original position in the zip files. I just tried to pass that path
(c:/usr/include/gnutls) to the compiler as a desperate attempt to
solve the configure problem.
> As I wrote in INSTALL.MSYS, I suggest to install everything into a
> single tree, preserving the directories recorded in the zip. Just
> unzip everything from the same parent directory, and you should be
> fine.
Yes, that is what I did for the libraries and packages installed
manually: I uncompressed the zip files under one common parent
directory (c:/usr).
In fact, after installing pkg-config, the configure script now finds
the libxml library:
configure:13773: checking for libxml-2.0 > 2.6.17
configure:13787: result: yes CFLAGS='-Ic:/usr/include/libxml2 '
LIBS='-Lc:/usr/lib -lxml2 '
... but it still does not find a correct gnutls library:
configure:11727: checking for gnutls >= 2.6.6
Package p11-kit-1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `p11-kit-1.pc'
to the PKG_CONFIG_PATH environment variable
Package 'p11-kit-1', required by 'GnuTLS', not found
configure:11745: result: no
configure:11782: checking for gnutls_certificate_set_verify_function
configure:11782: gcc -I /c/emacs/mybranch/nt/inc -std=gnu99 -o
conftest.exe -O0 -g3 -mtune=pentium4 -DGLYPH_DEBUG=1
-Ic:/usr/include/noX -Ic:/usr/include conftest.c >&5
C:\Users\dani\AppData\Local\Temp\ccGHYX1K.o: In function `main':
c:\emacs\build/conftest.c:87: undefined reference to
`gnutls_certificate_set_verify_function'
collect2.exe: error: ld returned 1 exit status
configure:11782: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "emacs"
[...]
| #endif
|
| int
| main ()
| {
| return gnutls_certificate_set_verify_function ();
| ;
| return 0;
| }
configure:11782: result: no
After seeing the error messages, I installed the "p11-kit" package
(from your site "http://sourceforge.net/projects/ezwinports") and now
the configure script finally does find the gnutls library:
configure:11727: checking for gnutls >= 2.6.6
configure:11741: result: yes CFLAGS='-Ic:/usr/include
-Ic:/usr/include/p11-kit-1 ' LIBS='-Lc:/usr/lib -lgnutls '
configure:11782: checking for gnutls_certificate_set_verify_function
configure:11782: gcc -I /c/emacs/mybranch/nt/inc -std=gnu99 -o
conftest.exe -O0 -g3 -Ic:/usr/include -Ic:/usr/include/p11-kit-1
-mtune=pentium4 -DGLYPH_DEBUG=1 -Ic:/usr/include/noX -Ic:/usr/include
conftest.c -Lc:/usr/lib -lgnutls >&5
configure:11782: $? = 0
configure:11782: result: yes
Thank you so much for your help.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-01 19:30 ` Dani Moncayo
@ 2013-05-01 19:40 ` Eli Zaretskii
2013-05-02 6:43 ` Dani Moncayo
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-01 19:40 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Wed, 1 May 2013 21:30:44 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> Indeed, I didn't have pkg-config installed, sorry (I thought that the
> packages auto-installed by mingw-get were enough already).
pkg-config is not a MinGW package, so mingw-get knows nothing about
it.
> > Also note that when you install GnuTLS and libxml2 from my ports, they
> > also install *.pc files in lib/pkg-config/. These are the files that
> > pkg-config will consult when the configure script invokes it.
> > Therefore, I suggest that you keep the directory tree in my zip files
> > intact, or else you will need to manually edit these *.pc files to
> > match your installation. I'm saying that because this:
> >
> >> $ CPPFLAGS='-DGLYPH_DEBUG=1 -Ic:/usr/include/gnutls
> >> -Ic:/usr/include/noX -Ic:/usr/include' CFLAGS='-O0 -g3'
> >> ../mybranch/nt/msysconfig.sh --prefix=c:/usr --enable-checking
> >
> > clearly shows that you moved the GnuTLS headers into
> > usr/include/gnutls, which is not what gnutls.pc file says. Likewise
> > with the lib*.a static and import libraries: you need to have them in
> > the same place where the corresponding .pc says they can be found.
>
> No, I didn't move any file of the libraries or packages from their
> original position in the zip files. I just tried to pass that path
> (c:/usr/include/gnutls) to the compiler as a desperate attempt to
> solve the configure problem.
Then don't do that, because it's wrong. The include directives in the
C sources say something like
#include <gnutls/foo.h>
so if you add -Ic:/usr/include/gnutls to the compiler switches, the
compiler will look for c:/usr/include/gnutls/gnutls/foo.h, which
doesn't exist.
> After seeing the error messages, I installed the "p11-kit" package
> (from your site "http://sourceforge.net/projects/ezwinports") and now
> the configure script finally does find the gnutls library:
Great. I added a few details to INSTALL.MSYS, so that others could
avoid similar pitfalls.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-01 19:40 ` Eli Zaretskii
@ 2013-05-02 6:43 ` Dani Moncayo
2013-05-02 16:19 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-05-02 6:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
>> Indeed, I didn't have pkg-config installed, sorry (I thought that the
>> packages auto-installed by mingw-get were enough already).
>
> pkg-config is not a MinGW package, so mingw-get knows nothing about
> it.
Do you mean that "pkg-config" is a MSYS package (as opposed to being a
MinGW package)? In that case, it might be installed (or uninstalled)
with mingw-get (if it was included in the package repository), because
the package manager handles both MinGW and MSYS packages.
I have two more questions:
Manually installing a package consists of just expanding the
compressed file under a suitable directory. But then, how can someone
remove (or replace with a newer version) one package installed in such
way?
How can someone make a binary distribution of Emacs for Windows, using
the new MSYS build system?
TIA.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-02 6:43 ` Dani Moncayo
@ 2013-05-02 16:19 ` Eli Zaretskii
2013-05-02 18:40 ` Dani Moncayo
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-02 16:19 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Thu, 2 May 2013 08:43:19 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> >> Indeed, I didn't have pkg-config installed, sorry (I thought that the
> >> packages auto-installed by mingw-get were enough already).
> >
> > pkg-config is not a MinGW package, so mingw-get knows nothing about
> > it.
>
> Do you mean that "pkg-config" is a MSYS package (as opposed to being a
> MinGW package)?
No, I mean that it's neither MinGW nor MSYS. It's a 3rd-party Windows
port. So mingw-get doesn't support it, as it doesn't support, for
example, my ports.
> Manually installing a package consists of just expanding the
> compressed file under a suitable directory. But then, how can someone
> remove (or replace with a newer version) one package installed in such
> way?
I never needed to uninstall a package; if I did, I'd probably make a
list of files from its zip listing, and then prepare a script that
would remove all the files in the list, except *.dll files and
share/info/dir.
To install a newer version, just unzip it. I normally do it
interactively, to be able to decide individually whether to overwrite
each file (important especially for DLLs and info/dir again), but you
can also say "unzip -o" and overwrite them all.
> How can someone make a binary distribution of Emacs for Windows, using
> the new MSYS build system?
make install prefix=WHEREVER
where WHEREVER doesn't exist, and then go to WHEREVER and create an
archive from the entire tree starting at it.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-02 16:19 ` Eli Zaretskii
@ 2013-05-02 18:40 ` Dani Moncayo
2013-05-02 19:49 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-05-02 18:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
[-- Attachment #1: Type: text/plain, Size: 703 bytes --]
Hi Eli,
I've just noticed a strange thing while using the build made with MSYS:
If I do `C-h i', the info directory lacks many entries which are
available from the other (old) build.
For example, the Emacs manual is not listed in the directory, but `C-h
r' still opens it.
I'm attaching:
* "info-top-new": contents of the Info directory buffer, from the new
(MSYS) Emacs build.
* "info-top-old": The same, but from the old (non-MSYS) Emacs build.
* "make-install.log": Output of the "make install" command which
generated the MSYS build. It contains some suspicious messages which
might be related to this problem (search for "install-info:").
If you need more info, let me know.
--
Dani Moncayo
[-- Attachment #2: data.zip --]
[-- Type: application/zip, Size: 22401 bytes --]
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-02 18:40 ` Dani Moncayo
@ 2013-05-02 19:49 ` Eli Zaretskii
2013-05-02 21:42 ` Dani Moncayo
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-02 19:49 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Thu, 2 May 2013 20:40:10 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> I've just noticed a strange thing while using the build made with MSYS:
>
> If I do `C-h i', the info directory lacks many entries which are
> available from the other (old) build.
Yes, because your install-info barfed.
> For example, the Emacs manual is not listed in the directory, but `C-h
> r' still opens it.
"C-h r" goes directly to the manual, it doesn't need the directory
node.
> (cd ${thisdir}; \
> /bin/install-info --info-dir=c:/usr/share/info c:/usr/share/info/$elt); \
> done)
> install-info: No such file or directory for /usr/share/info/emacs.info
> install-info: No such file or directory for /usr/share/info/eintr.info
You installed the MSYS Texinfo package, didn't you? My guess is that
it doesn't support compressed Info files, so it thinks they are not
there. What does "install-info --version" say in the MSYS Bash
window?
If nothing gives a clue, I suggest to uninstall the MSYS Texinfo
package and install the MinGW port of Texinfo from my site instead.
That's what I used. If you decide to go this way, make sure you also
have a MinGW gzip.
In any case, just copying info/dir from the source tree should restore
your lost entries.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-02 19:49 ` Eli Zaretskii
@ 2013-05-02 21:42 ` Dani Moncayo
2013-05-02 21:43 ` Dani Moncayo
2013-05-03 8:50 ` Eli Zaretskii
0 siblings, 2 replies; 116+ messages in thread
From: Dani Moncayo @ 2013-05-02 21:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
>> (cd ${thisdir}; \
>> /bin/install-info --info-dir=c:/usr/share/info c:/usr/share/info/$elt); \
>> done)
>> install-info: No such file or directory for /usr/share/info/emacs.info
>> install-info: No such file or directory for /usr/share/info/eintr.info
>
> You installed the MSYS Texinfo package, didn't you?
Not explicitly. I think it is part of the `msys-info' package.
BTW, that is the only Texinfo I've ever used, even for producing the
info files whenever I've bootstrapped Emacs.
> My guess is that
> it doesn't support compressed Info files, so it thinks they are not
> there. What does "install-info --version" say in the MSYS Bash
> window?
$ install-info --version
install-info (GNU texinfo) 4.13
> If nothing gives a clue, I suggest to uninstall the MSYS Texinfo
> package and install the MinGW port of Texinfo from my site instead.
> That's what I used. If you decide to go this way, make sure you also
> have a MinGW gzip.
ok, I'll try it if I don't see where is the problem with my MSYS Texinfo.
Thanks.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-02 21:42 ` Dani Moncayo
@ 2013-05-02 21:43 ` Dani Moncayo
2013-05-03 8:50 ` Eli Zaretskii
1 sibling, 0 replies; 116+ messages in thread
From: Dani Moncayo @ 2013-05-02 21:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
>> You installed the MSYS Texinfo package, didn't you?
>
> Not explicitly. I think it is part of the `msys-info' package.
^^^^^^^^^
I meant "msys-base", sorry.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-02 21:42 ` Dani Moncayo
2013-05-02 21:43 ` Dani Moncayo
@ 2013-05-03 8:50 ` Eli Zaretskii
2013-05-04 10:59 ` Dani Moncayo
1 sibling, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-03 8:50 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Thu, 2 May 2013 23:42:08 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> > You installed the MSYS Texinfo package, didn't you?
>
> Not explicitly. I think it is part of the `msys-info' package.
>
> BTW, that is the only Texinfo I've ever used, even for producing the
> info files whenever I've bootstrapped Emacs.
>
> > My guess is that
> > it doesn't support compressed Info files, so it thinks they are not
> > there. What does "install-info --version" say in the MSYS Bash
> > window?
>
> $ install-info --version
> install-info (GNU texinfo) 4.13
Strange, v4.13 does support compressed Info files. Perhaps try
invoking it from the command line, and see if it reports any errors.
> > If nothing gives a clue, I suggest to uninstall the MSYS Texinfo
> > package and install the MinGW port of Texinfo from my site instead.
> > That's what I used. If you decide to go this way, make sure you also
> > have a MinGW gzip.
>
> ok, I'll try it if I don't see where is the problem with my MSYS Texinfo.
Alternatively, you could say
make install GZIP_INFO=
in which case the Info files will not be compressed, and install-info
should be happy even if it doesn't support compressed files.
Installing without compressing Info files might be a good idea anyway,
since a previous discussion seemed to indicate Windows users won't
like them compressed. If you also want not to compress Lisp files,
add GZIP_PROG= to the above command line.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-03 8:50 ` Eli Zaretskii
@ 2013-05-04 10:59 ` Dani Moncayo
2013-05-04 11:04 ` Dani Moncayo
2013-05-04 11:27 ` Eli Zaretskii
0 siblings, 2 replies; 116+ messages in thread
From: Dani Moncayo @ 2013-05-04 10:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
>> > You installed the MSYS Texinfo package, didn't you?
>>
>> Not explicitly. I think it is part of the `msys-base' package.
>>
>> BTW, that is the only Texinfo I've ever used, even for producing the
>> info files whenever I've bootstrapped Emacs.
>>
>> > My guess is that
>> > it doesn't support compressed Info files, so it thinks they are not
>> > there. What does "install-info --version" say in the MSYS Bash
>> > window?
>>
>> $ install-info --version
>> install-info (GNU texinfo) 4.13
>
> Strange, v4.13 does support compressed Info files. Perhaps try
> invoking it from the command line, and see if it reports any errors.
I've found the problem and one solution.
Error messages like this one:
install-info: No such file or directory for /usr/share/info/emacs.info
suggested that this command from the Makefile:
/bin/install-info --info-dir=c:/usr/share/info c:/usr/share/info/$elt
was failing because, the shell was passing the argument
"/usr/share/info/XXXX" to the program instead of the intended
"c:/usr/share/info/XXXX", and "/usr/share/info/XXXX" is a different
path which references to a non-existent file.
I've tried to use the UNIX-like path: "make install prefix=/c/usr" and
it solved the problem.
This seems to suggest that, from the MSYS bash, it is safer to use the
UNIX-like paths instead of the Windows native ones.
I've also repeated the whole configuration using exclusively UNIX-like paths:
$ CPPFLAGS='-DGLYPH_DEBUG=1 -I/c/include' CFLAGS='-O0 -g3'
../mybranch/nt/msysconfig.sh --prefix=/c/usr --enable-checking
It worked fine, and "make && make install" worked fine too.
The resulting Emacs has a complete info directory. Good!!
There remains a minor annoyance, though: the info directory (attached
to this mail) has some parts with DOS-type EOLs an other parts with
UNIX-type EOLs. Therefore, my Emacs shows some annoying "^M" chars.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-04 10:59 ` Dani Moncayo
@ 2013-05-04 11:04 ` Dani Moncayo
2013-05-04 11:27 ` Eli Zaretskii
1 sibling, 0 replies; 116+ messages in thread
From: Dani Moncayo @ 2013-05-04 11:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
[-- Attachment #1: Type: text/plain, Size: 339 bytes --]
> I've also repeated the whole configuration using exclusively UNIX-like paths:
> $ CPPFLAGS='-DGLYPH_DEBUG=1 -I/c/include' CFLAGS='-O0 -g3'
^^^^^^^^^^
I meant "-I/c/usr/include".
> ... the info directory (attached to this mail) ...
I forgot to attach it. I'm doing it now. Sorry.
--
Dani Moncayo
[-- Attachment #2: dir --]
[-- Type: application/octet-stream, Size: 6060 bytes --]
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-04 10:59 ` Dani Moncayo
2013-05-04 11:04 ` Dani Moncayo
@ 2013-05-04 11:27 ` Eli Zaretskii
2013-05-04 12:00 ` Dani Moncayo
1 sibling, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-04 11:27 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Sat, 4 May 2013 12:59:57 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> Error messages like this one:
> install-info: No such file or directory for /usr/share/info/emacs.info
>
> suggested that this command from the Makefile:
> /bin/install-info --info-dir=c:/usr/share/info c:/usr/share/info/$elt
>
> was failing because, the shell was passing the argument
> "/usr/share/info/XXXX" to the program instead of the intended
> "c:/usr/share/info/XXXX", and "/usr/share/info/XXXX" is a different
> path which references to a non-existent file.
Ah, OK. I guess MSYS modified your c:/usr/share/info into
/usr/share/info because your Texinfo is an MSYS package.
> I've tried to use the UNIX-like path: "make install prefix=/c/usr" and
> it solved the problem.
>
> This seems to suggest that, from the MSYS bash, it is safer to use the
> UNIX-like paths instead of the Windows native ones.
That depends, see above. In general, MSYS is supposed to support
both styles alike; anything else is a bug in MSYS.
> There remains a minor annoyance, though: the info directory (attached
> to this mail) has some parts with DOS-type EOLs an other parts with
> UNIX-type EOLs. Therefore, my Emacs shows some annoying "^M" chars.
Looks like the lines in info/dir which came from the original file in
the source tree (which has Unix-style EOLs) are copied verbatim, while
other lines have DOS EOLs.
Does the same happen if you invoke install-info manually?
I think the cause of this is that MSYS programs use binary I/O mode,
so they output the lines with whatever EOL format they happened to
have in their source files.
(Using the native port of makeinfo, I don't have this problem.)
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-04 11:27 ` Eli Zaretskii
@ 2013-05-04 12:00 ` Dani Moncayo
2013-05-04 12:30 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-05-04 12:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
[-- Attachment #1: Type: text/plain, Size: 866 bytes --]
>> There remains a minor annoyance, though: the info directory (attached
>> to this mail) has some parts with DOS-type EOLs an other parts with
>> UNIX-type EOLs. Therefore, my Emacs shows some annoying "^M" chars.
>
> Looks like the lines in info/dir which came from the original file in
> the source tree (which has Unix-style EOLs) are copied verbatim, while
> other lines have DOS EOLs.
>
> Does the same happen if you invoke install-info manually?
Well, I've just tried this:
1. Remove the current info directory file (c:/usr/share/info/dir).
2. From bash, execute the command (taken from the Makefile) to re-generate it:
/bin/install -c -m 644 /c/emacs/mybranch/info/dir /c/usr/share/info/dir
This generates an info directory file which has only UNIX-type EOLs,
and which also has a bit different contents (I'm attaching both
versions).
--
Dani Moncayo
[-- Attachment #2: tmp.zip --]
[-- Type: application/zip, Size: 4695 bytes --]
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-04 12:00 ` Dani Moncayo
@ 2013-05-04 12:30 ` Eli Zaretskii
2013-05-07 19:36 ` Dani Moncayo
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-04 12:30 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Sat, 4 May 2013 14:00:01 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> 1. Remove the current info directory file (c:/usr/share/info/dir).
> 2. From bash, execute the command (taken from the Makefile) to re-generate it:
>
> /bin/install -c -m 644 /c/emacs/mybranch/info/dir /c/usr/share/info/dir
>
> This generates an info directory file which has only UNIX-type EOLs,
> and which also has a bit different contents (I'm attaching both
> versions).
But that's not the issue. The issue is not with /bin/install, which
basically just copies its argument files, the issue is with
/bin/install-info, which _modifies_ c:/usr/share/info/dir by reading
the Info files, which were copied:
cd ${srcdir}/info ; \
for elt in ${INFO_NONMISC} $${info_misc}; do \
test "$(HAVE_MAKEINFO)" = "no" && test ! -f $$elt && continue; \
for f in `ls $$elt $$elt-[1-9] $$elt-[1-9][0-9] 2>/dev/null`; do \
(cd $${thisdir}; \
${INSTALL_DATA} ${srcdir}/info/$$f $(DESTDIR)${infodir}/$$f); \
( [ -n "${GZIP_INFO}" ] && [ -n "${GZIP_PROG}" ] ) || continue ; \
rm -f $(DESTDIR)${infodir}/$$f.gz; \
${GZIP_PROG} -9n $(DESTDIR)${infodir}/$$f; \
done; \
(cd $${thisdir}; \
${INSTALL_INFO} --info-dir=$(DESTDIR)${infodir} $(DESTDIR)${infodir}/$$elt); \
done)
That's why you get a different DIR file: because install-info was not
invoked.
Perhaps try installing Info files without compressing them, like this:
make install prefix=/c/usr GZIP_INFO=
Maybe the problem with EOL format only happens when install-info
invokes gzip to decompress the files.
Failing that, I see no other alternative but to use a native port of
Texinfo.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-04 12:30 ` Eli Zaretskii
@ 2013-05-07 19:36 ` Dani Moncayo
2013-05-07 21:13 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-05-07 19:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
For the record: On my laptop (Intel Core i5-2410 CPU @ 2.3 GHz),
bootstraping Emacs on MS-Windows used to take about 15 minutes. With
the new (not yet committed to trunk) MSYS-based build system, that
time is reduced by a factor of 4 to 5:
real 3m25.157s
user 0m48.021s
sys 2m40.234s
Amazing!
BTW, Eli, when do you plan to commit this to the trunk?
Thanks
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-07 19:36 ` Dani Moncayo
@ 2013-05-07 21:13 ` Eli Zaretskii
2013-05-07 22:04 ` Dani Moncayo
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-07 21:13 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Tue, 7 May 2013 21:36:33 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> BTW, Eli, when do you plan to commit this to the trunk?
Soon. What's the final word about MSYS Texinfo and mixed EOLs?
Should I recommend to install a MinGW port instead?
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-07 21:13 ` Eli Zaretskii
@ 2013-05-07 22:04 ` Dani Moncayo
2013-05-08 17:09 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-05-07 22:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
> What's the final word about MSYS Texinfo and mixed EOLs?
The only new information I have about this issue is that today, after
doing a whole bootstrap and a "make install" (with my MSYS Texinfo, as
always), the resulting Info directory looks good (it has only
UNIX-type EOLs).
I'm thinking that probably this problem appears when, at the time you
do a "make install", your PREFIX/share/info directory already has some
info manuals with DOS-type EOLs. (For example, the GnuTLS library I
downloaded from ezwinports has an info manual with DOS-type EOLs)
I think that the other day, while testing things, I deleted all the
files in PREFIX/share/info, and therefore now all the info manuals are
the installed with Emacs, and they have all the same EOL-type: UNIX.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-07 22:04 ` Dani Moncayo
@ 2013-05-08 17:09 ` Eli Zaretskii
2013-05-08 17:32 ` Dani Moncayo
2013-05-13 12:23 ` Andy Moreton
0 siblings, 2 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-08 17:09 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel
> Date: Wed, 8 May 2013 00:04:45 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> > What's the final word about MSYS Texinfo and mixed EOLs?
>
> The only new information I have about this issue is that today, after
> doing a whole bootstrap and a "make install" (with my MSYS Texinfo, as
> always), the resulting Info directory looks good (it has only
> UNIX-type EOLs).
>
> I'm thinking that probably this problem appears when, at the time you
> do a "make install", your PREFIX/share/info directory already has some
> info manuals with DOS-type EOLs. (For example, the GnuTLS library I
> downloaded from ezwinports has an info manual with DOS-type EOLs)
>
> I think that the other day, while testing things, I deleted all the
> files in PREFIX/share/info, and therefore now all the info manuals are
> the installed with Emacs, and they have all the same EOL-type: UNIX.
But then the problem is not really solved: anyone who would install
Emacs into an already populated tree will get the mixed EOLs issue
back.
Thanks.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-08 17:09 ` Eli Zaretskii
@ 2013-05-08 17:32 ` Dani Moncayo
2013-05-13 12:23 ` Andy Moreton
1 sibling, 0 replies; 116+ messages in thread
From: Dani Moncayo @ 2013-05-08 17:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs development discussions
> But then the problem is not really solved: anyone who would install
> Emacs into an already populated tree will get the mixed EOLs issue
> back.
Indeed.
So, IMO, the proper fix for this should be applied to Texinfo (either
the MSYS port, the native Windows port or any other port): it should
be prepared for managing info manuals with different EOL formats while
creating/updating the info directory, so that the info directory never
ends up with a mix of formats.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-08 17:09 ` Eli Zaretskii
2013-05-08 17:32 ` Dani Moncayo
@ 2013-05-13 12:23 ` Andy Moreton
2013-05-13 16:23 ` Eli Zaretskii
1 sibling, 1 reply; 116+ messages in thread
From: Andy Moreton @ 2013-05-13 12:23 UTC (permalink / raw)
To: emacs-devel
On Wed 08 May 2013, Eli Zaretskii wrote:
>> Date: Wed, 8 May 2013 00:04:45 +0200
>> From: Dani Moncayo <dmoncayo@gmail.com>
>> Cc: Emacs development discussions <emacs-devel@gnu.org>
>>
>> > What's the final word about MSYS Texinfo and mixed EOLs?
>>
>> The only new information I have about this issue is that today, after
>> doing a whole bootstrap and a "make install" (with my MSYS Texinfo, as
>> always), the resulting Info directory looks good (it has only
>> UNIX-type EOLs).
>>
>> I'm thinking that probably this problem appears when, at the time you
>> do a "make install", your PREFIX/share/info directory already has some
>> info manuals with DOS-type EOLs. (For example, the GnuTLS library I
>> downloaded from ezwinports has an info manual with DOS-type EOLs)
>>
>> I think that the other day, while testing things, I deleted all the
>> files in PREFIX/share/info, and therefore now all the info manuals are
>> the installed with Emacs, and they have all the same EOL-type: UNIX.
>
> But then the problem is not really solved: anyone who would install
> Emacs into an already populated tree will get the mixed EOLs issue
> back.
Hi Eli,
This sounds like its a minor enough issue that it could be solved after
the changes are committed. If you are not comfortable doing that yet,
could you please post the latest version of your patch so I can help
test it ?
AndyM
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-13 12:23 ` Andy Moreton
@ 2013-05-13 16:23 ` Eli Zaretskii
2013-05-16 6:00 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-13 16:23 UTC (permalink / raw)
To: Andy Moreton; +Cc: emacs-devel
> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Mon, 13 May 2013 13:23:30 +0100
>
> >> The only new information I have about this issue is that today, after
> >> doing a whole bootstrap and a "make install" (with my MSYS Texinfo, as
> >> always), the resulting Info directory looks good (it has only
> >> UNIX-type EOLs).
> >>
> >> I'm thinking that probably this problem appears when, at the time you
> >> do a "make install", your PREFIX/share/info directory already has some
> >> info manuals with DOS-type EOLs. (For example, the GnuTLS library I
> >> downloaded from ezwinports has an info manual with DOS-type EOLs)
> >>
> >> I think that the other day, while testing things, I deleted all the
> >> files in PREFIX/share/info, and therefore now all the info manuals are
> >> the installed with Emacs, and they have all the same EOL-type: UNIX.
> >
> > But then the problem is not really solved: anyone who would install
> > Emacs into an already populated tree will get the mixed EOLs issue
> > back.
>
> Hi Eli,
>
> This sounds like its a minor enough issue that it could be solved after
> the changes are committed.
Not only is it minor, its solution is perfectly clear: use the native
Windows build of Texinfo. I will update the instructions accordingly.
> If you are not comfortable doing that yet, could you please post the
> latest version of your patch so I can help test it ?
The above is not what is holding the merge. I needed to leave the
branch alone for a while, because both GNU Make and Gawk have, or are
about to, release a new version which includes features that needed me
to do some non-trivial coding to support them. That took a week or
two of my time.
With this out of my way, I need to update the branch to handle the
changes in the configury committed lately to the trunk, to handle the
ACL portability. (I was actually hoping that something like this
would happen, because I want to see how much effort is needed to make
such adaptations.) Before I adapt to that change, I cannot merge my
branch onto the trunk, because the result will most probably fail to
compile. I hope to do that in a couple of days, and then I'll merge
and announce.
Stay tuned, and thanks for encouragement.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-13 16:23 ` Eli Zaretskii
@ 2013-05-16 6:00 ` Eli Zaretskii
2013-05-16 6:31 ` Paul Eggert
2013-05-16 13:19 ` Eli Zaretskii
0 siblings, 2 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-16 6:00 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
> Date: Mon, 13 May 2013 19:23:13 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
>
> With this out of my way, I need to update the branch to handle the
> changes in the configury committed lately to the trunk, to handle the
> ACL portability. (I was actually hoping that something like this
> would happen, because I want to see how much effort is needed to make
> such adaptations.) Before I adapt to that change, I cannot merge my
> branch onto the trunk, because the result will most probably fail to
> compile. I hope to do that in a couple of days, and then I'll merge
> and announce.
>
> Stay tuned, and thanks for encouragement.
I'm almost done. Adapting to the new gnulib module was easy, which is
really good news.
There's one minor issue, though. qset-acl.c didn't compile, because
it requires the acl_delete_def_file function:
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I/d/gnu/bzr/emacs/msys-build/lib -I../src -I/d/gnu/bzr/emacs/msys-build/src -mtune=pentium4 -DGLYPH_DEBUG=1 -DUSE_CRT_DLL=1 -I /d/gnu/bzr/emacs/msys-build/nt/inc -O0 -gdwarf-2 -g3 -MT qset-acl.o -MD -MP -MF .deps/qset-acl.Tpo -c -o qset-acl.o qset-acl.c
qset-acl.c:71:6: #error Must have acl_delete_def_file (see POSIX 1003.1e draft 17).
qset-acl.c: In function `qset_acl':
qset-acl.c:127: warning: implicit declaration of function `acl_delete_def_file'
Makefile:1449: recipe for target `qset-acl.o' failed
make[2]: *** [qset-acl.o] Error 1
I was able to get past that by removing qset-acl.c from this line in
nt/gnulib.mk:
libgnu_a_SOURCES += acl-errno-valid.c file-has-acl.c qcopy-acl.c qset-acl.c
However, I'd rather not remove parts of gnulib modules, I prefer to
either include the whole module or none of it. Perhaps some simple
change in qset-acl.c would be possible to work around this issue?
After all qcopy_acl will not be called by the Windows build, so it is
not important what it does.
Alternatively, perhaps the qacl module could be broken into 2: one
that includes the acl-errno-valid.c file, which is the only one the
Windows build really needs, the other with the rest. Then the Windows
build could use only the former.
Paul, can you help me out here? Thanks.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 6:00 ` Eli Zaretskii
@ 2013-05-16 6:31 ` Paul Eggert
2013-05-16 6:56 ` Eli Zaretskii
2013-05-16 13:19 ` Eli Zaretskii
1 sibling, 1 reply; 116+ messages in thread
From: Paul Eggert @ 2013-05-16 6:31 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 05/15/2013 11:00 PM, Eli Zaretskii wrote:
> However, I'd rather not remove parts of gnulib modules, I prefer to
> either include the whole module or none of it.
Even the POSIX build configuration isn't that rigid: for example,
it omits m4/fcntl-o.m4 and m4/warn-on-use.m4 even though they're
part of the corresponding gnulib modules. If the Windows port
doesn't need to compile qset-acl.c then it sounds simpler to
just omit qset-acl.c from nt/gnulib.mk. Adding a module to gnulib
would take more work than changing that one line in nt/gnulib.mk.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 6:31 ` Paul Eggert
@ 2013-05-16 6:56 ` Eli Zaretskii
2013-05-16 7:16 ` Paul Eggert
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-16 6:56 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
> Date: Wed, 15 May 2013 23:31:26 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
>
> On 05/15/2013 11:00 PM, Eli Zaretskii wrote:
> > However, I'd rather not remove parts of gnulib modules, I prefer to
> > either include the whole module or none of it.
>
> Even the POSIX build configuration isn't that rigid: for example,
> it omits m4/fcntl-o.m4 and m4/warn-on-use.m4 even though they're
> part of the corresponding gnulib modules. If the Windows port
> doesn't need to compile qset-acl.c then it sounds simpler to
> just omit qset-acl.c from nt/gnulib.mk.
That's fine with me, thanks. Do you also feel that some minor change
in qset-acl.c, to cause the compilation fall back on chmod_or_fchmod,
is not justified? That would allow to compile that file.
And another question: what is the difference between the files
mentioned in libgnu_a_SOURCES and those in EXTRA_libgnu_a_SOURCES?
Like here:
## begin gnulib module qacl
libgnu_a_SOURCES += acl-errno-valid.c file-has-acl.c qcopy-acl.c
EXTRA_DIST += acl-internal.h acl.h acl_entries.c
EXTRA_libgnu_a_SOURCES += acl_entries.c
## end gnulib module qacl
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 6:56 ` Eli Zaretskii
@ 2013-05-16 7:16 ` Paul Eggert
2013-05-16 7:30 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Paul Eggert @ 2013-05-16 7:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 05/15/2013 11:56 PM, Eli Zaretskii wrote:
> Do you also feel that some minor change
> in qset-acl.c, to cause the compilation fall back on chmod_or_fchmod,
> is not justified? That would allow to compile that file.
If I understand you correctly, there's no need to compile the file,
as its function is never called. So I'd just omit it from
nt/gnulib.mk; that's simpler.
> And another question: what is the difference between the files
> mentioned in libgnu_a_SOURCES and those in EXTRA_libgnu_a_SOURCES?
> Like here:
>
> ## begin gnulib module qacl
>
> libgnu_a_SOURCES += acl-errno-valid.c file-has-acl.c qcopy-acl.c
>
> EXTRA_DIST += acl-internal.h acl.h acl_entries.c
>
> EXTRA_libgnu_a_SOURCES += acl_entries.c
There's a call AC_REPLACE_FUNCS([acl_entries]) in gl_FUNC_ACL,
which means the autoconf machinery decides whether to compile
acl_entries.c based on whether the system already has an acl_entries.
The functions acl_errno_valid, file_has_acl, and qcopy_acl are
not like that: they're meant to be compiled no matter what,
so one can simply tell Automake about them directly, using
libgnu_a_SOURCES.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 7:16 ` Paul Eggert
@ 2013-05-16 7:30 ` Eli Zaretskii
0 siblings, 0 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-16 7:30 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
> Date: Thu, 16 May 2013 00:16:29 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
>
> On 05/15/2013 11:56 PM, Eli Zaretskii wrote:
>
> > Do you also feel that some minor change
> > in qset-acl.c, to cause the compilation fall back on chmod_or_fchmod,
> > is not justified? That would allow to compile that file.
>
> If I understand you correctly, there's no need to compile the file,
> as its function is never called. So I'd just omit it from
> nt/gnulib.mk; that's simpler.
Thanks, will do.
> > ## begin gnulib module qacl
> >
> > libgnu_a_SOURCES += acl-errno-valid.c file-has-acl.c qcopy-acl.c
> >
> > EXTRA_DIST += acl-internal.h acl.h acl_entries.c
> >
> > EXTRA_libgnu_a_SOURCES += acl_entries.c
>
> There's a call AC_REPLACE_FUNCS([acl_entries]) in gl_FUNC_ACL,
> which means the autoconf machinery decides whether to compile
> acl_entries.c based on whether the system already has an acl_entries.
> The functions acl_errno_valid, file_has_acl, and qcopy_acl are
> not like that: they're meant to be compiled no matter what,
> so one can simply tell Automake about them directly, using
> libgnu_a_SOURCES.
Got it. Thanks again.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 6:00 ` Eli Zaretskii
2013-05-16 6:31 ` Paul Eggert
@ 2013-05-16 13:19 ` Eli Zaretskii
2013-05-16 14:43 ` Dmitry Gutov
1 sibling, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-16 13:19 UTC (permalink / raw)
To: emacs-devel
> Date: Thu, 16 May 2013 09:00:51 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
>
> > Date: Mon, 13 May 2013 19:23:13 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: emacs-devel@gnu.org
> >
> > With this out of my way, I need to update the branch to handle the
> > changes in the configury committed lately to the trunk, to handle the
> > ACL portability. (I was actually hoping that something like this
> > would happen, because I want to see how much effort is needed to make
> > such adaptations.) Before I adapt to that change, I cannot merge my
> > branch onto the trunk, because the result will most probably fail to
> > compile. I hope to do that in a couple of days, and then I'll merge
> > and announce.
> >
> > Stay tuned, and thanks for encouragement.
>
> I'm almost done.
And now completely done. Trunk revision 112606 allows to build Emacs
on Windows using the Posix configure script and Makefile's, under the
MSYS environment.
I'd like to encourage everyone who builds native Windows port of Emacs
to please switch to this method; the old nt/configure.bat and
Windows-specific makefile.w32-in files are from now on deprecated.
Start by reading nt/INSTALL.MSYS.
I would also like to thank everyone who provided comments to the
original patch: Stefan, Glenn, Paul, and to Ken Brown and others who
tried that on their systems. Special thanks to Dani Moncayo, who
boldly applied my initial imperfect patch, and then patiently reported
every problem he discovered, until they all were resolved.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 13:19 ` Eli Zaretskii
@ 2013-05-16 14:43 ` Dmitry Gutov
2013-05-16 15:41 ` Eli Zaretskii
2013-05-19 6:48 ` Stephen Leake
0 siblings, 2 replies; 116+ messages in thread
From: Dmitry Gutov @ 2013-05-16 14:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> I'd like to encourage everyone who builds native Windows port of Emacs
> to please switch to this method; the old nt/configure.bat and
> Windows-specific makefile.w32-in files are from now on deprecated.
> Start by reading nt/INSTALL.MSYS.
Thank you for you work. A few comments on the documentation:
> It is always preferable to use --prefix to configure Emacs for
> some specific location of its installed tree; the default
> /usr/local is not suitable for Windows.
What's going to happen if I disregard this recommendation? Will build
fail? I've taken a habit of running Emacs from the trunk\bin directory
on Windows, I just add it to PATH. Will that stop working?
> After that, use "ming-get install PACKAGE" to install the following
Looks like a typo: ming -> mingw
> (We recommend that you refrain from installing the MSYS Texinfo
> package, which is part of msys-base, because it might produce mixed
> EOL format when installing Info files. Instead, install the MinGW
> port of Texinfo, see the ezwinports URL below.)
How am I supposed to do that? MinGW-Get installer only allows me to
check or uncheck the whole "MSYS Base" category, not the individual
packages.
> https://sourceforge.net/projects/mingw/files/Installer/mingw-get/
>
> (This installer only supports packages downloaded from the MinGW
> site; for the rest you will still need the manual method.)
>
> After installing mingw-get, invoke it to install the packages that
> are already selected by default on the "Select Components" screen of
> its wizard.
The MinGW-Get installer, at least, goes straight from selecting packages
to installing them. And it's the recommended download at the page you
link to (Looking for the latest version? Download
mingw-get-inst-20120426.exe).
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 14:43 ` Dmitry Gutov
@ 2013-05-16 15:41 ` Eli Zaretskii
2013-05-16 16:10 ` Dmitry Gutov
2013-05-19 6:48 ` Stephen Leake
1 sibling, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-16 15:41 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: emacs-devel@gnu.org
> Date: Thu, 16 May 2013 18:43:24 +0400
>
> > It is always preferable to use --prefix to configure Emacs for
> > some specific location of its installed tree; the default
> > /usr/local is not suitable for Windows.
>
> What's going to happen if I disregard this recommendation? Will build
> fail?
No, I don't think the build will fail. --prefix is only important for
"make install".
> I've taken a habit of running Emacs from the trunk\bin directory
> on Windows, I just add it to PATH. Will that stop working?
I don't know, I never tried such a strange arrangement with the Posix
build. Why don't you simply run Emacs from src instead? That is how
Emacs is supposed to be run uninstalled. Otherwise, you will be
copying a lot of files for no good reason.
And anyway, how is running from trunk/bin related to --prefix?
> > After that, use "ming-get install PACKAGE" to install the following
>
> Looks like a typo: ming -> mingw
Thanks, fixed.
> > (We recommend that you refrain from installing the MSYS Texinfo
> > package, which is part of msys-base, because it might produce mixed
> > EOL format when installing Info files. Instead, install the MinGW
> > port of Texinfo, see the ezwinports URL below.)
>
> How am I supposed to do that? MinGW-Get installer only allows me to
> check or uncheck the whole "MSYS Base" category, not the individual
> packages.
I don't know; I don't use mingw-get. Perhaps uninstall the Texinfo
package after installing msys-base (assuming mingw-get has an
uninstall option that can uninstall a single package)? If that
doesn't work, I suggest to ask on the mingw-users mailing list, the
developer of mingw-get is reading that.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 15:41 ` Eli Zaretskii
@ 2013-05-16 16:10 ` Dmitry Gutov
2013-05-16 17:17 ` Dani Moncayo
2013-05-16 17:18 ` Eli Zaretskii
0 siblings, 2 replies; 116+ messages in thread
From: Dmitry Gutov @ 2013-05-16 16:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 16.05.2013 19:41, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 16 May 2013 18:43:24 +0400
>>
>>> It is always preferable to use --prefix to configure Emacs for
>>> some specific location of its installed tree; the default
>>> /usr/local is not suitable for Windows.
>>
>> What's going to happen if I disregard this recommendation? Will build
>> fail?
>
> No, I don't think the build will fail. --prefix is only important for
> "make install".
If the installation will fail, maybe the prefix should default to some
reasonable directory within the Emacs tree. Would it be hard to do that?
>> I've taken a habit of running Emacs from the trunk\bin directory
>> on Windows, I just add it to PATH. Will that stop working?
>
> I don't know, I never tried such a strange arrangement with the Posix
> build. Why don't you simply run Emacs from src instead? That is how
> Emacs is supposed to be run uninstalled. Otherwise, you will be
> copying a lot of files for no good reason.
Ah, okay, thanks. That's how I run Emacs on GNU/Linux.
> And anyway, how is running from trunk/bin related to --prefix?
Technically, it's unrelated, I guess, so this was just a question from
someone who has been using the NT port for some time. AFAICT, the "make
install" step is mandatory to running Emacs built that way.
>>> (We recommend that you refrain from installing the MSYS Texinfo
>>> package, which is part of msys-base, because it might produce mixed
>>> EOL format when installing Info files. Instead, install the MinGW
>>> port of Texinfo, see the ezwinports URL below.)
>>
>> How am I supposed to do that? MinGW-Get installer only allows me to
>> check or uncheck the whole "MSYS Base" category, not the individual
>> packages.
>
> I don't know; I don't use mingw-get. Perhaps uninstall the Texinfo
> package after installing msys-base (assuming mingw-get has an
> uninstall option that can uninstall a single package)? If that
> doesn't work, I suggest to ask on the mingw-users mailing list, the
> developer of mingw-get is reading that.
Indeed, "mingw-get remove msys-texinfo" seems to have done that.
If having to remove that package manually (as opposed to not installing
it) is going to be a common situation, maybe INSTALL.MSYS should reflect
that.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 16:10 ` Dmitry Gutov
@ 2013-05-16 17:17 ` Dani Moncayo
2013-05-16 17:54 ` Eli Zaretskii
2013-05-16 17:18 ` Eli Zaretskii
1 sibling, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-05-16 17:17 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Eli Zaretskii, Emacs development discussions
>>>> It is always preferable to use --prefix to configure Emacs for
>>>> some specific location of its installed tree; the default
>>>> /usr/local is not suitable for Windows.
>>>
>>>
>>> What's going to happen if I disregard this recommendation? Will build
>>> fail?
>>
>>
>> No, I don't think the build will fail. --prefix is only important for
>> "make install".
>
>
> If the installation will fail, maybe the prefix should default to some
> reasonable directory within the Emacs tree. Would it be hard to do that?
"/usr/local" is a valid directory specification in MSYS, so I don't
see why the installation should fail. Omitting the --prefix in "make
install" should simply install Emacs under that directory.
>>>> (We recommend that you refrain from installing the MSYS Texinfo
>>>> package, which is part of msys-base, because it might produce mixed
>>>> EOL format when installing Info files. Instead, install the MinGW
>>>> port of Texinfo, see the ezwinports URL below.)
>>>
>>>
>>> How am I supposed to do that? MinGW-Get installer only allows me to
>>> check or uncheck the whole "MSYS Base" category, not the individual
>>> packages.
>>
>>
>> I don't know; I don't use mingw-get. Perhaps uninstall the Texinfo
>> package after installing msys-base (assuming mingw-get has an
>> uninstall option that can uninstall a single package)? If that
>> doesn't work, I suggest to ask on the mingw-users mailing list, the
>> developer of mingw-get is reading that.
>
>
> Indeed, "mingw-get remove msys-texinfo" seems to have done that.
> If having to remove that package manually (as opposed to not installing it)
> is going to be a common situation, maybe INSTALL.MSYS should reflect that.
The Texinfo version that comes with MSYS works just fine, AFAICT.
There is only a minor issue with ^M characters that get inserted in
the info directory in certain situations.
So, I don't see a big need for having to uninstall that Texinfo and
manually install the other (the Windows-native) one.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 16:10 ` Dmitry Gutov
2013-05-16 17:17 ` Dani Moncayo
@ 2013-05-16 17:18 ` Eli Zaretskii
2013-05-16 21:19 ` Dmitry Gutov
1 sibling, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-16 17:18 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Date: Thu, 16 May 2013 20:10:05 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> >> What's going to happen if I disregard this recommendation? Will build
> >> fail?
> >
> > No, I don't think the build will fail. --prefix is only important for
> > "make install".
>
> If the installation will fail, maybe the prefix should default to some
> reasonable directory within the Emacs tree. Would it be hard to do that?
I see no reason to do that because the build will NOT fail. In any
case, any such changes should be common to the Posix platforms, where
it would be really unusual to install within the source tree.
> > Why don't you simply run Emacs from src instead? That is how
> > Emacs is supposed to be run uninstalled. Otherwise, you will be
> > copying a lot of files for no good reason.
>
> Ah, okay, thanks. That's how I run Emacs on GNU/Linux.
The whole point of this build method is to make the Windows port build
and install as it does on GNU/Linux.
> > And anyway, how is running from trunk/bin related to --prefix?
>
> Technically, it's unrelated, I guess, so this was just a question from
> someone who has been using the NT port for some time. AFAICT, the "make
> install" step is mandatory to running Emacs built that way.
No, you don't need "make install" to run Emacs that was built the old
way on Windows. You do need to say "make" twice, because only the
second time picks up the updated DOC file. This nuisance is gone in
the Posix build method.
> Indeed, "mingw-get remove msys-texinfo" seems to have done that.
> If having to remove that package manually (as opposed to not installing
> it) is going to be a common situation, maybe INSTALL.MSYS should reflect
> that.
I added that, thanks.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 17:17 ` Dani Moncayo
@ 2013-05-16 17:54 ` Eli Zaretskii
2013-05-16 18:01 ` Dani Moncayo
2013-05-16 21:02 ` Dmitry Gutov
0 siblings, 2 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-16 17:54 UTC (permalink / raw)
To: Dani Moncayo; +Cc: emacs-devel, dgutov
> Date: Thu, 16 May 2013 19:17:04 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, Emacs development discussions <emacs-devel@gnu.org>
>
> "/usr/local" is a valid directory specification in MSYS, so I don't
> see why the installation should fail. Omitting the --prefix in "make
> install" should simply install Emacs under that directory.
Except that /usr/local is mapped by MSYS to something like
C:\MSYS\local or some such, not something Windows users who aren't
used to MSYS would expect. After "make install", a naive user might
not be able to find the installation, especially if the sources are
not on drive C:. That's why I wrote in INSTALL.MSYS that using the
default is not recommended.
In general, I suggest to always specify --prefix in Windows format,
i.e. x:/foo/bar, when using MSYS to run the configure scripts. MSYS
Bash supports that, and using Windows file names will give you a
chance to remember one less weird factoid.
> The Texinfo version that comes with MSYS works just fine, AFAICT.
> There is only a minor issue with ^M characters that get inserted in
> the info directory in certain situations.
>
> So, I don't see a big need for having to uninstall that Texinfo and
> manually install the other (the Windows-native) one.
I will let users decide whether they want to uninstall it. I just
added a sentence with the mingw-get command needed to do so, that's
all.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 17:54 ` Eli Zaretskii
@ 2013-05-16 18:01 ` Dani Moncayo
2013-05-16 18:36 ` Eli Zaretskii
2013-05-16 21:02 ` Dmitry Gutov
1 sibling, 1 reply; 116+ messages in thread
From: Dani Moncayo @ 2013-05-16 18:01 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Brief Busters, Emacs development discussions
>> "/usr/local" is a valid directory specification in MSYS, so I don't
>> see why the installation should fail. Omitting the --prefix in "make
>> install" should simply install Emacs under that directory.
>
> Except that /usr/local is mapped by MSYS to something like
> C:\MSYS\local or some such, not something Windows users who aren't
> used to MSYS would expect. After "make install", a naive user might
> not be able to find the installation, especially if the sources are
> not on drive C:. That's why I wrote in INSTALL.MSYS that using the
> default is not recommended.
Yes, I agree.
I just was pointing out the behavior I would expect if someone omits
--prefix when configuring, and also when installing Emacs.
> In general, I suggest to always specify --prefix in Windows format,
> i.e. x:/foo/bar, when using MSYS to run the configure scripts. MSYS
> Bash supports that, and using Windows file names will give you a
> chance to remember one less weird factoid.
>
>> The Texinfo version that comes with MSYS works just fine, AFAICT.
>> There is only a minor issue with ^M characters that get inserted in
>> the info directory in certain situations.
>>
>> So, I don't see a big need for having to uninstall that Texinfo and
>> manually install the other (the Windows-native) one.
>
> I will let users decide whether they want to uninstall it. I just
> added a sentence with the mingw-get command needed to do so, that's
> all.
Ok.
Thank you very much for your great work, Eli.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 18:01 ` Dani Moncayo
@ 2013-05-16 18:36 ` Eli Zaretskii
0 siblings, 0 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-16 18:36 UTC (permalink / raw)
To: Dani Moncayo; +Cc: dgutov, emacs-devel
> Date: Thu, 16 May 2013 20:01:04 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>, Brief Busters <dgutov@yandex.ru>
>
> Thank you very much for your great work, Eli.
And thank you for courageously testing it.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 17:54 ` Eli Zaretskii
2013-05-16 18:01 ` Dani Moncayo
@ 2013-05-16 21:02 ` Dmitry Gutov
2013-05-17 6:02 ` Eli Zaretskii
1 sibling, 1 reply; 116+ messages in thread
From: Dmitry Gutov @ 2013-05-16 21:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, Dani Moncayo
On 16.05.2013 21:54, Eli Zaretskii wrote:
>> Date: Thu, 16 May 2013 19:17:04 +0200
>> From: Dani Moncayo <dmoncayo@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, Emacs development discussions <emacs-devel@gnu.org>
>>
>> "/usr/local" is a valid directory specification in MSYS, so I don't
>> see why the installation should fail. Omitting the --prefix in "make
>> install" should simply install Emacs under that directory.
>
> Except that /usr/local is mapped by MSYS to something like
> C:\MSYS\local or some such, not something Windows users who aren't
> used to MSYS would expect. After "make install", a naive user might
> not be able to find the installation, especially if the sources are
> not on drive C:. That's why I wrote in INSTALL.MSYS that using the
> default is not recommended.
I see. That's okay, then, thanks for the explanation.
Now that I got to compilation, "make -j2" freezes the process soon after
start (I've tried it several times), here's the whole log:
$ make -j 2
[ -r "/c/Users/gutov/vc/emacs-bzr/trunk/src/config.in" ] || ( cd
/c/Users/gutov/vc/emacs-b
zr/trunk && autoheader )
cd nt && make all - --jobserver-fds=4,5 -j \
CC='gcc -std=gnu99' CFLAGS='-g3 -O2 -gdwarf-2'
CPPFLAGS='-mtune=pentium4 -DUS
E_CRT_DLL=1 -I /c/Users/gutov/vc/emacs-bzr/trunk/nt/inc' \
LDFLAGS='' MAKE='make'
cd lib && make all - --jobserver-fds=4,5 -j \
CC='gcc -std=gnu99' CFLAGS='-g3 -O2 -gdwarf-2'
CPPFLAGS='-mtune=pentium4 -DUS
E_CRT_DLL=1 -I /c/Users/gutov/vc/emacs-bzr/trunk/nt/inc' \
LDFLAGS='' MAKE='make'
make[1]: Entering directory `/c/Users/gutov/vc/emacs-bzr/trunk/nt'
gcc -std=gnu99 -mtune=pentium4 -I.
-I/c/Users/gutov/vc/emacs-bzr/trunk/nt -mtune=pen
tium4 -DUSE_CRT_DLL=1 -I /c/Users/gutov/vc/emacs-bzr/trunk/nt/inc -g3
-O2 -gdwarf-2 /c/U
sers/gutov/vc/emacs-bzr/trunk/nt/runemacs.c emacs.res -mwindows \
-o runemacs.exe
make[1]: Entering directory `/c/Users/gutov/vc/emacs-bzr/trunk/lib'
rm -f alloca.h-t alloca.h && \
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
cat /c/Users/gutov/vc/emacs-bzr/trunk/lib/alloca.in.h; \
} > alloca.h-t && \
mv -f alloca.h-t alloca.h
Is that what is meant by not "supporting parallel execution"?
Non-parallel "make" starts differently (!) and completes the build fine.
I think someone mentioned that this way of building would be faster, but
configuration takes longer than with configure.bat, and compilation
seems to take about the same amount of time.
configure.bat took ~15 seconds, msysconfig.sh takes a couple of minutes,
the following compilation is about the same, I think.
autogen.sh takes some time, too.
Speaking of stability, I've seen it crash a few times during exit,
around the time it complains about inability to write ACL. Haven't been
able to reproduce this under gdb, so far.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 17:18 ` Eli Zaretskii
@ 2013-05-16 21:19 ` Dmitry Gutov
2013-05-17 9:39 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dmitry Gutov @ 2013-05-16 21:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 16.05.2013 21:18, Eli Zaretskii wrote:
>>> Why don't you simply run Emacs from src instead? That is how
>>> Emacs is supposed to be run uninstalled. Otherwise, you will be
>>> copying a lot of files for no good reason.
>>
>> Ah, okay, thanks. That's how I run Emacs on GNU/Linux.
>
> The whole point of this build method is to make the Windows port build
> and install as it does on GNU/Linux.
A follow-up question: what do I do about runemacs.exe? It's not in src,
it's in nt, and it doesn't work when emacs.exe is not in the same dir.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 21:02 ` Dmitry Gutov
@ 2013-05-17 6:02 ` Eli Zaretskii
0 siblings, 0 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-17 6:02 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel, dmoncayo
> Date: Fri, 17 May 2013 01:02:53 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: Dani Moncayo <dmoncayo@gmail.com>, emacs-devel@gnu.org
>
> Now that I got to compilation, "make -j2" freezes the process soon after
> start (I've tried it several times), here's the whole log:
> [...]
> Is that what is meant by not "supporting parallel execution"?
Yes. Get a snapshot of MSYS Make, if you want -j.
> configure.bat took ~15 seconds, msysconfig.sh takes a couple of minutes,
> the following compilation is about the same, I think.
> autogen.sh takes some time, too.
But you seldom if ever need to run msysconfig.sh at all. Just run
"make" all the time, it will automatically re-run configure if
necessary.
> Speaking of stability, I've seen it crash a few times during exit,
> around the time it complains about inability to write ACL.
That's most probably unrelated: you are probably a member of the
Administrators group, which means you need to fix the permissions for
the ~/.emacs.d directory, so it is owned by your user, not by the
Administrators group.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 21:19 ` Dmitry Gutov
@ 2013-05-17 9:39 ` Eli Zaretskii
2013-05-17 12:05 ` Dmitry Gutov
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-17 9:39 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Date: Fri, 17 May 2013 01:19:14 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> A follow-up question: what do I do about runemacs.exe? It's not in src,
> it's in nt, and it doesn't work when emacs.exe is not in the same dir.
Starting with trunk revision 112622, it should work to invoke
runemacs.exe from the nt/ subdirectory of the source or the build
tree.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-17 9:39 ` Eli Zaretskii
@ 2013-05-17 12:05 ` Dmitry Gutov
2013-05-17 13:13 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dmitry Gutov @ 2013-05-17 12:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 17.05.2013 13:39, Eli Zaretskii wrote:
> Starting with trunk revision 112622, it should work to invoke
> runemacs.exe from the nt/ subdirectory of the source or the build
> tree.
Fantastic, thanks!
>> Speaking of stability, I've seen it crash a few times during exit,
>> around the time it complains about inability to write ACL.
>
> That's most probably unrelated:
Looks like that. One does not necessarily lead to the other. So far, gdb
just sometimes shows that exit status is not normal.
Run and immediately exit:
(gdb) run
Starting program: C:\Users\gutov\vc\emacs-bzr\trunk\src\emacs.exe
[New Thread 2704.0x304]
[New Thread 2704.0x1450]
Warning: Lisp directory
`C:/Users/gutov/vc/emacs-bzr/trunk/../site-lisp': No such file or
directory
[New Thread 2704.0x14d8]
[New Thread 2704.0xfb4]
[Inferior 1 (process 2704) exited normally]
(gdb)
Run, launch gnus, mess with it a bit, exit:
(gdb) run
Starting program: C:\Users\gutov\vc\emacs-bzr\trunk\src\emacs.exe
[New Thread 2496.0x1410]
[New Thread 2496.0x167c]
Warning: Lisp directory
`C:/Users/gutov/vc/emacs-bzr/trunk/../site-lisp': No such file or
directory
[New Thread 2496.0x8cc]
[New Thread 2496.0x1684]
[New Thread 2496.0x15dc]
[New Thread 2496.0x16b4]
[New Thread 2496.0x474]
[Inferior 1 (process 2496) exited with code 03]
The latter scenario, when executed outside of gdb, usually leads to
dialog "... has stopped working".
Problem signature:
Problem Event Name: APPCRASH
Application Name: emacs.exe
Application Version: 24.3.50.0
Application Timestamp: 51961843
Fault Module Name: libgcc_s_dw2-1.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 507d56df
The text displayed in the message area during the crash is "Wrote
C:/Users/gutov/.ido.last".
> you are probably a member of the
> Administrators group, which means you need to fix the permissions for
> the ~/.emacs.d directory, so it is owned by your user, not by the
> Administrators group.
I'm the owner of ~, ~/.emacs.d and ~/.emacs.d/backups, yet if I toggle
debug-on-error on, I still see the following when exiting:
Debugger entered--Lisp error: (file-error "Setting ACL" "operation not
permitted"
"c:/Users/gutov/.emacs.d/backups/!drive_c!Users!gutov!.recentf.~525~")
set-file-acl("c:/Users/gutov/.emacs.d/backups/!drive_c!Users!gutov!.recentf.~525~"
"O:BAG:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)")
set-file-extended-attributes("c:/Users/gutov/.emacs.d/backups/!drive_c!Users!gutov!.recentf.~525~"
((acl .
"O:BAG:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)")
(selinux-context nil nil nil nil)))
backup-buffer-copy("c:/Users/gutov/.recentf"
"c:/Users/gutov/.emacs.d/backups/!drive_c!Users!gutov!.recentf.~525~"
438 ((acl .
"O:BAG:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)")
(selinux-context nil nil nil nil)))
Apparently, because ~/.recentf is still owned by Administrator. I'll fix
that, no problem. Just another special case.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-17 12:05 ` Dmitry Gutov
@ 2013-05-17 13:13 ` Eli Zaretskii
2013-05-17 14:03 ` Dmitry Gutov
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-17 13:13 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Date: Fri, 17 May 2013 16:05:29 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> Run, launch gnus, mess with it a bit, exit:
>
> (gdb) run
> Starting program: C:\Users\gutov\vc\emacs-bzr\trunk\src\emacs.exe
> [New Thread 2496.0x1410]
> [New Thread 2496.0x167c]
> Warning: Lisp directory
> `C:/Users/gutov/vc/emacs-bzr/trunk/../site-lisp': No such file or
> directory
> [New Thread 2496.0x8cc]
> [New Thread 2496.0x1684]
> [New Thread 2496.0x15dc]
> [New Thread 2496.0x16b4]
> [New Thread 2496.0x474]
> [Inferior 1 (process 2496) exited with code 03]
Exit code 03 means it called 'abort'. Suggest to set a breakpoint on
'abort' and on 'exit', and see who calls them.
> The latter scenario, when executed outside of gdb, usually leads to
> dialog "... has stopped working".
>
> Problem signature:
> Problem Event Name: APPCRASH
> Application Name: emacs.exe
> Application Version: 24.3.50.0
> Application Timestamp: 51961843
> Fault Module Name: libgcc_s_dw2-1.dll
> Fault Module Version: 0.0.0.0
> Fault Module Timestamp: 507d56df
Are you sure your libgcc_s_dw2-1.dll is the one that goes with the
version of GCC you used to build Emacs? Do you perhaps have more than
one version of that DLL on your system? (I wish that libgcc DLL never
saw the light of day, for the problems it causes!)
> Debugger entered--Lisp error: (file-error "Setting ACL" "operation not
> permitted"
> "c:/Users/gutov/.emacs.d/backups/!drive_c!Users!gutov!.recentf.~525~")
>
> set-file-acl("c:/Users/gutov/.emacs.d/backups/!drive_c!Users!gutov!.recentf.~525~"
> "O:BAG:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)")
>
> set-file-extended-attributes("c:/Users/gutov/.emacs.d/backups/!drive_c!Users!gutov!.recentf.~525~"
> ((acl .
> "O:BAG:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)")
> (selinux-context nil nil nil nil)))
> backup-buffer-copy("c:/Users/gutov/.recentf"
> "c:/Users/gutov/.emacs.d/backups/!drive_c!Users!gutov!.recentf.~525~"
> 438 ((acl .
> "O:BAG:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)")
> (selinux-context nil nil nil nil)))
>
> Apparently, because ~/.recentf is still owned by Administrator.
Looks like that. I suggest that you take ownership on your entire
home directory, and check the checkbox that propagates the changes to
all the files and subdirectories under your home. This should make
sure any new files you create there will be owned by your user.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-17 13:13 ` Eli Zaretskii
@ 2013-05-17 14:03 ` Dmitry Gutov
2013-05-17 14:26 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dmitry Gutov @ 2013-05-17 14:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 17.05.2013 17:13, Eli Zaretskii wrote:
> Exit code 03 means it called 'abort'. Suggest to set a breakpoint on
> 'abort' and on 'exit', and see who calls them.
That caught it. Apparently, 'abort' is called by some background thread,
there are a few 'exit' calls before that. See the bottom of this email
for the full backtrace.
Breakpoint 1 at 0x10a5e03: file emacs.c, line 316.
Temporary breakpoint 2 at 0x10c2d4d: file sysdep.c, line 881.
(gdb) b abort
Breakpoint 3 at 0x11f38e8
(gdb) b exit
Breakpoint 4 at 0x11f37a0
(gdb) run
Starting program: c:\Users\gutov\vc\emacs-bzr\trunk\src\emacs.exe
[New Thread 5132.0x12c0]
[New Thread 5132.0x474]
Warning: Lisp directory
`c:/Users/gutov/vc/emacs-bzr/trunk/../site-lisp': No such fil
directory
[New Thread 5132.0x1540]
[New Thread 5132.0x1754]
[New Thread 5132.0x1698]
[New Thread 5132.0x5d8]
[New Thread 5132.0x1704]
[New Thread 5132.0x1190]
[New Thread 5132.0x4c0]
[New Thread 5132.0xb48]
[New Thread 5132.0x10a0]
Breakpoint 4, 0x011f37a0 in exit ()
(gdb) bt
#0 0x011f37a0 in exit ()
#1 0x010a7902 in Fkill_emacs (arg=54970394) at emacs.c:1856
#2 0x01128198 in Ffuncall (nargs=1, args=0x88f024) at eval.c:2674
#3 0x01163758 in exec_byte_code (bytestr=19079809, vector=19079829,
maxdepth=20,
args_template=54970394, nargs=0, args=0x0) at bytecode.c:900
#4 0x01128a9c in funcall_lambda (fun=19079781, nargs=1,
arg_vector=0x346c81a <__register_frame_info+54970394>) at eval.c:2906
#5 0x011283bf in Ffuncall (nargs=2, args=0x88f314) at eval.c:2723
#6 0x01163758 in exec_byte_code (bytestr=19080265, vector=19080285,
maxdepth=12,
args_template=54970394, nargs=0, args=0x0) at bytecode.c:900
#7 0x01128a9c in funcall_lambda (fun=19080237, nargs=1,
arg_vector=0x346c81a <__register_frame_info+54970394>) at eval.c:2906
#8 0x011283bf in Ffuncall (nargs=2, args=0x88f640) at eval.c:2723
#9 0x01123f45 in Fcall_interactively (function=56959266,
record_flag=54970394,
keys=54992221) at callint.c:839
#10 0x011281e3 in Ffuncall (nargs=4, args=0x88f87c) at eval.c:2681
#11 0x01163758 in exec_byte_code (bytestr=19300193, vector=19300213,
maxdepth=52,
args_template=4100, nargs=1, args=0x88fb80) at bytecode.c:900
#12 0x01128815 in funcall_lambda (fun=19300173, nargs=1, arg_vector=0x1004)
at eval.c:2840
#13 0x011283bf in Ffuncall (nargs=2, args=0x88fb78) at eval.c:2723
#14 0x01127cce in call1 (fn=55012098, arg1=56959266) at eval.c:2468
#15 0x010a9dda in command_loop_1 () at keyboard.c:1578
#16 0x01125abd in internal_condition_case (bfun=0x10a96f5 <command_loop_1>,
handlers=55016570, hfun=0x10a90ed <cmd_error>) at eval.c:1193
#17 0x010a946f in command_loop_2 (ignore=54970394) at keyboard.c:1167
#18 0x01125635 in internal_catch (tag=55010546, func=0x10a944b
<command_loop_2>,
arg=54970394) at eval.c:964
#19 0x010a9427 in command_loop () at keyboard.c:1146
#20 0x010a8d33 in recursive_edit_1 () at keyboard.c:779
#21 0x010a8e84 in Frecursive_edit () at keyboard.c:843
#22 0x010a725c in main (argc=1, argv=0xd71768) at emacs.c:1531
Lisp Backtrace:
"kill-emacs" (0x88f028)
"save-buffers-kill-emacs" (0x88f318)
"save-buffers-kill-terminal" (0x88f644)
"call-interactively" (0x88f880)
"command-execute" (0x88fb7c)
(gdb) c
Continuing.
Breakpoint 4, 0x74c436af in msvcrt!exit () from
C:\windows\syswow64\msvcrt.dll
(gdb) c
Continuing.
[New Thread 5132.0x1668]
Breakpoint 3, 0x74c98e76 in msvcrt!abort () from
C:\windows\syswow64\msvcrt.dll
(gdb) bt
#0 0x74c98e76 in msvcrt!abort () from C:\windows\syswow64\msvcrt.dll
#1 0x6e956f62 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
from J:\Apps\System\MinGW\bin\libgcc_s_dw2-1.dll
#2 0x00d72710 in ?? ()
#3 0x74c3c3e9 in msvcrt!isspace () from C:\windows\syswow64\msvcrt.dll
#4 0x74c436bb in msvcrt!exit () from C:\windows\syswow64\msvcrt.dll
#5 0x010a7902 in Fkill_emacs (arg=54970394) at emacs.c:1856
#6 0x01128198 in Ffuncall (nargs=1, args=0x88f024) at eval.c:2674
#7 0x01163758 in exec_byte_code (bytestr=19079809, vector=19079829,
maxdepth=20,
args_template=54970394, nargs=0, args=0x0) at bytecode.c:900
#8 0x01128a9c in funcall_lambda (fun=19079781, nargs=1,
arg_vector=0x346c81a <__register_frame_info+54970394>) at eval.c:2906
#9 0x011283bf in Ffuncall (nargs=2, args=0x88f314) at eval.c:2723
#10 0x01163758 in exec_byte_code (bytestr=19080265, vector=19080285,
maxdepth=12,
args_template=54970394, nargs=0, args=0x0) at bytecode.c:900
#11 0x01128a9c in funcall_lambda (fun=19080237, nargs=1,
arg_vector=0x346c81a <__register_frame_info+54970394>) at eval.c:2906
#12 0x011283bf in Ffuncall (nargs=2, args=0x88f640) at eval.c:2723
#13 0x01123f45 in Fcall_interactively (function=56959266,
record_flag=54970394,
keys=54992221) at callint.c:839
#14 0x011281e3 in Ffuncall (nargs=4, args=0x88f87c) at eval.c:2681
#15 0x01163758 in exec_byte_code (bytestr=19300193, vector=19300213,
maxdepth=52,
args_template=4100, nargs=1, args=0x88fb80) at bytecode.c:900
#16 0x01128815 in funcall_lambda (fun=19300173, nargs=1, arg_vector=0x1004)
at eval.c:2840
#17 0x011283bf in Ffuncall (nargs=2, args=0x88fb78) at eval.c:2723
#18 0x01127cce in call1 (fn=55012098, arg1=56959266) at eval.c:2468
#19 0x010a9dda in command_loop_1 () at keyboard.c:1578
#20 0x01125abd in internal_condition_case (bfun=0x10a96f5 <command_loop_1>,
handlers=55016570, hfun=0x10a90ed <cmd_error>) at eval.c:1193
#21 0x010a946f in command_loop_2 (ignore=54970394) at keyboard.c:1167
#22 0x01125635 in internal_catch (tag=55010546, func=0x10a944b
<command_loop_2>,
arg=54970394) at eval.c:964
#23 0x010a9427 in command_loop () at keyboard.c:1146
#24 0x010a8d33 in recursive_edit_1 () at keyboard.c:779
#25 0x010a8e84 in Frecursive_edit () at keyboard.c:843
#26 0x010a725c in main (argc=1, argv=0xd71768) at emacs.c:1531
Lisp Backtrace:
"kill-emacs" (0x88f028)
"save-buffers-kill-emacs" (0x88f318)
"save-buffers-kill-terminal" (0x88f644)
"call-interactively" (0x88f880)
"command-execute" (0x88fb7c)
>> The latter scenario, when executed outside of gdb, usually leads to
>> dialog "... has stopped working".
>>
>> Problem signature:
>> Problem Event Name: APPCRASH
>> Application Name: emacs.exe
>> Application Version: 24.3.50.0
>> Application Timestamp: 51961843
>> Fault Module Name: libgcc_s_dw2-1.dll
>> Fault Module Version: 0.0.0.0
>> Fault Module Timestamp: 507d56df
>
> Are you sure your libgcc_s_dw2-1.dll is the one that goes with the
> version of GCC you used to build Emacs? Do you perhaps have more than
> one version of that DLL on your system? (I wish that libgcc DLL never
> saw the light of day, for the problems it causes!)
Quite sure, yes. There's only one file with that name inside the MigGW
tree, and MSYS root is inside there, too.
> I suggest that you take ownership on your entire
> home directory, and check the checkbox that propagates the changes to
> all the files and subdirectories under your home. This should make
> sure any new files you create there will be owned by your user.
Will do, thanks.
(gdb) bt full
#0 0x74c98e76 in msvcrt!abort () from C:\windows\syswow64\msvcrt.dll
No symbol table info available.
#1 0x6e956f62 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
from J:\Apps\System\MinGW\bin\libgcc_s_dw2-1.dll
No symbol table info available.
#2 0x00d72710 in ?? ()
No symbol table info available.
#3 0x74c3c3e9 in msvcrt!isspace () from C:\windows\syswow64\msvcrt.dll
No symbol table info available.
#4 0x74c436bb in msvcrt!exit () from C:\windows\syswow64\msvcrt.dll
No symbol table info available.
#5 0x010a7902 in Fkill_emacs (arg=54970394) at emacs.c:1856
gcpro1 = {
next = 0x3652032 <__register_frame_info+56959026>,
var = 0x0,
nvars = 54970394
}
exit_code = 0
#6 0x01128198 in Ffuncall (nargs=1, args=0x88f024) at eval.c:2674
fun = 18836885
original_fun = 55091586
funcar = 0
numargs = 0
lisp_numargs = 0
val = 54970418
backtrace = {
next = 0x88f2b0,
function = 55091586,
args = 0x88f028,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0x6e956f62
<libgcc_s_dw2-1!__deregister_frame_info_bases+442>
i = 1
#7 0x01163758 in exec_byte_code (bytestr=19079809, vector=19079829,
maxdepth=20,
args_template=54970394, nargs=0, args=0x0) at bytecode.c:900
targets = {0x11663d9 <exec_byte_code+13756>, 0x11663e5
<exec_byte_code+13768>,
0x11663e7 <exec_byte_code+13770>, 0x11663e9
<exec_byte_code+13772>,
0x11663eb <exec_byte_code+13774>, 0x11663eb
<exec_byte_code+13774>,
0x116643b <exec_byte_code+13854>, 0x116649d
<exec_byte_code+13952>,
0x11631a2 <exec_byte_code+901>, 0x11631a4 <exec_byte_code+903>,
0x11631a6 <exec_byte_code+905>, 0x11631a8 <exec_byte_code+907>,
0x11631aa <exec_byte_code+909>, 0x11631aa <exec_byte_code+909>,
0x11631b0 <exec_byte_code+915>, 0x116316d <exec_byte_code+848>,
0x11634ef <exec_byte_code+1746>, 0x11634f1 <exec_byte_code+1748>,
0x11634f3 <exec_byte_code+1750>, 0x11634f5 <exec_byte_code+1752>,
0x11634f7 <exec_byte_code+1754>, 0x11634f7 <exec_byte_code+1754>,
0x1163532 <exec_byte_code+1813>, 0x11634fd <exec_byte_code+1760>,
0x1163682 <exec_byte_code+2149>, 0x1163684 <exec_byte_code+2151>,
0x1163686 <exec_byte_code+2153>, 0x1163688 <exec_byte_code+2155>,
0x116368a <exec_byte_code+2157>, 0x116368a <exec_byte_code+2157>,
0x1163633 <exec_byte_code+2070>, 0x116364d <exec_byte_code+2096>,
0x116372b <exec_byte_code+2318>, 0x116372d <exec_byte_code+2320>,
0x116372f <exec_byte_code+2322>, 0x1163731 <exec_byte_code+2324>,
0x1163733 <exec_byte_code+2326>, 0x1163733 <exec_byte_code+2326>,
0x11636dc <exec_byte_code+2239>, 0x11636f6 <exec_byte_code+2265>,
0x11637d5 <exec_byte_code+2488>, 0x11637d7 <exec_byte_code+2490>,
0x11637d9 <exec_byte_code+2492>, 0x11637db <exec_byte_code+2494>,
0x11637dd <exec_byte_code+2496>, 0x11637dd <exec_byte_code+2496>,
0x1163786 <exec_byte_code+2409>, 0x11637a0 <exec_byte_code+2435>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x1164529 <exec_byte_code+5900>, 0x1164607 <exec_byte_code+6122>,
0x116464e <exec_byte_code+6193>, 0x1164695 <exec_byte_code+6264>,
0x11646dc <exec_byte_code+6335>, 0x11633da <exec_byte_code+1469>,
0x116342a <exec_byte_code+1549>, 0x1164731 <exec_byte_code+6420>,
0x1163364 <exec_byte_code+1351>, 0x1163478 <exec_byte_code+1627>,
0x1164779 <exec_byte_code+6492>, 0x11647cd <exec_byte_code+6576>,
0x1164812 <exec_byte_code+6645>, 0x1164877 <exec_byte_code+6746>,
0x11648bc <exec_byte_code+6815>, 0x116496d <exec_byte_code+6992>,
0x11649a8 <exec_byte_code+7051>, 0x11649fc <exec_byte_code+7135>,
0x1164a69 <exec_byte_code+7244>, 0x1164aa4 <exec_byte_code+7303>,
0x1164adf <exec_byte_code+7362>, 0x1164b33 <exec_byte_code+7446>,
0x1164b87 <exec_byte_code+7530>, 0x1164bdb <exec_byte_code+7614>,
0x1164c48 <exec_byte_code+7723>, 0x1164c8d <exec_byte_code+7792>,
0x1164cd2 <exec_byte_code+7861>, 0x1164d83 <exec_byte_code+8038>,
0x1164dfa <exec_byte_code+8157>, 0x1164e71 <exec_byte_code+8276>,
0x116502c <exec_byte_code+8719>, 0x1165080 <exec_byte_code+8803>,
0x11650d4 <exec_byte_code+8887>, 0x1165128 <exec_byte_code+8971>,
0x116517c <exec_byte_code+9055>, 0x11651c1 <exec_byte_code+9124>,
0x116523c <exec_byte_code+9247>, 0x1165281 <exec_byte_code+9316>,
0x11652c6 <exec_byte_code+9385>, 0x116530b <exec_byte_code+9454>,
0x11653e9 <exec_byte_code+9676>, 0x116424d <exec_byte_code+5168>,
0x1165436 <exec_byte_code+9753>, 0x1165471 <exec_byte_code+9812>,
0x116551e <exec_byte_code+9985>, 0x116556b
<exec_byte_code+10062>,
0x11655b8 <exec_byte_code+10139>, 0x11655f3
<exec_byte_code+10198>,
0x1165636 <exec_byte_code+10265>, 0x1165679
<exec_byte_code+10332>,
0x11656c0 <exec_byte_code+10403>, 0x11663d9
<exec_byte_code+13756>,
0x1165705 <exec_byte_code+10472>, 0x116573c
<exec_byte_code+10527>,
0x1165773 <exec_byte_code+10582>, 0x11657aa
<exec_byte_code+10637>,
0x11657e1 <exec_byte_code+10692>, 0x1165818
<exec_byte_code+10747>,
0x116424d <exec_byte_code+5168>, 0x11663d9
<exec_byte_code+13756>,
0x1165853 <exec_byte_code+10806>, 0x1165899
<exec_byte_code+10876>,
0x11658d4 <exec_byte_code+10935>, 0x116590f
<exec_byte_code+10994>,
0x1165963 <exec_byte_code+11078>, 0x11659b7
<exec_byte_code+11162>,
0x11659f2 <exec_byte_code+11221>, 0x1165b90
<exec_byte_code+11635>,
0x1165be4 <exec_byte_code+11719>, 0x1165c38
<exec_byte_code+11803>,
0x1165c8c <exec_byte_code+11887>, 0x1165cc3
<exec_byte_code+11942>,
0x11663d9 <exec_byte_code+13756>, 0x1164199
<exec_byte_code+4988>,
0x1163871 <exec_byte_code+2644>, 0x116325e <exec_byte_code+1089>,
0x1163963 <exec_byte_code+2886>, 0x1163a75 <exec_byte_code+3160>,
0x1163b7f <exec_byte_code+3426>, 0x116412c <exec_byte_code+4879>,
0x116416c <exec_byte_code+4943>, 0x11635f6 <exec_byte_code+2009>,
0x116420f <exec_byte_code+5106>, 0x116427b <exec_byte_code+5214>,
0x11642fb <exec_byte_code+5342>, 0x1164339 <exec_byte_code+5404>,
0x1164395 <exec_byte_code+5496>, 0x11643d7 <exec_byte_code+5562>,
0x1164444 <exec_byte_code+5671>, 0x11644ae <exec_byte_code+5777>,
0x1163834 <exec_byte_code+2583>, 0x1165cfe
<exec_byte_code+12001>,
0x1165d6b <exec_byte_code+12110>, 0x1165da6
<exec_byte_code+12169>,
0x1165de1 <exec_byte_code+12228>, 0x1165e1c
<exec_byte_code+12287>,
0x1165e57 <exec_byte_code+12346>, 0x1165eab
<exec_byte_code+12430>,
0x1165eff <exec_byte_code+12514>, 0x1165f53
<exec_byte_code+12598>,
0x1165fa7 <exec_byte_code+12682>, 0x11660bd
<exec_byte_code+12960>,
0x1166111 <exec_byte_code+13044>, 0x1166165
<exec_byte_code+13128>,
0x11661a0 <exec_byte_code+13187>, 0x11661f4
<exec_byte_code+13271>,
0x1166248 <exec_byte_code+13355>, 0x11662a1
<exec_byte_code+13444>,
0x11662fb <exec_byte_code+13534>, 0x1165350
<exec_byte_code+9523>,
0x1165395 <exec_byte_code+9592>, 0x1166340
<exec_byte_code+13603>,
0x1166393 <exec_byte_code+13686>, 0x11663d9
<exec_byte_code+13756>,
0x1163c89 <exec_byte_code+3692>, 0x1163d54 <exec_byte_code+3895>,
0x1163e4e <exec_byte_code+4145>, 0x1163f48 <exec_byte_code+4395>,
0x116403a <exec_byte_code+4637>, 0x1164901 <exec_byte_code+6884>,
0x1164d17 <exec_byte_code+7930>, 0x11654b2 <exec_byte_code+9877>,
0x1166521 <exec_byte_code+14084>, 0x1166583
<exec_byte_code+14182>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x1166607 <exec_byte_code+14314>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x1166680 <exec_byte_code+14435> <repeats 64 times>}
count = 7
op = 0
vectorp = 0x1232294
stack = {
pc = 0x137ad44 "\207",
byte_string = 19079809,
byte_string_start = 0x137aca4
"\306\b\307\"\210\307\310\311\312 \">\203\025",
next = 0x88f340
}
top = 0x88f024
result = 8975128
#8 0x01128a9c in funcall_lambda (fun=19079781, nargs=1,
arg_vector=0x346c81a <__register_frame_info+54970394>) at eval.c:2906
val = 54970394
syms_left = 54970394
next = 56642426
lexenv = 54970394
count = 6
i = 1
optional = true
rest = false
#9 0x011283bf in Ffuncall (nargs=2, args=0x88f314) at eval.c:2723
fun = 19079781
original_fun = 56959098
funcar = 8975312
numargs = 1
lisp_numargs = 8975240
val = 54970394
backtrace = {
next = 0x88f590,
function = 56959098,
args = 0x88f318,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x346c81a <__register_frame_info+54970394>
i = 0
#10 0x01163758 in exec_byte_code (bytestr=19080265, vector=19080285,
maxdepth=12,
args_template=54970394, nargs=0, args=0x0) at bytecode.c:900
targets = {0x11663d9 <exec_byte_code+13756>, 0x11663e5
<exec_byte_code+13768>,
0x11663e7 <exec_byte_code+13770>, 0x11663e9
<exec_byte_code+13772>,
0x11663eb <exec_byte_code+13774>, 0x11663eb
<exec_byte_code+13774>,
0x116643b <exec_byte_code+13854>, 0x116649d
<exec_byte_code+13952>,
0x11631a2 <exec_byte_code+901>, 0x11631a4 <exec_byte_code+903>,
0x11631a6 <exec_byte_code+905>, 0x11631a8 <exec_byte_code+907>,
0x11631aa <exec_byte_code+909>, 0x11631aa <exec_byte_code+909>,
0x11631b0 <exec_byte_code+915>, 0x116316d <exec_byte_code+848>,
0x11634ef <exec_byte_code+1746>, 0x11634f1 <exec_byte_code+1748>,
0x11634f3 <exec_byte_code+1750>, 0x11634f5 <exec_byte_code+1752>,
0x11634f7 <exec_byte_code+1754>, 0x11634f7 <exec_byte_code+1754>,
0x1163532 <exec_byte_code+1813>, 0x11634fd <exec_byte_code+1760>,
0x1163682 <exec_byte_code+2149>, 0x1163684 <exec_byte_code+2151>,
0x1163686 <exec_byte_code+2153>, 0x1163688 <exec_byte_code+2155>,
0x116368a <exec_byte_code+2157>, 0x116368a <exec_byte_code+2157>,
0x1163633 <exec_byte_code+2070>, 0x116364d <exec_byte_code+2096>,
0x116372b <exec_byte_code+2318>, 0x116372d <exec_byte_code+2320>,
0x116372f <exec_byte_code+2322>, 0x1163731 <exec_byte_code+2324>,
0x1163733 <exec_byte_code+2326>, 0x1163733 <exec_byte_code+2326>,
0x11636dc <exec_byte_code+2239>, 0x11636f6 <exec_byte_code+2265>,
0x11637d5 <exec_byte_code+2488>, 0x11637d7 <exec_byte_code+2490>,
0x11637d9 <exec_byte_code+2492>, 0x11637db <exec_byte_code+2494>,
0x11637dd <exec_byte_code+2496>, 0x11637dd <exec_byte_code+2496>,
0x1163786 <exec_byte_code+2409>, 0x11637a0 <exec_byte_code+2435>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x1164529 <exec_byte_code+5900>, 0x1164607 <exec_byte_code+6122>,
0x116464e <exec_byte_code+6193>, 0x1164695 <exec_byte_code+6264>,
0x11646dc <exec_byte_code+6335>, 0x11633da <exec_byte_code+1469>,
0x116342a <exec_byte_code+1549>, 0x1164731 <exec_byte_code+6420>,
0x1163364 <exec_byte_code+1351>, 0x1163478 <exec_byte_code+1627>,
0x1164779 <exec_byte_code+6492>, 0x11647cd <exec_byte_code+6576>,
0x1164812 <exec_byte_code+6645>, 0x1164877 <exec_byte_code+6746>,
0x11648bc <exec_byte_code+6815>, 0x116496d <exec_byte_code+6992>,
0x11649a8 <exec_byte_code+7051>, 0x11649fc <exec_byte_code+7135>,
0x1164a69 <exec_byte_code+7244>, 0x1164aa4 <exec_byte_code+7303>,
0x1164adf <exec_byte_code+7362>, 0x1164b33 <exec_byte_code+7446>,
0x1164b87 <exec_byte_code+7530>, 0x1164bdb <exec_byte_code+7614>,
0x1164c48 <exec_byte_code+7723>, 0x1164c8d <exec_byte_code+7792>,
0x1164cd2 <exec_byte_code+7861>, 0x1164d83 <exec_byte_code+8038>,
0x1164dfa <exec_byte_code+8157>, 0x1164e71 <exec_byte_code+8276>,
0x116502c <exec_byte_code+8719>, 0x1165080 <exec_byte_code+8803>,
0x11650d4 <exec_byte_code+8887>, 0x1165128 <exec_byte_code+8971>,
0x116517c <exec_byte_code+9055>, 0x11651c1 <exec_byte_code+9124>,
0x116523c <exec_byte_code+9247>, 0x1165281 <exec_byte_code+9316>,
0x11652c6 <exec_byte_code+9385>, 0x116530b <exec_byte_code+9454>,
0x11653e9 <exec_byte_code+9676>, 0x116424d <exec_byte_code+5168>,
0x1165436 <exec_byte_code+9753>, 0x1165471 <exec_byte_code+9812>,
0x116551e <exec_byte_code+9985>, 0x116556b
<exec_byte_code+10062>,
0x11655b8 <exec_byte_code+10139>, 0x11655f3
<exec_byte_code+10198>,
0x1165636 <exec_byte_code+10265>, 0x1165679
<exec_byte_code+10332>,
0x11656c0 <exec_byte_code+10403>, 0x11663d9
<exec_byte_code+13756>,
0x1165705 <exec_byte_code+10472>, 0x116573c
<exec_byte_code+10527>,
0x1165773 <exec_byte_code+10582>, 0x11657aa
<exec_byte_code+10637>,
0x11657e1 <exec_byte_code+10692>, 0x1165818
<exec_byte_code+10747>,
0x116424d <exec_byte_code+5168>, 0x11663d9
<exec_byte_code+13756>,
0x1165853 <exec_byte_code+10806>, 0x1165899
<exec_byte_code+10876>,
0x11658d4 <exec_byte_code+10935>, 0x116590f
<exec_byte_code+10994>,
0x1165963 <exec_byte_code+11078>, 0x11659b7
<exec_byte_code+11162>,
0x11659f2 <exec_byte_code+11221>, 0x1165b90
<exec_byte_code+11635>,
0x1165be4 <exec_byte_code+11719>, 0x1165c38
<exec_byte_code+11803>,
0x1165c8c <exec_byte_code+11887>, 0x1165cc3
<exec_byte_code+11942>,
0x11663d9 <exec_byte_code+13756>, 0x1164199
<exec_byte_code+4988>,
0x1163871 <exec_byte_code+2644>, 0x116325e <exec_byte_code+1089>,
0x1163963 <exec_byte_code+2886>, 0x1163a75 <exec_byte_code+3160>,
0x1163b7f <exec_byte_code+3426>, 0x116412c <exec_byte_code+4879>,
0x116416c <exec_byte_code+4943>, 0x11635f6 <exec_byte_code+2009>,
0x116420f <exec_byte_code+5106>, 0x116427b <exec_byte_code+5214>,
0x11642fb <exec_byte_code+5342>, 0x1164339 <exec_byte_code+5404>,
0x1164395 <exec_byte_code+5496>, 0x11643d7 <exec_byte_code+5562>,
0x1164444 <exec_byte_code+5671>, 0x11644ae <exec_byte_code+5777>,
0x1163834 <exec_byte_code+2583>, 0x1165cfe
<exec_byte_code+12001>,
0x1165d6b <exec_byte_code+12110>, 0x1165da6
<exec_byte_code+12169>,
0x1165de1 <exec_byte_code+12228>, 0x1165e1c
<exec_byte_code+12287>,
0x1165e57 <exec_byte_code+12346>, 0x1165eab
<exec_byte_code+12430>,
0x1165eff <exec_byte_code+12514>, 0x1165f53
<exec_byte_code+12598>,
0x1165fa7 <exec_byte_code+12682>, 0x11660bd
<exec_byte_code+12960>,
0x1166111 <exec_byte_code+13044>, 0x1166165
<exec_byte_code+13128>,
0x11661a0 <exec_byte_code+13187>, 0x11661f4
<exec_byte_code+13271>,
0x1166248 <exec_byte_code+13355>, 0x11662a1
<exec_byte_code+13444>,
0x11662fb <exec_byte_code+13534>, 0x1165350
<exec_byte_code+9523>,
0x1165395 <exec_byte_code+9592>, 0x1166340
<exec_byte_code+13603>,
0x1166393 <exec_byte_code+13686>, 0x11663d9
<exec_byte_code+13756>,
0x1163c89 <exec_byte_code+3692>, 0x1163d54 <exec_byte_code+3895>,
0x1163e4e <exec_byte_code+4145>, 0x1163f48 <exec_byte_code+4395>,
0x116403a <exec_byte_code+4637>, 0x1164901 <exec_byte_code+6884>,
0x1164d17 <exec_byte_code+7930>, 0x11654b2 <exec_byte_code+9877>,
0x1166521 <exec_byte_code+14084>, 0x1166583
<exec_byte_code+14182>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x1166607 <exec_byte_code+14314>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x1166680 <exec_byte_code+14435> <repeats 64 times>}
count = 6
op = 1
vectorp = 0x123245c
stack = {
pc = 0x137abc8 "\207",
byte_string = 19080265,
byte_string_start = 0x137abb9 "\301\302 \303\"\203\f",
next = 0x88f8c0
}
top = 0x88f314
result = 0
#11 0x01128a9c in funcall_lambda (fun=19080237, nargs=1,
arg_vector=0x346c81a <__register_frame_info+54970394>) at eval.c:2906
val = 55078394
syms_left = 54970394
next = 56642426
lexenv = 54970394
count = 5
i = 1
optional = true
rest = false
#12 0x011283bf in Ffuncall (nargs=2, args=0x88f640) at eval.c:2723
fun = 19080237
original_fun = 56959266
funcar = 8976512
numargs = 1
lisp_numargs = 8975832
val = 54970394
backtrace = {
next = 0x88f800,
function = 56959266,
args = 0x88f644,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x88f880
i = 54970394
#13 0x01123f45 in Fcall_interactively (function=56959266,
record_flag=54970394,
keys=54992221) at callint.c:839
val = 54970394
args = 0x88f640
visargs = 0x88f620
specs = 18930537
filter_specs = 18930537
teml = 17990073
up_event = 54970394
enable = 54970394
speccount = 3
next_event = 2
prefix_arg = 54970394
string = 0x88f660 "P"
tem = 0x13bb2e4 ""
varies = 0x88f600 ""
i = 2
nargs = 2
mark = 57300686
arg_from_tty = false
gcpro1 = {
next = 0x3,
var = 0x0,
nvars = 0
}
gcpro2 = {
next = 0x88f9a0,
var = 0x88fa5c,
nvars = 1
}
gcpro3 = {
next = 0x53d4866,
var = 0x346c81a <__register_frame_info+54970394>,
nvars = 2
}
gcpro4 = {
next = 0x0,
var = 0x88f6f8,
nvars = 2
}
gcpro5 = {
next = 0x0,
var = 0x346c81a <__register_frame_info+54970394>,
nvars = 8976224
}
key_count = 2
record_then_fail = false
save_this_command = 56959266
save_last_command = 97854826
save_this_original_command = 56959266
save_real_this_command = 56959266
#14 0x011281e3 in Ffuncall (nargs=4, args=0x88f87c) at eval.c:2681
fun = 20606045
original_fun = 55080490
funcar = 0
numargs = 3
lisp_numargs = 0
val = 54970394
backtrace = {
next = 0x88fb10,
function = 55080490,
args = 0x88f880,
nargs = 3,
debug_on_exit = 0
}
internal_args = 0x88f880
i = 2
#15 0x01163758 in exec_byte_code (bytestr=19300193, vector=19300213,
maxdepth=52,
args_template=4100, nargs=1, args=0x88fb80) at bytecode.c:900
targets = {0x11663d9 <exec_byte_code+13756>, 0x11663e5
<exec_byte_code+13768>,
0x11663e7 <exec_byte_code+13770>, 0x11663e9
<exec_byte_code+13772>,
0x11663eb <exec_byte_code+13774>, 0x11663eb
<exec_byte_code+13774>,
0x116643b <exec_byte_code+13854>, 0x116649d
<exec_byte_code+13952>,
0x11631a2 <exec_byte_code+901>, 0x11631a4 <exec_byte_code+903>,
0x11631a6 <exec_byte_code+905>, 0x11631a8 <exec_byte_code+907>,
0x11631aa <exec_byte_code+909>, 0x11631aa <exec_byte_code+909>,
0x11631b0 <exec_byte_code+915>, 0x116316d <exec_byte_code+848>,
0x11634ef <exec_byte_code+1746>, 0x11634f1 <exec_byte_code+1748>,
0x11634f3 <exec_byte_code+1750>, 0x11634f5 <exec_byte_code+1752>,
0x11634f7 <exec_byte_code+1754>, 0x11634f7 <exec_byte_code+1754>,
0x1163532 <exec_byte_code+1813>, 0x11634fd <exec_byte_code+1760>,
0x1163682 <exec_byte_code+2149>, 0x1163684 <exec_byte_code+2151>,
0x1163686 <exec_byte_code+2153>, 0x1163688 <exec_byte_code+2155>,
0x116368a <exec_byte_code+2157>, 0x116368a <exec_byte_code+2157>,
0x1163633 <exec_byte_code+2070>, 0x116364d <exec_byte_code+2096>,
0x116372b <exec_byte_code+2318>, 0x116372d <exec_byte_code+2320>,
0x116372f <exec_byte_code+2322>, 0x1163731 <exec_byte_code+2324>,
0x1163733 <exec_byte_code+2326>, 0x1163733 <exec_byte_code+2326>,
0x11636dc <exec_byte_code+2239>, 0x11636f6 <exec_byte_code+2265>,
0x11637d5 <exec_byte_code+2488>, 0x11637d7 <exec_byte_code+2490>,
0x11637d9 <exec_byte_code+2492>, 0x11637db <exec_byte_code+2494>,
0x11637dd <exec_byte_code+2496>, 0x11637dd <exec_byte_code+2496>,
0x1163786 <exec_byte_code+2409>, 0x11637a0 <exec_byte_code+2435>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x1164529 <exec_byte_code+5900>, 0x1164607 <exec_byte_code+6122>,
0x116464e <exec_byte_code+6193>, 0x1164695 <exec_byte_code+6264>,
0x11646dc <exec_byte_code+6335>, 0x11633da <exec_byte_code+1469>,
0x116342a <exec_byte_code+1549>, 0x1164731 <exec_byte_code+6420>,
0x1163364 <exec_byte_code+1351>, 0x1163478 <exec_byte_code+1627>,
0x1164779 <exec_byte_code+6492>, 0x11647cd <exec_byte_code+6576>,
0x1164812 <exec_byte_code+6645>, 0x1164877 <exec_byte_code+6746>,
0x11648bc <exec_byte_code+6815>, 0x116496d <exec_byte_code+6992>,
0x11649a8 <exec_byte_code+7051>, 0x11649fc <exec_byte_code+7135>,
0x1164a69 <exec_byte_code+7244>, 0x1164aa4 <exec_byte_code+7303>,
0x1164adf <exec_byte_code+7362>, 0x1164b33 <exec_byte_code+7446>,
0x1164b87 <exec_byte_code+7530>, 0x1164bdb <exec_byte_code+7614>,
0x1164c48 <exec_byte_code+7723>, 0x1164c8d <exec_byte_code+7792>,
0x1164cd2 <exec_byte_code+7861>, 0x1164d83 <exec_byte_code+8038>,
0x1164dfa <exec_byte_code+8157>, 0x1164e71 <exec_byte_code+8276>,
0x116502c <exec_byte_code+8719>, 0x1165080 <exec_byte_code+8803>,
0x11650d4 <exec_byte_code+8887>, 0x1165128 <exec_byte_code+8971>,
0x116517c <exec_byte_code+9055>, 0x11651c1 <exec_byte_code+9124>,
0x116523c <exec_byte_code+9247>, 0x1165281 <exec_byte_code+9316>,
0x11652c6 <exec_byte_code+9385>, 0x116530b <exec_byte_code+9454>,
0x11653e9 <exec_byte_code+9676>, 0x116424d <exec_byte_code+5168>,
0x1165436 <exec_byte_code+9753>, 0x1165471 <exec_byte_code+9812>,
0x116551e <exec_byte_code+9985>, 0x116556b
<exec_byte_code+10062>,
0x11655b8 <exec_byte_code+10139>, 0x11655f3
<exec_byte_code+10198>,
0x1165636 <exec_byte_code+10265>, 0x1165679
<exec_byte_code+10332>,
0x11656c0 <exec_byte_code+10403>, 0x11663d9
<exec_byte_code+13756>,
0x1165705 <exec_byte_code+10472>, 0x116573c
<exec_byte_code+10527>,
0x1165773 <exec_byte_code+10582>, 0x11657aa
<exec_byte_code+10637>,
0x11657e1 <exec_byte_code+10692>, 0x1165818
<exec_byte_code+10747>,
0x116424d <exec_byte_code+5168>, 0x11663d9
<exec_byte_code+13756>,
0x1165853 <exec_byte_code+10806>, 0x1165899
<exec_byte_code+10876>,
0x11658d4 <exec_byte_code+10935>, 0x116590f
<exec_byte_code+10994>,
0x1165963 <exec_byte_code+11078>, 0x11659b7
<exec_byte_code+11162>,
0x11659f2 <exec_byte_code+11221>, 0x1165b90
<exec_byte_code+11635>,
0x1165be4 <exec_byte_code+11719>, 0x1165c38
<exec_byte_code+11803>,
0x1165c8c <exec_byte_code+11887>, 0x1165cc3
<exec_byte_code+11942>,
0x11663d9 <exec_byte_code+13756>, 0x1164199
<exec_byte_code+4988>,
0x1163871 <exec_byte_code+2644>, 0x116325e <exec_byte_code+1089>,
0x1163963 <exec_byte_code+2886>, 0x1163a75 <exec_byte_code+3160>,
0x1163b7f <exec_byte_code+3426>, 0x116412c <exec_byte_code+4879>,
0x116416c <exec_byte_code+4943>, 0x11635f6 <exec_byte_code+2009>,
0x116420f <exec_byte_code+5106>, 0x116427b <exec_byte_code+5214>,
0x11642fb <exec_byte_code+5342>, 0x1164339 <exec_byte_code+5404>,
0x1164395 <exec_byte_code+5496>, 0x11643d7 <exec_byte_code+5562>,
0x1164444 <exec_byte_code+5671>, 0x11644ae <exec_byte_code+5777>,
0x1163834 <exec_byte_code+2583>, 0x1165cfe
<exec_byte_code+12001>,
0x1165d6b <exec_byte_code+12110>, 0x1165da6
<exec_byte_code+12169>,
0x1165de1 <exec_byte_code+12228>, 0x1165e1c
<exec_byte_code+12287>,
0x1165e57 <exec_byte_code+12346>, 0x1165eab
<exec_byte_code+12430>,
0x1165eff <exec_byte_code+12514>, 0x1165f53
<exec_byte_code+12598>,
0x1165fa7 <exec_byte_code+12682>, 0x11660bd
<exec_byte_code+12960>,
0x1166111 <exec_byte_code+13044>, 0x1166165
<exec_byte_code+13128>,
0x11661a0 <exec_byte_code+13187>, 0x11661f4
<exec_byte_code+13271>,
0x1166248 <exec_byte_code+13355>, 0x11662a1
<exec_byte_code+13444>,
0x11662fb <exec_byte_code+13534>, 0x1165350
<exec_byte_code+9523>,
0x1165395 <exec_byte_code+9592>, 0x1166340
<exec_byte_code+13603>,
0x1166393 <exec_byte_code+13686>, 0x11663d9
<exec_byte_code+13756>,
0x1163c89 <exec_byte_code+3692>, 0x1163d54 <exec_byte_code+3895>,
0x1163e4e <exec_byte_code+4145>, 0x1163f48 <exec_byte_code+4395>,
0x116403a <exec_byte_code+4637>, 0x1164901 <exec_byte_code+6884>,
0x1164d17 <exec_byte_code+7930>, 0x11654b2 <exec_byte_code+9877>,
0x1166521 <exec_byte_code+14084>, 0x1166583
<exec_byte_code+14182>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x1166607 <exec_byte_code+14314>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x11663d9 <exec_byte_code+13756>, 0x11663d9
<exec_byte_code+13756>,
0x1166680 <exec_byte_code+14435> <repeats 64 times>}
count = 3
op = 3
vectorp = 0x1267f74
stack = {
pc = 0x13582c5 "\006\006\071\203\225",
byte_string = 19300193,
byte_string_start = 0x1358257 "\306\020\211?\205\f",
next = 0x0
}
top = 0x88f87c
result = 30298883
#16 0x01128815 in funcall_lambda (fun=19300173, nargs=1, arg_vector=0x1004)
at eval.c:2840
val = 21206348
syms_left = 4100
next = 0
lexenv = 0
count = 3
i = 239000000
optional = false
rest = false
#17 0x011283bf in Ffuncall (nargs=2, args=0x88fb78) at eval.c:2723
fun = 19300173
original_fun = 55012098
funcar = 0
numargs = 1
lisp_numargs = 0
val = 8977256
backtrace = {
next = 0x0,
function = 55012098,
args = 0x88fb7c,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x7efde000
i = 0
#18 0x01127cce in call1 (fn=55012098, arg1=56959266) at eval.c:2468
ret_ungc_val = 54970394
gcpro1 = {
next = 0x0,
var = 0x3652122 <__register_frame_info+56959266>,
nvars = 2
}
args = {55012098, 56959266}
#19 0x010a9dda in command_loop_1 () at keyboard.c:1578
scount = 2
cmd = 56959266
keybuf = {96, 12, 8977464, 17993845, 55078394, 54970394,
21153724, 54996480,
8977624, 8977628, 0, 55078394, 54970394, 0, 0, 17993397,
55078394, 54970394,
56657694, 19128981, 0, 54970394, 0, 54970394, 0, 0, 8977512,
17984453, 2,
56657694}
i = 2
prev_modiff = 1
prev_buffer = 0x3472e00 <__register_frame_info+54996480>
already_adjusted = false
#20 0x01125abd in internal_condition_case (bfun=0x10a96f5 <command_loop_1>,
handlers=55016570, hfun=0x10a90ed <cmd_error>) at eval.c:1193
val = 56657694
c = {
tag = 54970394,
val = 54970394,
next = 0x88fd74,
gcpro = 0x0,
jmp = {8977720, 2130567168, 0, 0, 8977548, 17980010, 8978372,
0, 11529984,
8977684, 1984207565, 11529984, 0, 1959604792, 0, 1033},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 0,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 55016570,
var = 54970394,
chosen_clause = 1996779989,
tag = 0x88fcc0,
next = 0x0
}
#21 0x010a946f in command_loop_2 (ignore=54970394) at keyboard.c:1167
val = 2130567168
#22 0x01125635 in internal_catch (tag=55010546, func=0x10a944b
<command_loop_2>,
arg=54970394) at eval.c:964
c = {
tag = 55010546,
val = 54970394,
next = 0x0,
gcpro = 0x0,
jmp = {8977896, 2130567168, 0, 0, 8977756, 17978918, 8978372,
0, 54970394,
54996480, 1959606080, 1959606143, 2130567168, 8977896,
17893633, 20911284},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 0,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#23 0x010a9427 in command_loop () at keyboard.c:1146
No locals.
#24 0x010a8d33 in recursive_edit_1 () at keyboard.c:779
count = 1
val = 1958978626
#25 0x010a8e84 in Frecursive_edit () at keyboard.c:843
count = 0
buffer = 54970394
#26 0x010a725c in main (argc=1, argv=0xd71768) at emacs.c:1531
dummy = 8978152
stack_bottom_variable = 0 '\000'
do_initial_setlocale = true
dumping = false
skip_args = 0
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
Lisp Backtrace:
"kill-emacs" (0x88f028)
"save-buffers-kill-emacs" (0x88f318)
"save-buffers-kill-terminal" (0x88f644)
"call-interactively" (0x88f880)
"command-execute" (0x88fb7c)
(gdb)
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-17 14:03 ` Dmitry Gutov
@ 2013-05-17 14:26 ` Eli Zaretskii
2013-05-17 15:29 ` Dmitry Gutov
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-17 14:26 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Date: Fri, 17 May 2013 18:03:12 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> (gdb) bt
> #0 0x74c98e76 in msvcrt!abort () from C:\windows\syswow64\msvcrt.dll
> #1 0x6e956f62 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
> from J:\Apps\System\MinGW\bin\libgcc_s_dw2-1.dll
Hello, old foe! This is a known issue with libgcc_s_dw2-1.dll, see
https://sourceforge.net/mailarchive/message.php?msg_id=30633081
Please run depends.exe on your DLLs that Emacs loads dynamically, and
find out which one(s) depend(s) on libgcc_s_dw2-1.dll. My guess is
some image library.
(Did I already say that libgcc_s_dw2-1.dll is evil?)
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-17 14:26 ` Eli Zaretskii
@ 2013-05-17 15:29 ` Dmitry Gutov
2013-05-17 16:05 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dmitry Gutov @ 2013-05-17 15:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 17.05.2013 18:26, Eli Zaretskii wrote:
>> Date: Fri, 17 May 2013 18:03:12 +0400
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> CC: emacs-devel@gnu.org
>>
>> (gdb) bt
>> #0 0x74c98e76 in msvcrt!abort () from C:\windows\syswow64\msvcrt.dll
>> #1 0x6e956f62 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
>> from J:\Apps\System\MinGW\bin\libgcc_s_dw2-1.dll
>
> Hello, old foe! This is a known issue with libgcc_s_dw2-1.dll, see
>
> https://sourceforge.net/mailarchive/message.php?msg_id=30633081
>
> Please run depends.exe on your DLLs that Emacs loads dynamically, and
This one? http://www.dependencywalker.com/
> find out which one(s) depend(s) on libgcc_s_dw2-1.dll. My guess is
> some image library.
Do you mean only libs from `dynamic-library-alist'?
Not zlib1.dll, jpeg-62.dll, libpng14-14.dll or giflib4.dll.
libgnutls-28 depends on libintl-8.dll, which in turn depends on the lib
in question.
Dependency Walker also adds "Warning: At least one delay-load dependency
module was not found.
Warning: At least one module has an unresolved import due to a missing
export function in a delay-load dependent module."
Should I try to get rid of libgcc_s_dw2-1.dll and look for libintl or
libgnutls version that doesn't depend on it?
> (Did I already say that libgcc_s_dw2-1.dll is evil?)
I believe you have, yes. It sound pretty nasty.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-17 15:29 ` Dmitry Gutov
@ 2013-05-17 16:05 ` Eli Zaretskii
2013-05-17 16:30 ` Dmitry Gutov
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-17 16:05 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Date: Fri, 17 May 2013 19:29:23 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> > Please run depends.exe on your DLLs that Emacs loads dynamically, and
>
> This one? http://www.dependencywalker.com/
Yes.
> > find out which one(s) depend(s) on libgcc_s_dw2-1.dll. My guess is
> > some image library.
>
> Do you mean only libs from `dynamic-library-alist'?
Yes. The rest are Windows DLLs, and cannot possibly depend on libgcc.
> libgnutls-28 depends on libintl-8.dll, which in turn depends on the lib
> in question.
That's what I thought, sigh.
> Dependency Walker also adds "Warning: At least one delay-load dependency
> module was not found.
> Warning: At least one module has an unresolved import due to a missing
> export function in a delay-load dependent module."
That's normal, you can see the libraries it didn't find below. They
are not needed.
> Should I try to get rid of libgcc_s_dw2-1.dll and look for libintl or
> libgnutls version that doesn't depend on it?
GnuTLS always depends on libintl, but you can find a libintl that
doesn't need libgcc_s_dw2-1.dll. The one that came with my libgnutls
port, here:
http://sourceforge.net/projects/ezwinports/files/gnutls-3.0.9-w32-bin.zip/download
doesn't require libgcc (it was linked against it statically).
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-17 16:05 ` Eli Zaretskii
@ 2013-05-17 16:30 ` Dmitry Gutov
2013-05-17 17:40 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dmitry Gutov @ 2013-05-17 16:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 17.05.2013 20:05, Eli Zaretskii wrote:
>> libgnutls-28 depends on libintl-8.dll, which in turn depends on the lib
>> in question.
>
> That's what I thought, sigh.
>
>> Should I try to get rid of libgcc_s_dw2-1.dll and look for libintl or
>> libgnutls version that doesn't depend on it?
>
> GnuTLS always depends on libintl, but you can find a libintl that
> doesn't need libgcc_s_dw2-1.dll. The one that came with my libgnutls
> port, here:
>
> http://sourceforge.net/projects/ezwinports/files/gnutls-3.0.9-w32-bin.zip/download
>
> doesn't require libgcc (it was linked against it statically).
That fixed it, thanks for your help.
I remember choosing not to overwrite the existing libintl DLL with the
one that came with your GnuTLS build, because the existing one was newer.
Looks like another good candidate for mentioning in INSTALL.MSYS.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-17 16:30 ` Dmitry Gutov
@ 2013-05-17 17:40 ` Eli Zaretskii
2013-05-17 18:43 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-17 17:40 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Date: Fri, 17 May 2013 20:30:18 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> I remember choosing not to overwrite the existing libintl DLL with the
> one that came with your GnuTLS build, because the existing one was newer.
That's the correct decision, in general. You couldn't have known
about this obscure problem.
> Looks like another good candidate for mentioning in INSTALL.MSYS.
I'd rather we unload all the DLLs before we exit, to avoid such
problems in the first place. Patches are welcome.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-17 17:40 ` Eli Zaretskii
@ 2013-05-17 18:43 ` Eli Zaretskii
2013-05-17 20:47 ` Dmitry Gutov
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-17 18:43 UTC (permalink / raw)
To: dgutov; +Cc: emacs-devel
> Date: Fri, 17 May 2013 20:40:45 +0300
> Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and
> truncated.
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
>
> > Looks like another good candidate for mentioning in INSTALL.MSYS.
>
> I'd rather we unload all the DLLs before we exit, to avoid such
> problems in the first place.
Like in the patch below. Can you try that? (I hope you still have
that libintl-8.dll somewhere which required libgcc_s_dw2-1.dll, and
can reinstate it at least for the purposes of testing this patch.)
=== modified file 'src/w32.c'
--- src/w32.c 2013-04-15 13:39:41 +0000
+++ src/w32.c 2013-05-17 18:39:41 +0000
@@ -7404,13 +7404,9 @@ sys_localtime (const time_t *t)
\f
/* Try loading LIBRARY_ID from the file(s) specified in
Vdynamic_library_alist. If the library is loaded successfully,
- return the handle of the DLL, and record the filename in the
- property :loaded-from of LIBRARY_ID. If the library could not be
- found, or when it was already loaded (because the handle is not
- recorded anywhere, and so is lost after use), return NULL.
-
- We could also save the handle in :loaded-from, but currently
- there's no use case for it. */
+ return the handle of the DLL, and record the filename and the
+ handle in the property :loaded-from of LIBRARY_ID. If the library
+ could not be found, or when it was already loaded, return NULL. */
HMODULE
w32_delayed_load (Lisp_Object library_id)
{
@@ -7434,11 +7430,12 @@ w32_delayed_load (Lisp_Object library_id
DWORD len;
len = GetModuleFileNameA (library_dll, name, sizeof (name));
- found = Fcons (XCAR (dlls),
- (len > 0)
- /* Possibly truncated */
- ? make_specified_string (name, -1, len, 1)
- : Qnil);
+ found = list3 (XCAR (dlls),
+ ((len > 0)
+ /* Possibly truncated */
+ ? make_specified_string (name, -1, len, 1)
+ : Qnil),
+ XIL ((EMACS_INT)library_dll));
break;
}
}
@@ -7449,6 +7446,36 @@ w32_delayed_load (Lisp_Object library_id
return library_dll;
}
+/* Unload any dynamic libraries we loaded. Called at exit. */
+static void
+unload_dlls (void)
+{
+ Lisp_Object dyn_alist = Vdynamic_library_alist;
+
+ while (CONSP (dyn_alist))
+ {
+ Lisp_Object elt = XCAR (dyn_alist), sym = Qnil;
+ Lisp_Object loaded_from = Qnil;
+
+ if (CONSP (elt))
+ {
+ sym = XCAR (elt);
+ if (SYMBOLP (sym))
+ loaded_from = Fget (sym, QCloaded_from);
+ }
+
+ if (CONSP (loaded_from)
+ && CONSP (XCDR (XCDR (loaded_from)))
+ && INTEGERP (XCAR (XCDR (XCDR (loaded_from)))))
+ {
+ HANDLE lh = (HANDLE)XLI (XCAR (XCDR (XCDR (loaded_from))));
+
+ FreeLibrary (lh);
+ }
+ dyn_alist = XCDR (dyn_alist);
+ }
+}
+
\f
void
check_windows_init_file (void)
@@ -7505,6 +7532,8 @@ term_ntproc (int ignored)
{
(void)ignored;
+ unload_dlls ();
+
term_timers ();
/* shutdown the socket interface if necessary */
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-17 18:43 ` Eli Zaretskii
@ 2013-05-17 20:47 ` Dmitry Gutov
2013-05-18 7:18 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dmitry Gutov @ 2013-05-17 20:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 17.05.2013 22:43, Eli Zaretskii wrote:
>> Date: Fri, 17 May 2013 20:40:45 +0300
>> Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and
>> truncated.
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>>> Looks like another good candidate for mentioning in INSTALL.MSYS.
>>
>> I'd rather we unload all the DLLs before we exit, to avoid such
>> problems in the first place.
>
> Like in the patch below. Can you try that? (I hope you still have
> that libintl-8.dll somewhere which required libgcc_s_dw2-1.dll, and
> can reinstate it at least for the purposes of testing this patch.)
No such luck, but the libintl build here:
http://sourceforge.net/projects/mingw/files/MinGW/Base/gettext/gettext-0.18.1.1-2/
(third item from the top) has the same dependency problem.
The patch doesn't seem to have the desired effect (and I've tried make
clean && make CFLAGS="-g3").
Moreover, despite the above CFLAGS value, I'm unable to obtain detailed
backtrace here:
Breakpoint 3, 0x74c98e76 in msvcrt!abort ()
from C:\windows\syswow64\msvcrt.dll
(gdb) bt full
#0 0x74c98e76 in msvcrt!abort () from C:\windows\syswow64\msvcrt.dll
No symbol table info available.
#1 0x6e956f62 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
from J:\Apps\System\MinGW\bin\libgcc_s_dw2-1.dll
No symbol table info available.
#2 0x00000000 in ?? ()
No symbol table info available.
Lisp Backtrace:
"kill-emacs" (0x88f028)
"save-buffers-kill-emacs" (0x88f318)
"save-buffers-kill-terminal" (0x88f644)
"call-interactively" (0x88f880)
"command-execute" (0x88fb7c)
(gdb)
If I revert the patch, recompile and reproduce it again, 'bt full'
outputs it full, no problem.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-17 20:47 ` Dmitry Gutov
@ 2013-05-18 7:18 ` Eli Zaretskii
2013-05-18 8:08 ` Dmitry Gutov
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-18 7:18 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Date: Sat, 18 May 2013 00:47:50 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> The patch doesn't seem to have the desired effect (and I've tried make
> clean && make CFLAGS="-g3").
>
> Moreover, despite the above CFLAGS value, I'm unable to obtain detailed
> backtrace here:
>
> Breakpoint 3, 0x74c98e76 in msvcrt!abort ()
> from C:\windows\syswow64\msvcrt.dll
> (gdb) bt full
> #0 0x74c98e76 in msvcrt!abort () from C:\windows\syswow64\msvcrt.dll
> No symbol table info available.
> #1 0x6e956f62 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
> from J:\Apps\System\MinGW\bin\libgcc_s_dw2-1.dll
> No symbol table info available.
> #2 0x00000000 in ?? ()
> No symbol table info available.
>
> Lisp Backtrace:
> "kill-emacs" (0x88f028)
> "save-buffers-kill-emacs" (0x88f318)
> "save-buffers-kill-terminal" (0x88f644)
> "call-interactively" (0x88f880)
> "command-execute" (0x88fb7c)
> (gdb)
>
> If I revert the patch, recompile and reproduce it again, 'bt full'
> outputs it full, no problem.
Sorry, I don't follow. Are you saying that there's still a crash
after applying the patch, except that you cannot get a backtrace when
the crash happens? What exactly happens when you try to produce a
backtrace? Are you sure you switch to the correct thread when asking
for a backtrace? Try "info threads" and "thread apply all bt".
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-18 7:18 ` Eli Zaretskii
@ 2013-05-18 8:08 ` Dmitry Gutov
2013-05-18 9:08 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dmitry Gutov @ 2013-05-18 8:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 18.05.2013 11:18, Eli Zaretskii wrote:
>> The patch doesn't seem to have the desired effect (and I've tried make
>> clean && make CFLAGS="-g3").
>>
>> Moreover, despite the above CFLAGS value, I'm unable to obtain detailed
>> backtrace here:
>> ...
>> If I revert the patch, recompile and reproduce it again, 'bt full'
>> outputs it full, no problem.
>
> Sorry, I don't follow. Are you saying that there's still a crash
> after applying the patch, except that you cannot get a backtrace when
> the crash happens?
Yes.
> What exactly happens when you try to produce a
> backtrace?
I get the output I sent in the previous email.
> Are you sure you switch to the correct thread when asking
> for a backtrace?
Doesn't 'abort' breakpoint hit guarantee that I'm on the right thread?
> Try "info threads" and "thread apply all bt".
(gdb) info threads
Id Target Id Frame
5 Thread 1360.0x1318 0x77541dfe in
ntdll!LdrQueryProcessModuleInformation
() from C:\windows\system32\ntdll.dll
4 Thread 1360.0x204 0x751178d7 in USER32!IsDialogMessage ()
from C:\windows\syswow64\user32.dll
3 Thread 1360.0x558 0x7753fd71 in ntdll!RtlFindSetBits ()
from C:\windows\system32\ntdll.dll
2 Thread 1360.0xe24 0x7754013d in
ntdll!RtlEnableEarlyCriticalSectionEventCreation () from
C:\windows\system32\ntdll.dll
* 1 Thread 1360.0xe28 0x76ba8e76 in msvcrt!abort ()
from C:\windows\syswow64\msvcrt.dll
(gdb) thread apply all bt
Thread 5 (Thread 1360.0x1318):
#0 0x77541dfe in ntdll!LdrQueryProcessModuleInformation ()
from C:\windows\system32\ntdll.dll
#1 0x77541dfe in ntdll!LdrQueryProcessModuleInformation ()
from C:\windows\system32\ntdll.dll
#2 0x77577156 in ntdll!RtlTraceDatabaseLock ()
from C:\windows\system32\ntdll.dll
#3 0x00000010 in ?? ()
#4 0x00000000 in ?? ()
Lisp Backtrace:
"kill-emacs" (0x88f028)
"save-buffers-kill-emacs" (0x88f318)
"save-buffers-kill-terminal" (0x88f644)
"call-interactively" (0x88f880)
"command-execute" (0x88fb7c)
Thread 4 (Thread 1360.0x204):
#0 0x751178d7 in USER32!IsDialogMessage ()
from C:\windows\syswow64\user32.dll
#1 0x751178d7 in USER32!IsDialogMessage ()
from C:\windows\syswow64\user32.dll
#2 0x7511790d in USER32!GetCursorPos () from C:\windows\syswow64\user32.dll
#3 0x6c9afec0 in ?? ()
#4 0x011a0185 in w32_msg_pump (msg_buf=0x6c9aff28) at w32fns.c:2417
#5 0x011a03c3 in w32_msg_worker@4 (arg=0x0) at w32fns.c:2643
#6 0x76f333aa in KERNEL32!BaseCleanupAppcompatCacheSupport ()
from C:\windows\syswow64\kernel32.dll
#7 0x6c9affd4 in ?? ()
#8 0x77559ef2 in ntdll!RtlpNtSetValueKey ()
from C:\windows\system32\ntdll.dll
#9 0x00000000 in ?? ()
Lisp Backtrace:
"kill-emacs" (0x88f028)
"save-buffers-kill-emacs" (0x88f318)
"save-buffers-kill-terminal" (0x88f644)
"call-interactively" (0x88f880)
"command-execute" (0x88fb7c)
Thread 3 (Thread 1360.0x558):
#0 0x7753fd71 in ntdll!RtlFindSetBits () from C:\windows\system32\ntdll.dll
#1 0x75213bc8 in SleepEx () from C:\windows\syswow64\KernelBase.dll
#2 0x00000000 in ?? ()
Lisp Backtrace:
"kill-emacs" (0x88f028)
"save-buffers-kill-emacs" (0x88f318)
"save-buffers-kill-terminal" (0x88f644)
"call-interactively" (0x88f880)
"command-execute" (0x88fb7c)
Thread 2 (Thread 1360.0xe24):
#0 0x7754013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from C:\windows\system32\ntdll.dll
#1 0x7754013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from C:\windows\system32\ntdll.dll
#2 0x77572f51 in ntdll!RtlWeaklyEnumerateEntryHashTable ()
from C:\windows\system32\ntdll.dll
#3 0x00000003 in ?? ()
#4 0x00ab3a40 in ?? ()
#5 0x76f333aa in KERNEL32!BaseCleanupAppcompatCacheSupport ()
from C:\windows\syswow64\kernel32.dll
#6 0x6bf2ffd4 in ?? ()
#7 0x77559ef2 in ntdll!RtlpNtSetValueKey ()
from C:\windows\system32\ntdll.dll
#8 0x00ab3a10 in ?? ()
#9 0x77559ec5 in ntdll!RtlpNtSetValueKey ()
from C:\windows\system32\ntdll.dll
#10 0x77572e25 in ntdll!RtlWeaklyEnumerateEntryHashTable ()
from C:\windows\system32\ntdll.dll
#11 0x00ab3a10 in ?? ()
#12 0x00000000 in ?? ()
Lisp Backtrace:
"kill-emacs" (0x88f028)
"save-buffers-kill-emacs" (0x88f318)
"save-buffers-kill-terminal" (0x88f644)
"call-interactively" (0x88f880)
"command-execute" (0x88fb7c)
Thread 1 (Thread 1360.0xe28):
#0 0x76ba8e76 in msvcrt!abort () from C:\windows\syswow64\msvcrt.dll
#1 0x6cae6f62 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
from J:\Apps\System\MinGW\bin\libgcc_s_dw2-1.dll
#2 0x00000000 in ?? ()
Lisp Backtrace:
"kill-emacs" (0x88f028)
"save-buffers-kill-emacs" (0x88f318)
"save-buffers-kill-terminal" (0x88f644)
"call-interactively" (0x88f880)
"command-execute" (0x88fb7c)
(gdb)
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-18 8:08 ` Dmitry Gutov
@ 2013-05-18 9:08 ` Eli Zaretskii
2013-05-18 13:24 ` Dmitry Gutov
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-18 9:08 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Date: Sat, 18 May 2013 12:08:58 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> > Sorry, I don't follow. Are you saying that there's still a crash
> > after applying the patch, except that you cannot get a backtrace when
> > the crash happens?
>
> Yes.
>
> > What exactly happens when you try to produce a
> > backtrace?
>
> I get the output I sent in the previous email.
So the problem is that the backtrace stops early, is that right?
Anyway, can you verify that the function unload_dlls is being called
at exit, and that it does unload libgnutls-28.dll? Setting a
breakpoint at the line that calls FreeLibrary should allow you to
display the value of loaded_from variable, which is a list showing the
library and the handle used to load it.
> > Are you sure you switch to the correct thread when asking
> > for a backtrace?
>
> Doesn't 'abort' breakpoint hit guarantee that I'm on the right thread?
No, not on Windows anyway.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-18 9:08 ` Eli Zaretskii
@ 2013-05-18 13:24 ` Dmitry Gutov
2013-05-18 14:25 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dmitry Gutov @ 2013-05-18 13:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 18.05.2013 13:08, Eli Zaretskii wrote:
>> > What exactly happens when you try to produce a
>>> backtrace?
>>
>> I get the output I sent in the previous email.
>
> So the problem is that the backtrace stops early, is that right?
I guess so.
> Anyway, can you verify that the function unload_dlls is being called
> at exit, and that it does unload libgnutls-28.dll? Setting a
> breakpoint at the line that calls FreeLibrary should allow you to
> display the value of loaded_from variable, which is a list showing the
> library and the handle used to load it.
It does, but 'abort' breakpoint hits earlier.
The sequence is, as gdb sees it, unload libpng14-14.dll, abort from
deregister_frame_info_bases, unload libpng14-14.dll again (!), then
unload libgnutls-28.dll.
(gdb) run
Starting program: c:\Users\gutov\vc\emacs-bzr\trunk\src\emacs.exe
[New Thread 3904.0xd54]
[New Thread 3904.0x4a8]
[New Thread 3904.0x568]
[New Thread 3904.0xbac]
[New Thread 3904.0xf7c]
[New Thread 3904.0xab4]
[New Thread 3904.0x624]
[New Thread 3904.0xc50]
[New Thread 3904.0x1228]
Breakpoint 4, unload_dlls () at w32.c:7473
7473 FreeLibrary (lh);
(gdb) p loaded_from
$26 = 95127070
(gdb) xcar
$27 = 0x3871131
(gdb) xstring
$28 = (struct Lisp_String *) 0x3871130 <__register_frame_info+59183408>
"libpng14-14.dll"
(gdb) bt
#0 unload_dlls () at w32.c:7473
#1 0x011ce311 in term_ntproc (ignored=0) at w32.c:7535
#2 0x010b9531 in shut_down_emacs (sig=0, stuff=54704154) at emacs.c:1940
#3 0x010b9433 in Fkill_emacs (arg=54704154) at emacs.c:1838
#4 0x0113b830 in Ffuncall (nargs=1, args=0x88f024) at eval.c:2674
#5 0x01176df0 in exec_byte_code (bytestr=19202657, vector=19202677,
maxdepth=20, args_template=54704154, nargs=0, args=0x0) at
bytecode.c:900
#6 0x0113c134 in funcall_lambda (fun=19202629, nargs=1,
arg_vector=0x342b81a <__register_frame_info+54704154>) at eval.c:2906
#7 0x0113ba57 in Ffuncall (nargs=2, args=0x88f314) at eval.c:2723
#8 0x01176df0 in exec_byte_code (bytestr=19203113, vector=19203133,
maxdepth=12, args_template=54704154, nargs=0, args=0x0) at
bytecode.c:900
#9 0x0113c134 in funcall_lambda (fun=19203085, nargs=1,
arg_vector=0x342b81a <__register_frame_info+54704154>) at eval.c:2906
#10 0x0113ba57 in Ffuncall (nargs=2, args=0x88f640) at eval.c:2723
#11 0x011375dd in Fcall_interactively (function=56693026,
record_flag=54704154, keys=54725981) at callint.c:839
#12 0x0113b87b in Ffuncall (nargs=4, args=0x88f87c) at eval.c:2681
#13 0x01176df0 in exec_byte_code (bytestr=19423041, vector=19423061,
maxdepth=52, args_template=4100, nargs=1, args=0x88fb80) at
bytecode.c:900
#14 0x0113bead in funcall_lambda (fun=19423021, nargs=1, arg_vector=0x1004)
at eval.c:2840
#15 0x0113ba57 in Ffuncall (nargs=2, args=0x88fb78) at eval.c:2723
#16 0x0113b366 in call1 (fn=54745858, arg1=56693026) at eval.c:2468
#17 0x010bb96e in command_loop_1 () at keyboard.c:1578
#18 0x01139155 in internal_condition_case (bfun=0x10bb289 <command_loop_1>,
handlers=54750330, hfun=0x10bac81 <cmd_error>) at eval.c:1193
#19 0x010bb003 in command_loop_2 (ignore=54704154) at keyboard.c:1167
#20 0x01138ccd in internal_catch (tag=54744306,
func=0x10bafdf <command_loop_2>, arg=54704154) at eval.c:964
#21 0x010bafbb in command_loop () at keyboard.c:1146
#22 0x010ba8c7 in recursive_edit_1 () at keyboard.c:779
#23 0x010baa18 in Frecursive_edit () at keyboard.c:843
#24 0x010b8df0 in main (argc=1, argv=0xbc2e30) at emacs.c:1531
Lisp Backtrace:
"kill-emacs" (0x88f028)
"save-buffers-kill-emacs" (0x88f318)
"save-buffers-kill-terminal" (0x88f644)
"call-interactively" (0x88f880)
"command-execute" (0x88fb7c)
(gdb) c
Continuing.
Breakpoint 3, 0x75e58e76 in msvcrt!abort ()
from C:\windows\syswow64\msvcrt.dll
(gdb) bt
#0 0x75e58e76 in msvcrt!abort () from C:\windows\syswow64\msvcrt.dll
#1 0x6e956f62 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
from J:\Apps\System\MinGW\bin\libgcc_s_dw2-1.dll
#2 0x00000000 in ?? ()
Lisp Backtrace:
"kill-emacs" (0x88f028)
"save-buffers-kill-emacs" (0x88f318)
"save-buffers-kill-terminal" (0x88f644)
"call-interactively" (0x88f880)
"command-execute" (0x88fb7c)
(gdb) c
Continuing.
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
Breakpoint 4, unload_dlls () at w32.c:7473
7473 FreeLibrary (lh);
(gdb) p loaded_from
$29 = 95127070
(gdb) xcar
$30 = 0x3871131
(gdb) xstring
$31 = (struct Lisp_String *) 0x3871130 <__register_frame_info+59183408>
"libpng14-14.dll"
(gdb) c
Continuing.
Breakpoint 4, unload_dlls () at w32.c:7473
7473 FreeLibrary (lh);
(gdb) p loaded_from
$32 = 99874734
(gdb) xcar
$33 = 0x3630561
(gdb) xstring
$34 = (struct Lisp_String *) 0x3630560 <__register_frame_info+56821088>
"libgnutls-28.dll"
(gdb) c
Continuing.
Warning: Lisp directory
`c:/Users/gutov/vc/emacs-bzr/trunk/../site-lisp': No such file or directory
[New Thread 3904.0x13a0]
[Inferior 1 (process 3904) exited with code 03]
(gdb)
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-18 13:24 ` Dmitry Gutov
@ 2013-05-18 14:25 ` Eli Zaretskii
2013-05-18 14:28 ` Dmitry Gutov
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-18 14:25 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Date: Sat, 18 May 2013 17:24:31 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> On 18.05.2013 13:08, Eli Zaretskii wrote:
> >> > What exactly happens when you try to produce a
> >>> backtrace?
> >>
> >> I get the output I sent in the previous email.
> >
> > So the problem is that the backtrace stops early, is that right?
>
> I guess so.
>
> > Anyway, can you verify that the function unload_dlls is being called
> > at exit, and that it does unload libgnutls-28.dll? Setting a
> > breakpoint at the line that calls FreeLibrary should allow you to
> > display the value of loaded_from variable, which is a list showing the
> > library and the handle used to load it.
>
> It does, but 'abort' breakpoint hits earlier.
>
> The sequence is, as gdb sees it, unload libpng14-14.dll, abort from
> deregister_frame_info_bases, unload libpng14-14.dll again (!), then
> unload libgnutls-28.dll.
Does libpng14-14.dll depend on libintl as well, or depend on
libgcc_s_dw2-1.dll in some other way, per chance?
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-18 14:25 ` Eli Zaretskii
@ 2013-05-18 14:28 ` Dmitry Gutov
2013-05-18 18:21 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dmitry Gutov @ 2013-05-18 14:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 18.05.2013 18:25, Eli Zaretskii wrote:
>> Date: Sat, 18 May 2013 17:24:31 +0400
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> CC: emacs-devel@gnu.org
>>
>> On 18.05.2013 13:08, Eli Zaretskii wrote:
>>>> > What exactly happens when you try to produce a
>>>>> backtrace?
>>>>
>>>> I get the output I sent in the previous email.
>>>
>>> So the problem is that the backtrace stops early, is that right?
>>
>> I guess so.
>>
>>> Anyway, can you verify that the function unload_dlls is being called
>>> at exit, and that it does unload libgnutls-28.dll? Setting a
>>> breakpoint at the line that calls FreeLibrary should allow you to
>>> display the value of loaded_from variable, which is a list showing the
>>> library and the handle used to load it.
>>
>> It does, but 'abort' breakpoint hits earlier.
>>
>> The sequence is, as gdb sees it, unload libpng14-14.dll, abort from
>> deregister_frame_info_bases, unload libpng14-14.dll again (!), then
>> unload libgnutls-28.dll.
>
> Does libpng14-14.dll depend on libintl as well, or depend on
> libgcc_s_dw2-1.dll in some other way, per chance?
Nope, its only dependencies are zlib1, kernel32 and msvcrt.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-18 14:28 ` Dmitry Gutov
@ 2013-05-18 18:21 ` Eli Zaretskii
2013-05-18 18:42 ` Dmitry Gutov
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-18 18:21 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Date: Sat, 18 May 2013 18:28:15 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> >>> Anyway, can you verify that the function unload_dlls is being called
> >>> at exit, and that it does unload libgnutls-28.dll? Setting a
> >>> breakpoint at the line that calls FreeLibrary should allow you to
> >>> display the value of loaded_from variable, which is a list showing the
> >>> library and the handle used to load it.
> >>
> >> It does, but 'abort' breakpoint hits earlier.
> >>
> >> The sequence is, as gdb sees it, unload libpng14-14.dll, abort from
> >> deregister_frame_info_bases, unload libpng14-14.dll again (!), then
> >> unload libgnutls-28.dll.
> >
> > Does libpng14-14.dll depend on libintl as well, or depend on
> > libgcc_s_dw2-1.dll in some other way, per chance?
>
> Nope, its only dependencies are zlib1, kernel32 and msvcrt.
OK. Can you try a session that only loads libgnutls, but doesn't load
image libraries? I think "emacs -nw" should achieve that, if you then
use whatever features that load GnuTLS. The question is, if libgnutls
is the only DLL loaded, does Emacs still crash at exit, with and
without my unloading patch?
Thanks.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-18 18:21 ` Eli Zaretskii
@ 2013-05-18 18:42 ` Dmitry Gutov
2013-05-18 18:53 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dmitry Gutov @ 2013-05-18 18:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 18.05.2013 22:21, Eli Zaretskii wrote:
>> Date: Sat, 18 May 2013 18:28:15 +0400
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> CC: emacs-devel@gnu.org
>>
>>>>> Anyway, can you verify that the function unload_dlls is being called
>>>>> at exit, and that it does unload libgnutls-28.dll? Setting a
>>>>> breakpoint at the line that calls FreeLibrary should allow you to
>>>>> display the value of loaded_from variable, which is a list showing the
>>>>> library and the handle used to load it.
>>>>
>>>> It does, but 'abort' breakpoint hits earlier.
>>>>
>>>> The sequence is, as gdb sees it, unload libpng14-14.dll, abort from
>>>> deregister_frame_info_bases, unload libpng14-14.dll again (!), then
>>>> unload libgnutls-28.dll.
>>>
>>> Does libpng14-14.dll depend on libintl as well, or depend on
>>> libgcc_s_dw2-1.dll in some other way, per chance?
>>
>> Nope, its only dependencies are zlib1, kernel32 and msvcrt.
>
> OK. Can you try a session that only loads libgnutls, but doesn't load
> image libraries? I think "emacs -nw" should achieve that, if you then
> use whatever features that load GnuTLS. The question is, if libgnutls
> is the only DLL loaded, does Emacs still crash at exit, with and
> without my unloading patch?
I've only tried it with your patch, for now, launching and then quitting
Gnus in console Emacs, but it still crashes.
It looks to me that libpng gets loaded by Gnus anyway, because a) the
breakpoint on w32.c:7473 still gets hit, the same amount of times, and
the car of 'loaded_from' on the first hit is still "libpng14-14.dll", b)
'M-x list-dynamic-libraries' crashes with (wrong-type-argument
characterp "J:\\Apps\\System\\MinGW\\bin\\libpng14-14.dll") after Gnus
has been launched, just like it does in graphical environment.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-18 18:42 ` Dmitry Gutov
@ 2013-05-18 18:53 ` Eli Zaretskii
2013-05-18 19:15 ` Dmitry Gutov
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-18 18:53 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Date: Sat, 18 May 2013 22:42:42 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> It looks to me that libpng gets loaded by Gnus anyway, because a) the
> breakpoint on w32.c:7473 still gets hit, the same amount of times, and
> the car of 'loaded_from' on the first hit is still "libpng14-14.dll", b)
> 'M-x list-dynamic-libraries' crashes with (wrong-type-argument
> characterp "J:\\Apps\\System\\MinGW\\bin\\libpng14-14.dll") after Gnus
> has been launched, just like it does in graphical environment.
I'd be interested to know which sequence of calls causes libpng to be
loaded by Gnus in a non-GUI session. That sounds like a bug to me.
Anyway, you should be able to work around this by renaming or moving
out of PATH the image libraries.
The goal of this exercise is to see whether the problem is in any way
related to the order of loading and unloading the DLLs. When there's
only one DLL, the order doesn't matter ;-)
Thanks.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-18 18:53 ` Eli Zaretskii
@ 2013-05-18 19:15 ` Dmitry Gutov
2013-05-18 19:24 ` Eli Zaretskii
2013-06-07 8:51 ` Eli Zaretskii
0 siblings, 2 replies; 116+ messages in thread
From: Dmitry Gutov @ 2013-05-18 19:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 18.05.2013 22:53, Eli Zaretskii wrote:
>> Date: Sat, 18 May 2013 22:42:42 +0400
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> CC: emacs-devel@gnu.org
>>
>> It looks to me that libpng gets loaded by Gnus anyway, because a) the
>> breakpoint on w32.c:7473 still gets hit, the same amount of times, and
>> the car of 'loaded_from' on the first hit is still "libpng14-14.dll", b)
>> 'M-x list-dynamic-libraries' crashes with (wrong-type-argument
>> characterp "J:\\Apps\\System\\MinGW\\bin\\libpng14-14.dll") after Gnus
>> has been launched, just like it does in graphical environment.
>
> I'd be interested to know which sequence of calls causes libpng to be
> loaded by Gnus in a non-GUI session. That sounds like a bug to me.
I don't mind participating in the troubleshooting, but can't you
reproduce this on your end? I mean both libpng loading in the terminal,
and crash when using libgcc-dw2-dependent libintl. It would be quicker.
> Anyway, you should be able to work around this by renaming or moving
> out of PATH the image libraries.
>
> The goal of this exercise is to see whether the problem is in any way
> related to the order of loading and unloading the DLLs. When there's
> only one DLL, the order doesn't matter ;-)
Looks like it is. I renamed libpng, so it doesn't get loaded. Without
your patch, it still crashes, but with the patch applied, the crash is
gone. I only see this message in the console:
warning: Temporarily disabling breakpoints for unloaded shared library
"J:\Apps\System\MinGW\bin\libiconv-2.dll"
libiconv-2.dll is a dependency of libintl-8.dll.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-18 19:15 ` Dmitry Gutov
@ 2013-05-18 19:24 ` Eli Zaretskii
2013-06-07 8:51 ` Eli Zaretskii
1 sibling, 0 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-18 19:24 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Date: Sat, 18 May 2013 23:15:29 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> > Anyway, you should be able to work around this by renaming or moving
> > out of PATH the image libraries.
> >
> > The goal of this exercise is to see whether the problem is in any way
> > related to the order of loading and unloading the DLLs. When there's
> > only one DLL, the order doesn't matter ;-)
>
> Looks like it is. I renamed libpng, so it doesn't get loaded. Without
> your patch, it still crashes, but with the patch applied, the crash is
> gone. I only see this message in the console:
>
> warning: Temporarily disabling breakpoints for unloaded shared library
> "J:\Apps\System\MinGW\bin\libiconv-2.dll"
Thanks.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-16 14:43 ` Dmitry Gutov
2013-05-16 15:41 ` Eli Zaretskii
@ 2013-05-19 6:48 ` Stephen Leake
2013-05-19 14:51 ` Eli Zaretskii
1 sibling, 1 reply; 116+ messages in thread
From: Stephen Leake @ 2013-05-19 6:48 UTC (permalink / raw)
To: emacs-devel
Dmitry Gutov <dgutov@yandex.ru> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>> I'd like to encourage everyone who builds native Windows port of Emacs
>> to please switch to this method; the old nt/configure.bat and
>> Windows-specific makefile.w32-in files are from now on deprecated.
>> Start by reading nt/INSTALL.MSYS.
>
> Thank you for you work. A few comments on the documentation:
>
>> It is always preferable to use --prefix to configure Emacs for
>> some specific location of its installed tree; the default
>> /usr/local is not suitable for Windows.
It would be best to say _why_ you think "/usr/local is not suitable for
Windows". Certainly Microsoft doesn't care about "/usr/local". Neither
does MSYS or MinGW (if installed in the default places).
Cygwin might, if installed at c:/ (as I do). In that case, it would
appear your MSYS/MinGW Emacs build is a Cygwin build, which would be
confusing.
--
-- Stephe
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-19 6:48 ` Stephen Leake
@ 2013-05-19 14:51 ` Eli Zaretskii
2013-05-21 8:31 ` Stephen Leake
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-19 14:51 UTC (permalink / raw)
To: Stephen Leake; +Cc: emacs-devel
> From: Stephen Leake <stephen_leake@member.fsf.org>
> Date: Sun, 19 May 2013 01:48:49 -0500
>
> >> It is always preferable to use --prefix to configure Emacs for
> >> some specific location of its installed tree; the default
> >> /usr/local is not suitable for Windows.
>
> It would be best to say _why_ you think "/usr/local is not suitable for
> Windows". Certainly Microsoft doesn't care about "/usr/local".
It's funny how the most obvious things draw most of the questions.
Here are 2 obvious reasons which I had in mind when I wrote that:
. /usr/local does not specify a drive letter, so its location is
ambiguous, as it depends on the current drive
. Windows systems don't usually have /usr/local on _any_ drive, even
if they have many MinGW packages installed, while one of the main
goals of this build was to allow installing Emacs as part of a
larger tree of ported software, not as a stand-alone package
There's also a subtler problem, already mentioned in this thread,
which might be known to fewer people:
> Neither does MSYS or MinGW (if installed in the default places).
You are wrong here: MSYS does care. It maps /usr/local to a
subdirectory of its installation root. So if MSYS was installed in
C:\MSYS, /usr/local will be actually C:\MSYS\local (note that the
'usr' part disappeared, because MSYS maps both / and /usr to the same
place). Imagine the surprise of a newbie who says "make install" and
then looks in vain for any "usr/local" directory anywhere, and doesn't
find it!
Since INSTALL.MSYS cannot be a treatise on MSYS or anything near it, I
thought that it will be sufficient to say "not recommended", and rely
on people to know about the 2 obvious reasons above, and just go with
the recommendation. How naive of me...
Also:
> Cygwin might, if installed at c:/ (as I do). In that case, it would
> appear your MSYS/MinGW Emacs build is a Cygwin build, which would be
> confusing.
Here, you actually answered your own question: there are Emacs users
on Windows who do actually have Cygwin installed.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-19 14:51 ` Eli Zaretskii
@ 2013-05-21 8:31 ` Stephen Leake
2013-05-21 17:07 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Stephen Leake @ 2013-05-21 8:31 UTC (permalink / raw)
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Stephen Leake <stephen_leake@member.fsf.org>
>> Date: Sun, 19 May 2013 01:48:49 -0500
>>
>> >> It is always preferable to use --prefix to configure Emacs for
>> >> some specific location of its installed tree; the default
>> >> /usr/local is not suitable for Windows.
>>
>> It would be best to say _why_ you think "/usr/local is not suitable for
>> Windows". Certainly Microsoft doesn't care about "/usr/local".
>
> It's funny how the most obvious things draw most of the questions.
> Here are 2 obvious reasons which I had in mind when I wrote that:
>
> . /usr/local does not specify a drive letter, so its location is
> ambiguous, as it depends on the current drive
That's a good point.
> . Windows systems don't usually have /usr/local on _any_ drive, even
> if they have many MinGW packages installed, while one of the main
> goals of this build was to allow installing Emacs as part of a
> larger tree of ported software, not as a stand-alone package
I assume 'make install' will create the directory, so that's not a
problem.
> There's also a subtler problem, already mentioned in this thread,
> which might be known to fewer people:
>
>> Neither does MSYS or MinGW (if installed in the default places).
>
> You are wrong here: MSYS does care. It maps /usr/local to a
> subdirectory of its installation root. So if MSYS was installed in
> C:\MSYS, /usr/local will be actually C:\MSYS\local (note that the
> 'usr' part disappeared, because MSYS maps both / and /usr to the same
> place). Imagine the surprise of a newbie who says "make install" and
> then looks in vain for any "usr/local" directory anywhere, and doesn't
> find it!
Right. I forgot that 'make install' is run from an MSYS shell, not a DOS
or Cygwin bash shell.
> Since INSTALL.MSYS cannot be a treatise on MSYS or anything near it, I
> thought that it will be sufficient to say "not recommended", and rely
> on people to know about the 2 obvious reasons above, and just go with
> the recommendation. How naive of me...
That would be true for naive users.
For Emacs users used to customizing things on Linux, the additional
information is helpful. A pointer to a thorough discussion of MSYS
issues would be very nice, but I don't think such a thing exists :(.
A pointer to an Emacs W32 FAQ would be another choice.
> Also:
>
>> Cygwin might, if installed at c:/ (as I do). In that case, it would
>> appear your MSYS/MinGW Emacs build is a Cygwin build, which would be
>> confusing.
>
> Here, you actually answered your own question: there are Emacs users
> on Windows who do actually have Cygwin installed.
Actually not, since MSYS treats "/usr/local" as Cygwin
"/cygdrive/c/MSYS/local".
--
-- Stephe
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-21 8:31 ` Stephen Leake
@ 2013-05-21 17:07 ` Eli Zaretskii
2013-05-21 19:36 ` Stephen Leake
0 siblings, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-21 17:07 UTC (permalink / raw)
To: Stephen Leake; +Cc: emacs-devel
> From: Stephen Leake <stephen_leake@member.fsf.org>
> Date: Tue, 21 May 2013 03:31:16 -0500
>
> > . Windows systems don't usually have /usr/local on _any_ drive, even
> > if they have many MinGW packages installed, while one of the main
> > goals of this build was to allow installing Emacs as part of a
> > larger tree of ported software, not as a stand-alone package
>
> I assume 'make install' will create the directory, so that's not a
> problem.
Yes, "make install" will create it, but that's not the point. See the
second part of the sentence I wrote and you quoted above. The point
is that I want to encourage people to install ports of GNU and Unix
software in a single tree, so that they all play together well without
a lot of tinkering with environment variables. And _since_ there
usually is not /usr/local on Windows systems, I doubt that /usr/local
will be a good guess of where people might put such a tree. So I
_want_ them to think about the root of that tree, and I want them to
use that in the --prefix option.
> For Emacs users used to customizing things on Linux, the additional
> information is helpful.
Are there such users who don't prefer Cygwin instead?
> > Also:
> >
> >> Cygwin might, if installed at c:/ (as I do). In that case, it would
> >> appear your MSYS/MinGW Emacs build is a Cygwin build, which would be
> >> confusing.
> >
> > Here, you actually answered your own question: there are Emacs users
> > on Windows who do actually have Cygwin installed.
>
> Actually not, since MSYS treats "/usr/local" as Cygwin
> "/cygdrive/c/MSYS/local".
Actually, still yes, although for a slightly different reason ;-)
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-21 17:07 ` Eli Zaretskii
@ 2013-05-21 19:36 ` Stephen Leake
2013-05-25 7:29 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Stephen Leake @ 2013-05-21 19:36 UTC (permalink / raw)
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> Yes, "make install" will create it, but that's not the point. See the
> second part of the sentence I wrote and you quoted above. The point
> is that I want to encourage people to install ports of GNU and Unix
> software in a single tree, so that they all play together well without
> a lot of tinkering with environment variables. And _since_ there
> usually is not /usr/local on Windows systems, I doubt that /usr/local
> will be a good guess of where people might put such a tree. So I
> _want_ them to think about the root of that tree, and I want them to
> use that in the --prefix option.
Ok; INSTALL should say that. The point is to make clear what your
reasons are, so if I decide to ignore your advice, I know what the
issues are.
I had the same complaint about the Cygwin installer; it used to complain
if I installed to c:/ (requiring an extra confirming click), without
saying anything about why that might matter, leaving me to wonder if
Cygwin would break in some way. In that case, there was a rationale
posted online, which boiled down to "users might have other stuff
installed at c:/".
>> For Emacs users used to customizing things on Linux, the additional
>> information is helpful.
>
> Are there such users who don't prefer Cygwin instead?
I'm one :). I don't use Cygwin Emacs, because it doesn't work well
with the MinGW and native Windows tools I use. Although that may have
improved since I first played with this, back in Emacs 21 days. I do use
Cygwin bash and make, under native Emacs; that works well.
--
-- Stephe
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-21 19:36 ` Stephen Leake
@ 2013-05-25 7:29 ` Eli Zaretskii
0 siblings, 0 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-05-25 7:29 UTC (permalink / raw)
To: Stephen Leake; +Cc: emacs-devel
> From: Stephen Leake <stephen_leake@member.fsf.org>
> Date: Tue, 21 May 2013 14:36:36 -0500
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Yes, "make install" will create it, but that's not the point. See the
> > second part of the sentence I wrote and you quoted above. The point
> > is that I want to encourage people to install ports of GNU and Unix
> > software in a single tree, so that they all play together well without
> > a lot of tinkering with environment variables. And _since_ there
> > usually is not /usr/local on Windows systems, I doubt that /usr/local
> > will be a good guess of where people might put such a tree. So I
> > _want_ them to think about the root of that tree, and I want them to
> > use that in the --prefix option.
>
> Ok; INSTALL should say that.
Done. Thanks for the suggestion.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-05-18 19:15 ` Dmitry Gutov
2013-05-18 19:24 ` Eli Zaretskii
@ 2013-06-07 8:51 ` Eli Zaretskii
2013-06-07 9:36 ` Dmitry Gutov
1 sibling, 1 reply; 116+ messages in thread
From: Eli Zaretskii @ 2013-06-07 8:51 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Date: Sat, 18 May 2013 23:15:29 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> On 18.05.2013 22:53, Eli Zaretskii wrote:
> >> Date: Sat, 18 May 2013 22:42:42 +0400
> >> From: Dmitry Gutov <dgutov@yandex.ru>
> >> CC: emacs-devel@gnu.org
> >>
> >> It looks to me that libpng gets loaded by Gnus anyway, because a) the
> >> breakpoint on w32.c:7473 still gets hit, the same amount of times, and
> >> the car of 'loaded_from' on the first hit is still "libpng14-14.dll", b)
> >> 'M-x list-dynamic-libraries' crashes with (wrong-type-argument
> >> characterp "J:\\Apps\\System\\MinGW\\bin\\libpng14-14.dll") after Gnus
> >> has been launched, just like it does in graphical environment.
> >
> > I'd be interested to know which sequence of calls causes libpng to be
> > loaded by Gnus in a non-GUI session. That sounds like a bug to me.
>
> I don't mind participating in the troubleshooting, but can't you
> reproduce this on your end? I mean both libpng loading in the terminal,
> and crash when using libgcc-dw2-dependent libintl. It would be quicker.
Just for the record, see this thread on the GCC list:
http://gcc.gnu.org/ml/gcc/2013-05/msg00180.html
Unfortunately, none of the GCC maintainers said anything interesting
in that thread, nor suggested to fix this. However, I think I have a
pretty good understanding of what happens here, as I described here:
http://gcc.gnu.org/ml/gcc/2013-05/msg00214.html
To summarize:
. This happens due to a bug in the GCC startup and termination code,
which check independently for whether libgcc was loaded as a
shared library. When libgcc is not loaded at startup, but is
found to be loaded on ext, that code hits an assertion and aborts.
. The only way around this, besides not using DLLs that depend on
shared libgcc, is to link the program with the -shared-libgcc
compiler option.
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-06-07 8:51 ` Eli Zaretskii
@ 2013-06-07 9:36 ` Dmitry Gutov
2013-06-07 9:56 ` Eli Zaretskii
0 siblings, 1 reply; 116+ messages in thread
From: Dmitry Gutov @ 2013-06-07 9:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 07.06.2013 12:51, Eli Zaretskii wrote:
> To summarize:
>
> . This happens due to a bug in the GCC startup and termination code,
> which check independently for whether libgcc was loaded as a
> shared library. When libgcc is not loaded at startup, but is
> found to be loaded on ext, that code hits an assertion and aborts.
>
> . The only way around this, besides not using DLLs that depend on
> shared libgcc, is to link the program with the -shared-libgcc
> compiler option.
>
Thanks for the follow-up.
As a practical solution, are there downsides to building Emacs with
-shared-libgcc option?
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: MS-Windows build using Posix configury
2013-06-07 9:36 ` Dmitry Gutov
@ 2013-06-07 9:56 ` Eli Zaretskii
0 siblings, 0 replies; 116+ messages in thread
From: Eli Zaretskii @ 2013-06-07 9:56 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Date: Fri, 07 Jun 2013 13:36:02 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> As a practical solution, are there downsides to building Emacs with
> -shared-libgcc option?
Just that (AFAIR) the resulting binary will depend on the shared
libgcc DLL, even if you never use gnutls. But if you are building for
your own usage on your machine, that's not a downside. If you copy
the binary to another machine, you will needto copy the libgcc DLL as
well.
For someone who wants to distribute the resulting binary, it's a
hassle, because the GPL requires that the entire 80-MB source tarball
of GCC be available from the same site. (For some reason that is
above my pay grade, statically linked libgcc doesn't require sources,
while dynamically linked one does.)
^ permalink raw reply [flat|nested] 116+ messages in thread
end of thread, other threads:[~2013-06-07 9:56 UTC | newest]
Thread overview: 116+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-16 18:24 MS-Windows build using Posix configury Eli Zaretskii
2013-04-16 18:40 ` Eli Zaretskii
2013-04-16 20:13 ` Stefan Monnier
2013-04-17 2:53 ` Eli Zaretskii
2013-04-16 21:17 ` Glenn Morris
2013-04-17 2:56 ` Eli Zaretskii
2013-04-17 6:25 ` Glenn Morris
2013-04-17 16:48 ` Eli Zaretskii
2013-04-17 17:11 ` Glenn Morris
2013-04-17 17:34 ` Eli Zaretskii
2013-04-17 17:53 ` Glenn Morris
2013-04-17 18:15 ` Glenn Morris
2013-04-17 18:44 ` Eli Zaretskii
2013-04-17 0:42 ` Glenn Morris
2013-04-17 2:57 ` Eli Zaretskii
2013-04-17 6:24 ` Glenn Morris
2013-04-17 3:33 ` Paul Eggert
2013-04-17 17:00 ` Eli Zaretskii
2013-04-17 18:48 ` Paul Eggert
2013-04-17 19:15 ` Glenn Morris
2013-04-17 19:45 ` Eli Zaretskii
2013-04-17 20:43 ` Glenn Morris
2013-04-17 21:19 ` Paul Eggert
2013-04-17 22:38 ` Glenn Morris
2013-04-18 0:52 ` Paul Eggert
2013-04-18 5:29 ` Glenn Morris
2013-04-18 16:11 ` Eli Zaretskii
2013-04-17 6:27 ` Glenn Morris
2013-04-17 6:31 ` Glenn Morris
2013-04-18 19:32 ` Dani Moncayo
2013-04-18 20:27 ` Dani Moncayo
2013-04-18 21:20 ` Eli Zaretskii
2013-04-18 22:03 ` Dani Moncayo
2013-04-19 6:34 ` Eli Zaretskii
2013-04-19 20:17 ` Dani Moncayo
2013-04-20 6:34 ` Eli Zaretskii
2013-04-20 7:35 ` Dani Moncayo
2013-04-20 7:56 ` Eli Zaretskii
2013-04-20 17:18 ` Dani Moncayo
2013-04-20 18:30 ` Eli Zaretskii
2013-04-20 20:21 ` Dani Moncayo
2013-04-21 15:12 ` Eli Zaretskii
2013-04-21 19:53 ` Dani Moncayo
2013-05-01 15:30 ` Dani Moncayo
2013-05-01 16:30 ` Eli Zaretskii
2013-05-01 19:30 ` Dani Moncayo
2013-05-01 19:40 ` Eli Zaretskii
2013-05-02 6:43 ` Dani Moncayo
2013-05-02 16:19 ` Eli Zaretskii
2013-05-02 18:40 ` Dani Moncayo
2013-05-02 19:49 ` Eli Zaretskii
2013-05-02 21:42 ` Dani Moncayo
2013-05-02 21:43 ` Dani Moncayo
2013-05-03 8:50 ` Eli Zaretskii
2013-05-04 10:59 ` Dani Moncayo
2013-05-04 11:04 ` Dani Moncayo
2013-05-04 11:27 ` Eli Zaretskii
2013-05-04 12:00 ` Dani Moncayo
2013-05-04 12:30 ` Eli Zaretskii
2013-05-07 19:36 ` Dani Moncayo
2013-05-07 21:13 ` Eli Zaretskii
2013-05-07 22:04 ` Dani Moncayo
2013-05-08 17:09 ` Eli Zaretskii
2013-05-08 17:32 ` Dani Moncayo
2013-05-13 12:23 ` Andy Moreton
2013-05-13 16:23 ` Eli Zaretskii
2013-05-16 6:00 ` Eli Zaretskii
2013-05-16 6:31 ` Paul Eggert
2013-05-16 6:56 ` Eli Zaretskii
2013-05-16 7:16 ` Paul Eggert
2013-05-16 7:30 ` Eli Zaretskii
2013-05-16 13:19 ` Eli Zaretskii
2013-05-16 14:43 ` Dmitry Gutov
2013-05-16 15:41 ` Eli Zaretskii
2013-05-16 16:10 ` Dmitry Gutov
2013-05-16 17:17 ` Dani Moncayo
2013-05-16 17:54 ` Eli Zaretskii
2013-05-16 18:01 ` Dani Moncayo
2013-05-16 18:36 ` Eli Zaretskii
2013-05-16 21:02 ` Dmitry Gutov
2013-05-17 6:02 ` Eli Zaretskii
2013-05-16 17:18 ` Eli Zaretskii
2013-05-16 21:19 ` Dmitry Gutov
2013-05-17 9:39 ` Eli Zaretskii
2013-05-17 12:05 ` Dmitry Gutov
2013-05-17 13:13 ` Eli Zaretskii
2013-05-17 14:03 ` Dmitry Gutov
2013-05-17 14:26 ` Eli Zaretskii
2013-05-17 15:29 ` Dmitry Gutov
2013-05-17 16:05 ` Eli Zaretskii
2013-05-17 16:30 ` Dmitry Gutov
2013-05-17 17:40 ` Eli Zaretskii
2013-05-17 18:43 ` Eli Zaretskii
2013-05-17 20:47 ` Dmitry Gutov
2013-05-18 7:18 ` Eli Zaretskii
2013-05-18 8:08 ` Dmitry Gutov
2013-05-18 9:08 ` Eli Zaretskii
2013-05-18 13:24 ` Dmitry Gutov
2013-05-18 14:25 ` Eli Zaretskii
2013-05-18 14:28 ` Dmitry Gutov
2013-05-18 18:21 ` Eli Zaretskii
2013-05-18 18:42 ` Dmitry Gutov
2013-05-18 18:53 ` Eli Zaretskii
2013-05-18 19:15 ` Dmitry Gutov
2013-05-18 19:24 ` Eli Zaretskii
2013-06-07 8:51 ` Eli Zaretskii
2013-06-07 9:36 ` Dmitry Gutov
2013-06-07 9:56 ` Eli Zaretskii
2013-05-19 6:48 ` Stephen Leake
2013-05-19 14:51 ` Eli Zaretskii
2013-05-21 8:31 ` Stephen Leake
2013-05-21 17:07 ` Eli Zaretskii
2013-05-21 19:36 ` Stephen Leake
2013-05-25 7:29 ` Eli Zaretskii
2013-04-19 3:05 ` Ken Brown
2013-04-19 6:35 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).