Fixed the LN_S and LN_EMACS issue.

Makefile.in

@@ -257,8 +257,6 @@ 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@
@@ -473,7 +471,7 @@ install-arch-dep: src install-arch-indep install-doc
 	  chmod 1755 $(DESTDIR)${bindir}/$(EMACSFULL) || true; \
 	  if test "x${NO_BIN_LINK}" = x; then \
 	    rm -f $(DESTDIR)${bindir}/$(EMACS) ; \
-	    cd $(DESTDIR)${bindir} && $(LN_EMACS) $(EMACSFULL) $(EMACS); \
+	    cd $(DESTDIR)${bindir} && $(LN_S) $(EMACSFULL) $(EMACS); \
 	  fi; \
 	else \
 	  subdir=${ns_appresdir}/site-lisp; \

configure.ac

@@ -814,11 +814,15 @@ dnl   AC_PROG_RANLIB
 dnl fi
 AC_PROG_LN_S
 
-LN_EMACS="\$(LN_S)"
+dnl AC_PROG_LN_S sets LN_S to 'cp -pR' for MinGW, on the premise that 'ln'
+dnl doesn't support links to directories, as in "ln file dir".  But that
+dnl use is non-portable, and OTOH MinGW wants to use hard links for Emacs
+dnl executables at "make install" time.
+dnl See http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00475.html
+dnl for more details.
 if test "$opsys" = "mingw32"; then
-  LN_EMACS="ln"
+  LN_S="ln"
 fi
-AC_SUBST(LN_EMACS)
 
 AC_PATH_PROG(INSTALL_INFO, install-info, :,
   $PATH$PATH_SEPARATOR/usr/sbin$PATH_SEPARATOR/sbin)