-\input texinfo @c -*-texinfo-*-
-@setfilename README-W32.info
-@settitle LilyPond on W32
-
-
-@node Top, , , (dir)
-
-@chapter LilyPond on W32
-
-FIXME: remove yodl refs.
-
-[FIXME: THIS DOCUMENTED IS OUTDATED]
-
-No, there's no reason to be concered, Lily should work in
-Windows-NT(/95/98?) too. The setup may not be easy or smooth. This
-document will help you getting started.
-
-
-@section DISCLAIMER
-
-If you have the Cygnus gnu-windows32 port of the GNU utils, LilyPond
-will work in Windows-NT (/95/98?).
-
-We still recommend you use Unix. In particular, use GNU/Linux: We've
-been there, and we've seen it happen several times. It is @strong{much}
-easier and quicker to install RedHat Linux and LilyPond than to
-obtain, compile and install all the necessary tools to compile and run
-LilyPond on Windows.
-
-``Ok, thanks for the suggestions. I can't run Linux or I don't want
-to run Unix. What can I expect?''
-
-@itemize @bullet
-@item LilyPond development is moving quite fast, and all developers use Unix.
- Newly added features may require some attention to get them to work.
-@item LilyPond depends on a number of other packages that usually are
- available on Unix boxes, but are not installed by default on Windows.
-@end itemize
-
-
-LilyPond will now install/extract in a unix-like tree:
-@example
-
- usr/[local/]bin/
- usr/[local/]share/lilypond/*
-
-@end example
-
-etc.
-
-Lily runs in a the unix-like Cygnus gnu-windows environment;
-hopefully Cygnus will adopt the @file{/usr/[local/]} tree too.
-
-@*
-If you really don't want usr/ in your root directory, but rather scatter
-your programs and packages all over your harddisk, do something like:
-@example
-
- md lilypond
- cd lilypond
- unzip ../lilypond-0.1.77.exe.zip
-
-@end example
-
-and add @file{lilypond/usr/bin} to your @file{PATH} and
-@file{lilypond/usr/share/lilypond} to your @file{LILYINCLUDE}.
-
-
-If you've received a binary release of LilyPond (@file{.exe.zip}),
-you may skip the following sections.
-
-
-It can be done! Occasionally, the Cygnus b19.1 cross compiler and
-utilities under GNU/Linux are used to make the binary @file{.exe.zip}
-releases (some makefile hacking was needed to build this stuff). Jeffrey
-Reed tries to keep-up with LilyPond development, and is doing quite
-well. His latest release is available on
-@uref{http://home.austin.rr.com/jbr/jeff/lilypond/}.
-
-
-I have heard of such tools that think they're probably much smarter than the
-packager and thus decide for themselves that they don't need to unpack certain
-files (e.g., empty directories such as bin/out).
-
-To unpack the lilypond sources, you should do something like: @example
-
- tar zxf releases/lilypond-x.y.z.tar.gz
-
-@end example
-
-
-If you're familiar with the GNU/Cygnus development package, you may skip
-this.
-
-Don't forget to set
-@example
-
- /start/settings/control-panel/system/environment/system-variables:
- GCC_EXEC_PREFIX=/Cygnus/b19/H-i386-cygwin32/lib/gcc-lib/
- MAKE_MODE=UNIX
-
-@end example
-
-You want to run bash, while building Lily:
-@example
-
- c:\bash
- bash-2.01$
-
-@end example
-
-The install instructions mention something like:
-@example
-
- configure
- make
- make install
-
-@end example
-
-Now for a small UNIX lesson: The current working directory (cwd) is
-by default not in your PATH, like it is under DOS (for security reasons).
-Check this by looking at the output of:
-@example
-
- echo $PATH
-
-@end example
-
-The cwd looks like @code{'::'} or @code{':.'}. If it's not there, you may
-add the cwd to your path:
-@example
-
- PATH=$PATH:.
-
-@end example
-
-or you must use './' when issuing a command in th cwd, try:
-@example
-
- ./configure
- make
-
-@end example
-
-My point of reference comes from 15 odd years working with a variety
-of @code{UNIX} platforms. I am relatively new to Windows-NT and, even
-though I am a card carrying @code{UNIX} bigot, I am excited about the
-NT OS. My goals for lilypond are to give back to the Free Software
-Foundation a little of what they have given me over the years and to
-contribute to the lilypond project by supporting a Windows-NT port. I
-hope that someday we can distribute and run lilypond on the NT OS in a
-much more native fashion.
-
-@itemize @bullet
-
-@item Building lilypond on Windows-NT
-@item Maintaining lilypond on Windows-NT
-@item Running lilypond on Windows-NT
-
-@end itemize
-
-
-Currently as stated above lilypond is primarily a @code{UNIX} thing.
-The Windows-NT port is based on the @code{UNIX} environment provided by
-@uref{http://www.cygnus.com,Cygnus}. Therefore the first step is to
-download and install the Cygnus development kit:
-
-@uref{http://www.cygnus.com/misc/gnu-win32/}
-
-Please follow the documentation Cygnus has on there web site for
-downloading and installing. The important part is that you down load
-the entire development kit. I believe it is @file{full.exe}. The
-installation will ask you where you want to install it. I will refer
-to Cygnus installation directory as @file{/gnuwin32/cygwin-b20}. There
-should be a @file{README} file that contains installation instructions.
-After the installation is complete you should have a @emph{Cygnus}
-shortcut in your @emph{Program} section of your @emph{Start Menu}. This
-shortcut is your door to the @code{UNIX} world and I will refer to the
-resulting window as a @file{bash} shell.
-
-The shortcut points to @file{/gnuwin32/cygwin-b20/cygnus.bat}. The
-following is my @file{cygnus.bat} file.
-
-@example
-
-@@ECHO OFF
-rem default environment
-
-rem GNU cygnus installation
-
-SET CYGREL=B19.1
-SET MAKE_MODE=unix
-SET LOCAL_ROOT=d:\gnuwin32
-SET LOCAL_FS=d:/gnuwin32
-SET LOCAL_DIR=d:/gnuwin32/cygwin-b20
-SET CYGROOT=%LOCAL_ROOT%\cygwin-b20
-SET CYGFS=%LOCAL_FS%/cygwin-b20
-SET TCL_LIBRARY=%CYGROOT%\share\tcl8.0
-rem
-rem This was not in the original but is needed by lots of packages
-rem
-SET BISON_SIMPLE=%CYGFS%/share/bison.simple
-
-rem
-rem I place the cygnus stuff in front of /WINNT
-rem
-
-SET PATH=d:\bin;%LOCAL_ROOT%\bin;%CYGROOT%\H-i586-cygwin32\bin;%PATH%
-SET MANPATH=%LOCAL_ROOT%\man;%LOCAL_ROOT%\cygwin-b20\full-man\man
-SET INFOPATH=%LOCAL_FS%/cygwin-b20/full-man/info;%LOCAL_FS%/cygwin-b20/info;%LOCAL_DIR%/info
-
-rem General tools not included with Cygnus Development Kit
-
-rem CVS
-
-SET PATH=%PATH%;%LOCAL_ROOT%\cvs-1.9.28\bin
-SET INFOPATH=%INFOPATH%;%LOCAL_FS%/cvs-1.9.28/info
-SET MANPATH=%MANPATH%;%LOCAL_ROOT%\cvs-1.9.28\man
-
-rem EMACS
-
-SET PATH=%PATH%;%LOCAL_ROOT%\emacs-19.34\bin
-SET INFOPATH=%INFOPATH%;%LOCAL_FS%/emacs-19.34/info
-
-rem VIM
-
-SET VIM=%LOCAL_ROOT%\vim-4.6\doc
-SET PATH=%PATH%;%LOCAL_ROOT%\vim-4.6
-
-rem TeX
-
-SET PATH=%PATH%;%LOCAL_ROOT%\texmf\miktex\bin
-
-rem a2ps
-
-SET PATH=%PATH%;%LOCAL_ROOT%\a2ps-4.10\bin
-SET INFOPATH=%INFOPATH%;%LOCAL_FS%/a2ps-4.10/info
-SET MANPATH=%MANPATH%;%LOCAL_ROOT%\a2ps-4.10\man
-
-rem python
-
-SET PATH=%PATH%;\Program Files\Python
-
-rem perl
-
-SET PATH=%PATH%;\qub
-
-rem yodl
-
-uname -sv
-bash -login
-
-@end example
-
-Please look over this carefully. Be careful with the forward and
-backward slash notations. The paths specified were done for good
-reasons. Maybe someday we will all be using @code{UNC}. Note the
-@code{BISON} entry and the @code{PATH} ordering in particular. Also note
-that the generic @file{cygnus.bat} you will be looking at does not
-include alot of the packages listed. We will be installing some of
-these.
-
-The installation also suggests that you create a directory @file{/bin}
-and copy @file{/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/sh.exe} to
-@file{/bin}. The @file{sh.exe} shell provided by Cygnus is a descendant
-of the @file{ash} shell. The @file{sh.exe} shell has improved greatly
-and is much faster than the @file{bash} shell for script invocations.
-So this is my recommendation for post installation steps. From a
-@file{bash} shell:
-
-@itemize @bullet
-@item @code{cd /}
-@item @code{mkdir bin}
-@item @code{cd /bin}
-@item @code{cp /gnuwin32/cygwin-b20/H-i586-cygwin32/bin/sh.exe sh.exe}
-@item @code{cp /gnuwin32/cygwin-b20/H-i586-cygwin32/bin/bash.exe bash.exe}
-@item @code{cd /}
-@item @code{mkdir /tmp}
-@item @code{chmod a+rwx tmp}
-@item @code{mkdir /etc}
-@item @code{cd /etc}
-@item @code{mkpasswd -l > passwd}
-@item @code{mkgroup -l > group}
-@end itemize
-
-
-There is also some discussion of how you want to @emph{mount} the Cygnus
-development kit. @emph{mount} is a @code{UNIX} term that refers to the
-mechanism used to provide a disk resource to the filesystem. Cygnus
-supplies a mechinism for @emph{mounting} a filesystem as a @code{DOS} like
-resource or a @code{UNIX} like resource. Among other things this
-attempts to deal with the text file carriage return line feed on
-@code{DOS} versus the line feed on @code{UNIX} and the issue that @code{DOS}
-has two file types, text and binary. Where @code{UNIX} deals with a
-single streams type. My opinion on this matter currently is to use
-binary mounts only. This can be accomplished by:
-
-@itemize @bullet
-@item From a bash shell, umount /
-@item mount -b d: /
-@end itemize
-
-If you have other disks that you intend to use for data generated by
-cygnus tools you will have to mount those devices with the @emph{-b}
-switch.
-
-
-@uref{http://www.xraylith.wisc.edu/~khan/software/gnu-win32/egcs.html}
-
-Cygnus now distributes the ecgs compiler with cygwin-b20.
-
-
-@uref{http://www.gnu.org/order/ftp.html}
-
-Considering the origin of the major contributors of lilypond, this is a
-must. However before we actually do a @strong{GNU} build we have to
-discuss some caveats of the Windows-NT OS in particular the naming of
-executable files. @code{Windows-NT} uses a .exe extension where @code{UNIX}
-does not use an extension. This causes a problem during the
-installation portion of a @strong{GNU} build. The following script can be
-used to help alleviate this problem.
-
-@example
-
-#!/bin/sh
-
-realinstall=/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/install.exe
-args=''
-while [ $# -ne 0 ]
-do
- case $1 in
- -*) args="$args $1"
- ;;
-
- *) if [ -f $1.exe ]; then
- args="$args $1.exe"
- else
- args="$args $1"
- fi
- ;;
- esac
- shift
-done
-
-$realinstall $args
-
-@end example
-
-I place this in script @file{~/bin}. The LilyPond configure, build,
-and install process handles this with it's own install script. In
-addition there are patches to the cygnus install command that also
-deals with this problem. Having said that, here is how one
-might build the @emph{gettext} package.
-
-@itemize @bullet
-@item download the package from one of the ftp sites.
-@item From a bash shell, cd ~/usr/src.
-@item tar zxf gettext-0.10.tar.gz
-@item cd gettext-0.10
-@item ./configure --prefix=$CYGFS/H-i586-cygwin32
-@item make
-@item make install
-@end itemize
-
-
-@uref{http://www.gnu.org/order/ftp.html}
-
-Following the instructions for @emph{gettext} package to download, build,
-and install the @emph{groff} package.
-
-
-@uref{http://www.python.org}
-
-Python is the scripting language of choice for a lilypond build.
-There is a native @code{Windows-NT} self extracting binary distribution
-available. I recommend installing Python in a directory that does
-@strong{not} have spaces. And then place it in the bash shell path by
-editing $CYGFS/cygnus.bat.
-
-
-@uref{http://www.cpan.org}
-
-I believe perl is used in some legacy scripts to date. There is a
-native @code{Windows-NT} self extracting binary distribution available.
-I recommend installing Perl in a directory that does @strong{not} have
-spaces. And then place it in the bash shell path by editing
-$CYGFS/cygnus.bat.
-
-The development methodology of @emph{LilyPond} relies on a the following
-directory structure:
-
-
-@example
-
-$HOME/usr/src/
- |-releases/
- |-patches/
- |-test/
-
-@end example
-
-@table @samp
-
-@item releases/ Downloaded and generated releases live here. For
-example @file{lilypond-1.1.17.tar.gz}.
-
-@item patches/ Downloaded and generated patches live here. For
-example @file{lilypond-1.1.17.diff.gz}.
-
-@item test/ This directory is used to generate releases and patches.
-
-@end table
-
-I strongly recommend using this file structure to build @emph{yodl} and
-@emph{lilypond}.
-
-@itemize @bullet
-@item download the package from
-@uref{http://www.xs4all.nl/~jantien/yodl/} to
-@file{$HOME/usr/src/releases}.
-@item From a bash shell, cd @file{$HOME/usr/src}.
-@item tar zxf releases/yodl-@emph{<version>}.tar.gz
-@item cd yodl-@emph{<version>}
-@item ./configure --prefix=/gnuwin32/yodl-@emph{<version>} --srcdir=.
-Since @emph{yodl} is under development I choose to install it in a
-version rooted directory. This allows me to test newly released
-versions without losing a known working version.
-
-@item make
-@item make install
-@item place it in the bash shell path by editing $CYGFS/cygnus.bat.
-For example:
-@example
-rem yodl
-
-SET PATH=%PATH%;%LOCAL_ROOT%\yodl-1.31.7\bin
-
-
-@end example
-
-@end itemize
-
-
-
-GUILE, GNU's Ubiquitous Intelligent Language for Extension, is a
-library that implements the Scheme language plus various convenient
-facilities. It's designed so that you can link it into an application
-or utility to make it extensible. GNU's plan is to link this library
-into all GNU programs that call for extensibility.
-
-@itemize @bullet
-@item download guile-1.3 patch from
-@uref{http://home.austin.rr.com/jbr/jeff/lilypond/guile.patch} and save it
-to @file{/tmp/guile.patch}.
-@item download guile-1.3 from one of GNU's ftp sites.
-@item From a bash shell, tar zxf guile-1.3.tar.gz
-@item cd guile-1.3
-@item patch -p2 < /tmp/guile.patch
-@item LD=/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/ld \ @*
- ./configure --prefix=$CYGFS/H-i586-cygwin32
-@item make sure bin_PROGRAMS macro in libguile/Makefile does @emph{not} have the
-.exe extension during the build
-@item make
-@item make sure bin_PROGRAMS in libguile/Makefile @emph{does} have the
-.exe extension during the install. Yuck.
-@item make install
-@end itemize
-
-
-@itemize @bullet
-@item download the package from
-@uref{http://www.cs.uu.nl/people/hanwen/lilypond/} to
-@file{$HOME/usr/src/releases}.
-@item From a bash shell, cd @file{$HOME/usr/src}.
-@item tar zxf releases/lilypond-@emph{<version>}.tar.gz
-@item cd lilypond-@emph{<version>}
-@item ./configure --prefix=/gnuwin32/lilypond-@emph{<version>} \ @*
- --srcdir=. @*
-Since @emph{lilypond} is under development I choose to install it in a
-version rooted directory. This allows me to test newly released
-versions without losing a known working version.
-@item make
-@item make install
-@item place it in the bash shell path by editing $CYGFS/cygnus.bat.
-For example:
-@example
-rem lilypond
-
-SET PATH=%PATH%;%LOCAL_ROOT%\lilypond-1.1.17\bin
-
-
-@end example
-
-@end itemize
-
-
-If you have built @emph{lilypond} on @code{Windows-NT} using the directory
- and the process described
-in section FIXME, then you are ready to maintain
-@emph{lilypond}. It can not be that easy!? Well, there is one caveat.
-Currently to use the @file{stepmake/bin/release.py} and
-@file{stepmake/bin/package-diff.py} scripts you need to obtain/build a
-version of @emph{python} that was built with @strong{Cygnus} development kit.
-The process I used is as follows:
-
-@itemize @bullet
-@item obtain python source from @uref{http://www.python.org}
-@item tar zxf /tmp/python-@emph{<version>}.tar.gz
-@item cd python-@emph{<version>}
-@item configure --prefix=/gnuwin32/Python-@emph{<version>}
-@item edit toplevel @file{Makefile} @code{EXE} macro so it reads @code{EXE=.exe}
-@item make
-@item make install
-@item place it in the bash shell path by editing $CYGFS/cygnus.bat.
-For example:
-@example
-rem python
-
-SET PATH=%PATH%;%LOCAL_ROOT%\python-1.5.1\bin
-
-
-@end example
-
-@end itemize
-
-I choose to build @emph{lilypond} with the standard @code{Windows-NT}
-@emph{python} and use the @strong{Cygnus} version for using the release
-scripts. This way I can make sure the @code{Windows-NT} @emph{python}
-version is able to build @emph{lilypond}. Currently there are several
-issues with the release scripts. Using @code{os.link} and
-@code{os.system(set -x;...)} are to name a few.
-
-To generate a new release and patch you must use the directory
-. And follow the
-instructions found in @file{PATCH.txt}. Editing
-@file{Documentation/AUTHORS.yo}, @file{VERSION}, and @file{NEWS} is also
-required. When my edits are complete and tested I:
-
-@itemize @bullet
-@item Edit @file{config.make} and change @emph{python} path to the
-@strong{Cygnus} version: @code{PYTHON=/gnuwin32/Python-1.5.1/bin/python}.
-@item make release
-@end itemize
-
-The new release is placed in @file{releases} directory and the patch is
-placed in the @file{patches} directory. I email the new patch to
-@email{gnu-music-discuss@@gnu.org}. More than one patch a day can be
-generated by:
-
-@itemize @bullet
-@item cd $HOME/usr/src
-@item tar zxf releases/lilypond-@emph{<version>}.@emph{<patchlevel>}
-@item use your normal configure
-@item make edits
-@item Change @file{VERSION} to increment @emph{<patchlevel>}
-@item Change @file{NEWS}
-@item make release
-@end itemize
-
-
-We are now distributing a formated binary distribution for
-Windows-NT. Please refer to
-@uref{http://home.austin.rr.com/jbr/jeff/lilypond/} for current news,
-download, installation, and running information.
-
-Jeffrey B. Reed @email{daboys@@austin.rr.com}
-
-@section RUNNING LILYPOND -- by Dominique Cretel
-
-You may want to refer to section FIXME, for more current
-information about downloading, installing, and running the Windows-NT
-binary distribution.
-
-@enumerate i
-@item First, I have download tha 0.1.64 version of LilyPond music software.
-
-@item Then I extract it in a temp directory, and I move the directory
-"lilypond-0.1.64" to the root directory of my D drive.
-
-@item I go to the D:\Lilypond-0.1.64\tex directory to modify the
-lilyponddefs.tex file (lines 75 and 84), and comment all
-cmbx15 ans cmbx14, and replace them by cmbx12.
-
-@item build a command file like this:
-Note: I use MiKTeX to process the tex file generated.
-
-@example
-
----begin ly2dvi.bat
-echo off
-set ver=0.1.64
-set path=%path%;d:\lilypond-%ver%\bin
-lilypond -I d:\lilypond-%ver%\init %1
-rem *** pause
-
-set path=c:\texmf\miktex\bin;%path%
-set TEXINPUTS=%TEXINPUTS%;d:\lilypond-%ver%\tex
-set MFINPUTS=%MFINPUTS%;d:\lilypond-%ver%\mf
-tex %1.tex
-rem *** pause
-
-dvips %1.dvi
-rem *** pause
-
-set path=%path%;d:\gstools\gsview
-gsview32 %1.ps
----end ly2dvi.bat
-
-@end example
-
-@item execute lilypond by doing:
-@example
-
-ly2ps silly <Enter>
-
-@end example
-
-@end enumerate
-
-Note:
-@*
-You'll better have to put the SET commands lines in a separate command
-file to avoid consumming each time environnment ressources.
-
-Bye,@*
-Dominique Cretel @email{dominique.cretel@@cfwb.be}
-
-@section PROBLEMS AND ANWSWERS
-
-This is all to confusing. I have:
-@enumerate i
-@item downloaded @file{/tmp/lilypond-0.1.78.tar.gz}
-@item @example
-
- cd ~/usr/src
-
-@end example
-
-@item @example
-
- tar zxf /tmp/lilypond-0.1.78.tar.gz
-
-@end example
-
-@item @example
-
- ./configure --prefix=/users/jeff/lilypond-0.1.78 \--enable-tex-prefix=/users/jeff/lilypond-0.1.78/texmf \--enable-tex-dir=/users/jeff/lilypond-0.1.78/texmf/tex \--enable-mf-dir=/users/jeff/lilypond-0.1.78/texmf/mf
-
-@end example
-
-@item @example
-
- make
-
-@end example
-
-@item @example
-
- make install
-
-@end example
-
-@end enumerate
-
-I did have a problem with lilypond.info. And I will look into this
-further. After mending lilypond.info issue, it compiled and install
-with no problems.
-
-I have 64 Meg of physical memory and 64 Meg of swap. Actually I need
-to increase the swap space. If a memory problem is occuring it most
-likely is during the link process of lilypond. There is a boat load
-of objects to link.
-
-Jan the mount -b stuff is confussing to me. I have the entire system
-mounted _without_ -b and only use -b on certain paths for programs
-that create binary files that do not use O_BINARY open option. By the
-way the midi file open is one of these cases, I need to look into
-that. I have had no problems with this methodology.
-
-
-The windows multiroot filesystem is an utterly broken concept. Please
-do everything on one (urg) drive, C:.
-
-@example
-
-> configure
-> creating cache ./config.cache
-> [..]
-> creating config.make
-> creating config.hh
-> cd: lstat /d failed
-
-@end example
-
-Ok, this looks like another stupid windows problem.
-You're working on 'drive D:', right?
-
-I can think of some solutions, but i don't know if they work;
-i just had to do some work in windows some time ago. If you
-have problems with this, please ask @email{gnu-win32@@cygnus.com}.
-I'll start with the simplest:
-@itemize @bullet
- @item do everything on drive C:, or
- @item explicitely mount drive d:, work from there:
- @example
-
- mkdir -p /mnt/d
- mount d: /mnt/d
- cd /mnt/d/lilypond-x.y.z/
-
-@end example
-
- @item make d:/ the root of cygnus, in cmd.exe/command.exe do:
- @example
-
- umount /
- mount d: /
-
-@end example
-
-@end itemize
-
-
-> - First I have installed Python (for win32) "Pyth151.exe" and "Configure
-@*
-> don't find it. I had to put it in the path for configure find it?
-@*
-
-Yes, of course. It should be possible to have different versions of tools
-installed (e.g. perl 4 and perl 5). The best way to tell people (or tools
-like configure) which one to use is to put it in the path?
-
-Another small unix lesson: Where under dos each program installs itself
-into a nice directory
-@example
-
- c:\DosProgram\*
-
-@end example
-
-under unix, installation is handled centrally. Executables go in
-@file{/usr/bin} (or @file{/usr/local/bin}), and are always in your path.
-
-
-@example
-
-> 4. make -C lily don't work. I get an error (see below). I get several
-> object files in the ./lily/out directory (34 files: 17 *.dep, 16 *.o,
-> and 1 *.hh):
-> [...]
-> include/engraver-group.hh:35: virtual memory exhausted
-> make: *** [out/bar-grav.o] Error 1
-> bash-2.01$
-
-
-@end example
-
-Ok, so everything works now, there's only some error with one of the
-source files. Lets see which one (and now the cc's now why they're
-reading this :-)
-
-It looks like you've run out of memory. You should compile without
-optimisation, gcc/egcs need a lot of memory for optimising.
-Reconfigure without optimisation:
-@example
-
- configure --disable-optimise
-
-@end example
-
-or edit @file{config.make}:
-@example
-
- ## USER_CXXFLAGS = -g # -O no optimise!
- USER_CXXFLAGS = -g
-
-@end example
-
-There are some other things to look at: how much RAM do you have
-(please say something > 8Mb :-)? Although it might be an egcs bug,
-you should have a look at the size of your swap file.
-For an US version of windows, you should find it here:
-@example
-
- /start/settings/control-panel/system/performance/virtual-memory
-
-@end example
-
-you see, amongst others, these entries:
-@example
-
- paging file size for selected drive:
-
- space-available: xx
- initial-size: xx
- maximum-size: xx
-
- total paging file size for all drives
-
- currently allocated: xx
-
-@end example
-
-Try to set:
-@example
-
- initial-size: 64
- maximum-size: 128
-
-@end example
-
-Make sure that:
-@itemize @bullet
-@item maximum-size >= 128 Mb
-@item urrently-allocated + space-available >= 128 Mb
-@end itemize
-
-
-@bye