Building Emacs fails on Cygwin

Building Emacs fails on Cygwin

[Paul Michael Reilly]

I just started a new gig where I must use Windows temporarily.  Even 
temporary, I found being without the latest Emacs is untenable.  So I 
just installed Cygwin, downloaded the current Emacs source and proceeded 
to do a build.  The bootstrap failed as shown below.  It was not clear 
to me where in the build 'emacs.exe' is supposed to be created.

fwiw, the build system is Windows 2003 system fully updated.

Any insight will be much appreciated,

-pmr

...
$ make
boot=bootstrap-emacs.exe;                         \
	if [ -x "src/$boot" ]; then boot=""; fi;                   \
	cd lib-src; make all                            \
	  CC='gcc' CFLAGS='-g -O2 ' CPPFLAGS='' \
	  LDFLAGS='-L/usr/X11R6/lib' MAKE='make' BOOTSTRAPEMACS="$boot"
make[1]: Entering directory `/usr/local/src/emacs/lib-src'
gcc -DHAVE_CONFIG_H -I. -I../src -I/usr/local/src/emacs/lib-src 
-I/usr/local/src/emacs/lib-src/../src -L/usr/X11R6/lib  -g -O2  -o 
test-distrib /usr/local/src/emacs/lib-src/test-distrib.c
./test-distrib /usr/local/src/emacs/lib-src/testfile
...
gcc -Demacs -DHAVE_CONFIG_H  -I. -I/usr/local/src/emacs/src 
-I/usr/X11R6/include -DXTHREADS -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0 
-I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 
-I/usr/include/pango-1.0 -I/usr/include/freetype2 
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/X11R6/include 
-I/usr/include/freetype2    -g -O2  -L/usr/X11R6/lib 
/usr/local/src/emacs/src/prefix-args.c -o prefix-args
echo "dispnew.o frame.o scroll.o xdisp.o menu.o xmenu.o window.o 
charset.o coding.o category.o ccl.o character.o chartab.o cm.o term.o 
terminal.o xfaces.o xterm.o xfns.o xselect.o xrdb.o fontset.o xsmfns.o 
fringe.o image.o gtkutil.o  emacs.o keyboard.o macros.o keymap.o 
sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o 
dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o 
regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o 
floatfns.o fns.o font.o print.o lread.o syntax.o unexcw.o bytecode.o 
process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o 
intervals.o textprop.o composite.o md5.o   sheap.o xfont.o ftfont.o 
xftfont.o ftxfont.o terminfo.o gmalloc.o ralloc.o lastfile.o vm-limit.o 
  mktime.o getloadavg.o " > buildobj.lst
gcc -Wl,--image-base,0x20000000   -L/usr/X11R6/lib -o temacs ecrt0.o 
dispnew.o frame.o scroll.o xdisp.o menu.o xmenu.o window.o charset.o 
coding.o category.o ccl.o character.o chartab.o cm.o term.o terminal.o 
xfaces.o xterm.o xfns.o xselect.o xrdb.o fontset.o xsmfns.o fringe.o 
image.o gtkutil.o  emacs.o keyboard.o macros.o keymap.o sysdep.o 
buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o 
filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o 
undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o 
font.o print.o lread.o syntax.o unexcw.o bytecode.o process.o callproc.o 
region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o 
textprop.o composite.o md5.o   sheap.o xfont.o ftfont.o xftfont.o 
ftxfont.o terminfo.o gmalloc.o ralloc.o lastfile.o vm-limit.o  mktime.o 
getloadavg.o    -L/usr/X11R6/lib -L/usr/X11R6/lib -lgtk-x11-2.0 
-lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lXft -lfreetype 
-lz -lXrender -lXext -lfontconfig -lpangox-1.0 -lX11 -lpango-1.0 -lm 
-lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv -lpthread -lSM 
-lICE -ltiff -ljpeg -lpng -lz -lm -lungif -lXpm -lX11 -L/usr/X11R6/lib 
-lXft -lfreetype -lz -lXrender -lX11 -lXext -lfontconfig -lexpat 
-lresolv -lcurses -lg  `gcc -print-libgcc-file-name` -lm -lc `gcc 
-print-libgcc-file-name`
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: 
warning: auto-importing has been activated without --enable-auto-import 
specified on the command line.
This should work unless it involves constant data structures referencing 
symbols from auto-imported DLLs.Info: resolving _gdk_display by linking 
to __imp__gdk_display (auto-import)
Info: resolving __tzname by linking to __imp___tzname (auto-import)
cd ../lisp; make -w update-subdirs
make[2]: Entering directory `/usr/local/src/emacs/lisp'
wd=/usr/local/src/emacs/lisp; subdirs=`(cd $wd; find . -type d -print)`; 
for file in $subdirs; do case $file in */Old | */RCS | */CVS | */CVS/* | 
*/.* | */.*/* | */=* ) ;; *) wins="$wins $wd/$file" ;; esac; done; \
	for file in $wins; do \
	   /usr/local/src/emacs/lisp/../update-subdirs $file; \
	done;
make[2]: Leaving directory `/usr/local/src/emacs/lisp'
`/bin/pwd`/temacs --batch --load loadup bootstrap
Loading loadup.el (source)...
Using load-path (/usr/local/src/emacs/lisp 
/usr/local/src/emacs/lisp/emacs-lisp /usr/local/src/emacs/lisp/language 
/usr/local/src/emacs/lisp/international /usr/local/src/emacs/lisp/textmodes)
Loading emacs-lisp/byte-run (source)...
Loading emacs-lisp/backquote (source)...
Loading subr (source)...
Loading version.el (source)...
Loading widget (source)...
Loading custom (source)...
Loading emacs-lisp/map-ynp (source)...
Loading cus-start (source)...
Loading international/mule (source)...
Loading international/mule-conf.el (source)...
Loading env (source)...
Loading format (source)...
Loading bindings (source)...
Loading /usr/local/src/emacs/lisp/files.el (source)...
Loading /usr/local/src/emacs/lisp/cus-face.el (source)...
Loading /usr/local/src/emacs/lisp/faces.el (source)...
mv -f emacs.exe bootstrap-emacs.exe
mv: cannot stat `emacs.exe': No such file or directory
make[1]: *** [bootstrap-emacs.exe] Error 1
make[1]: Leaving directory `/usr/local/src/emacs/src'
make: *** [src] Error 2
^[]0;/usr/local/src/emacs\a
^[[32mreipa09@reipa09gx620 ^[[33m/usr/local/src/emacs^[[0m

Re: Building Emacs fails on Cygwin

[Angelo Graziosi]

Paul Michael Reilly wrote:

> The bootstrap failed as shown below

This has been discussed longly [1]. I think this is also related to
recent discussion titled

    "size of emacs executable after unicode merge".

The solution is the patch below. Pre-built binaries here [2].


===============================
--- sheap.c.orig        2008-05-14 14:56:07.000000000 +0200
+++ sheap.c     2008-06-28 18:21:30.984375000 +0200
@@ -24,7 +24,7 @@

  #include <unistd.h>

-#define STATIC_HEAP_SIZE       (12 * 1024 * 1024)
+#define STATIC_HEAP_SIZE       (25 * 1024 * 1024)

  int debug_sheap = 0;

@@ -40,9 +40,7 @@
    if (!bss_sbrk_ptr)
      {
        bss_sbrk_ptr = bss_sbrk_buffer;
-#ifdef CYGWIN
        sbrk (BLOCKSIZE);                /* force space for fork to work */
-#endif
      }

    if (!(int) request_size)
===============================


Cheers,
    Angelo.

---
[1] http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg00052.html
[2] http://www.webalice.it/angelo.graziosi/cygwin/emacs/Emacs.html

Facesti come quei che va di notte,
che porta il lume dietro e se' non giova,
ma dopo se' fa le persone dotte.

                   DANTE, Purgatorio, xxii 67-69

Re: Building Emacs fails on Cygwin

[Paul Reilly]

Angelo Graziosi wrote:
> Paul Michael Reilly wrote:
> 
>> The bootstrap failed as shown below
> 
> This has been discussed longly [1]. I think this is also related to
> recent discussion titled
> 
>    "size of emacs executable after unicode merge".
> 
> The solution is the patch below. Pre-built binaries here [2].
> 
> 
> ===============================
> --- sheap.c.orig        2008-05-14 14:56:07.000000000 +0200
> +++ sheap.c     2008-06-28 18:21:30.984375000 +0200
> @@ -24,7 +24,7 @@
> 
>  #include <unistd.h>
> 
> -#define STATIC_HEAP_SIZE       (12 * 1024 * 1024)
> +#define STATIC_HEAP_SIZE       (25 * 1024 * 1024)

Seems to me that this is merely a short term fix until the next time 
Emacs needs more heap.  Is it impossible/impractical to find a mechanism 
to determine how big this requirement should be at build time so the 
problem can be solved forever?  I'll plead guilty right up front to not 
having a clue on what the optimal long term answer might be.

And thanks for your help.  Much appreciated.

-pmr

Re: Building Emacs fails on Cygwin

[Stephen J. Turnbull]

Paul Reilly writes:

 > Seems to me that this is merely a short term fix until the next time 
 > Emacs needs more heap.  Is it impossible/impractical to find a mechanism 
 > to determine how big this requirement should be at build time so the 
 > problem can be solved forever?

It's not impossible because XEmacs and SXEmacs do it.  I don't know
the code though so that's as far as I can help.