Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

OTP-8449 Documentation improvements.

          The most important "readme" files now use Markdown notation. HTML
          versions of these files are now also automatically generated and
          included in the HTML documentation.

          - Building and Installing Erlang/OTP - $ERL_TOP/INSTALL.md
          (previously known as $ERL_TOP/README).

          - Cross Compiling Erlang/OTP - $ERL_TOP/INSTALL-CROSS.md.

          - How to Build Erlang/OTP on Windows - $ERL_TOP/INSTALL-WIN32.md
          (previously known as $ERL_TOP/README.win32).
  • Loading branch information...
commit 7aa2cb2e64cd404f8a9f388d85ab287ced95f139 1 parent 924f3aa
@rickard-green rickard-green authored Erlang/OTP committed
View
1  INSTALL-CROSS.md
View
779 INSTALL-WIN32.md
@@ -0,0 +1,779 @@
+How to Build Erlang/OTP on Windows
+==================================
+
+Table of Contents
+-----------------
+
+1. Introduction
+2. Frequently Asked Questions
+3. Tools you Need and Their Environment
+4. The Shell Environment
+5. Building and Installing
+6. Development
+7. Final Words
+8. Copyright and License
+
+Introduction
+------------
+
+This file describes how to build the Erlang emulator and the OTP
+libraries on Windows. The instructions apply to versions of Windows
+supporting the Cygwin emulated gnuish environment for Windows. We've
+built on the following platforms: Windows 2000 Professional, Windows
+2003 server, Windows XP Home/Professional, and Windows Vista. Any
+Windows95'ish platform will surely get you into trouble, what I'm not
+sure of, but it certainly will...
+
+The procedure described uses Cygwin as a build environment, you run
+the bash shell in Cygwin and uses gnu make/configure/autoconf etc to
+do the build. The emulator C-source code is, however, mostly compiled
+with Microsoft Visual C++(tm), producing a native Windows binary. This
+is the same procedure as we use to build the pre-built binaries. The
+fact that we use VC++ and not gcc is explained further in the FAQ
+section.
+
+I describe the build procedure to make it possible for open source
+customers to build the emulator, given that they have the needed
+tools. The binary Windows releases is still a preferred alternative if
+one does not have Microsoft's development tools and/or don't want to
+install Cygwin.
+
+To use Cygwin, one needs basic experience from a Unix environment, if
+one does not know how to set environment variables, run programs etc
+in a Unix environment, one will be quite lost in the Cygwin
+ditto. I can unfortunately not teach all the world how to use
+Cygwin and bash, neither how to install Cygwin nor perform basic tasks
+on a computer. Please refer to other documentation on the net for
+help, or use the binary release instead if you have problems using the
+tools.
+
+However, if you feel comfortable with the environment and build
+system, and have all the necessary tools, you have a great opportunity
+to make the Erlang/OTP distribution for Windows better. Please submit
+any suggestions and patches to the appropriate mailing lists (see
+<http://www.erlang.org/faq.html>) to let them find their way into the next
+version of Erlang. If making changes to the build system (like
+makefiles etc) please bear in mind that the same makefiles are used on
+Unix/VxWorks/OSEDelta, so that your changes don't break other
+platforms. That of course goes for C-code too, system specific code
+resides in the `$ERL_TOP/erts/emulator/sys/win32` and `$ERL_TOP/erts/etc/win32`
+directories mostly. The `$ERL_TOP/erts/emulator/beam directory` is for
+common code.
+
+Before the R9C release of Erlang/OTP, the Windows release was built
+partly on a Unix (Solaris) box and partly on a Windows box, using Perl
+hacks to communicate and sync between the two machines. R9C was the
+first release ever built solely on Windows, where no Unix machine is
+needed at all. Now we've used this build procedure for a couple of
+releases, and it has worked fine for us. Still, there might be all
+sorts of troubles on different machines and with different
+setups. I'll try to give hints wherever I've encountered difficulties,
+but please share your experiences by using the mailing list
+<erlang-questions@erlang.org>. I cannot of course help everyone with all
+their problems, please try to solve the problems and submit
+solutions/workarounds. Remember, it's all about sharing, not about
+demanding...
+
+Lets go then, I'll start with a little FAQ, based on in house questions
+and misunderstandings.
+
+
+Frequently Asked Questions
+--------------------------
+
+* Q: So, now I can build Erlang using GCC on Windows?
+
+ A: No, unfortunately not. You'll need Microsoft's Visual C++ still, a
+ Bourne-shell script (cc.sh) wraps the Visual C++ compiler and runs it
+ from within the Cygwin environment. All other tools needed to build
+ Erlang are free-ware/open source, but not the C compiler.
+
+* Q: Why haven't you got rid of VC++ then, you `******`?
+
+ A: Well, partly because it's a good compiler - really! Actually it's
+ been possible in late R11-releases to build using mingw instead of
+ visual C++ (you might see the remnants of that in some scripts and
+ directories). Unfortunately the development of the SMP version for
+ Windows broke the mingw build and we chose to focus on the VC++ build
+ as the performance has been much better in the VC++ versions. The
+ mingw build will be back, but as long as VC++ gives better
+ performance, the commercial build will be a VC++ one.
+
+* Q: OK, VC++ you need, but now you've started to demand a very recent
+ (and expensive) version of Visual studio, not the old and stable VC++
+ 6.0 that was used in earlier versions. Why?
+
+ A: The SMP version of Erlang needs features in the Visual Studio 2005.
+ Can't live without them. Besides the new compiler gives the Erlang
+ emulator a ~40% performance boost(!)
+
+* Q: Can/will I build a Cygwin binary with the procedure you describe?
+
+ A: No, the result will be a pure Windows binary, and as far as I know,
+ it's not possible to make a Cygwin binary yet. That is of course
+ something desirable, but there are still some problems with the
+ dynamic linking (dynamic Erlang driver loading) as well as the TCP/IP
+ emulation in Cygwin, which, I'm sure of, will improve, but still has
+ some problems. Fixing those problems might be easy or might be hard.
+ I suggest you try yourself and share your experience. No one would be
+ happier if a simple ./configure && make would produce a fully fledged
+ Cygwin binary. Ericsson does however not pay me to do a Cygwin port, so
+ such a port would have to happen in spare time, which is a limited
+ resource...
+
+* Q: Hah, I saw you, you used GCC even though you said you didn't!
+
+ A: OK, I admit, one of the files is compiled using Cygwin's GCC and
+ the resulting object code is then converted to MS VC++ compatible coff
+ using a small C hack. It's because that particular file, `beam_emu.c`
+ benefits immensely from being able to use the GCC labels-as-values
+ extension, which boosts emulator performance by up to 50%. That does
+ unfortunately not (yet) mean that all of OTP could be compiled using
+ GCC, that particular source code does not do anything system specific
+ and actually is adopted to the fact that GCC is used to compile it on
+ Windows.
+
+* Q: So now there's a MS VC++ project file somewhere and I can build OTP
+ using the nifty VC++ GUI?
+
+ A: No, never. The hassle of keeping the project files up to date and
+ do all the steps that constitute an OTP build from within the VC++ GUI
+ is simply not worth it, maybe even impossible. A VC++ project
+ file for Erlang/OTP will never happen, at least I will never make
+ one. Clicking around in super-multi-tab'd dialogs to add a file or
+ compiler option when it's so much easier in a makefile is simply not
+ my style.
+
+* Q: So how does it all work then?
+
+ A: Cygwin is the environment, which closely resembles the environments
+ found on any Unix machine. It's almost like you had a virtual Unix
+ machine inside Windows. Configure, given certain parameters, then
+ creates makefiles that are used by the Cygwin gnu-make to built the
+ system. Most of the actual compilers etc are not, however, Cygwin
+ tools, so I've written a couple of wrappers (Bourne-shell scripts),
+ which reside in `$ERL_TOP/etc/win32/cygwin_tools` and they all do
+ conversion of parameters and switches common in the Unix environment
+ to fit the native Windows tools. Most notable is of course the paths,
+ which in Cygwin are Unix-like paths with "forward slashes" (/) and no
+ drive letters, the Cygwin specific command `cygpath` is used for most
+ of the path conversions. Luckily most compilers accept forward slashes
+ instead of backslashes as path separators, one still have to get the
+ drive letters etc right, though. The wrapper scripts are not general
+ in the sense that, for example, cc.sh would understand and translates
+ every possible gcc option and passes correct options to cl.exe. The
+ principle is that the scripts are powerful enough to allow building of
+ Erlang/OTP, no more, no less. They might need extensions to cope with
+ changes during the development of Erlang, that's one of the reasons I
+ made them into shell-scripts and not Perl-scripts, I believe they are
+ easier to understand and change that way. I might be wrong though,
+ cause another reason I didn't write them in Perl is because I've never
+ liked Perl and my Perl code is no pleasant reading...
+
+ In `$ERL_TOP`, there is a script called `otp_build`, that script handles
+ the hassle of giving all the right parameters to `configure`/`make` and
+ also helps you set up the correct environment variables to work with
+ the Erlang source under Cygwin.
+
+* Q: You use and need Cygwin, but then you haven't taken the time to
+ port Erlang to the Cygwin environment but instead focus on your
+ commercial release, is that really ethical?
+
+ A: No, not really, but see this as a step in the right direction. I'm
+ aiming at GCC compiled emulators and a Cygwin version, but I really
+ need to do other things as well... In time, but don't hold your
+ breath...
+
+* Q: Can I build something that looks exactly as the commercial release?
+
+ A: Yes, we use the exactly same build procedure.
+
+* Q: Which version of Cygwin and other tools do you use then?
+
+ A: For Cygwin we try to use the latest releases available when
+ building. What versions you use shouldn't really matter, I try to
+ include workarounds for the bugs I've found in different Cygwin
+ releases, please help me to add workarounds for new Cygwin-related
+ bugs as soon as you encounter them. Also please do submit bug reports
+ to the appropriate Cygwin developers. The Cygwin GCC we used for R13B
+ was version 3.4.4. We used VC++ 8.0 (i.e. Visual studio 2005 SP1),
+ Sun's JDK 1.5.0\_17, NSIS 2.37, and Win32 OpenSSL 0.9.8e. Please read
+ the next section for details on what you need.
+
+* Q: Can you help me setup X in Cygwin?
+
+ A: No, unfortunately I haven't got time to help with Cygwin related
+ user problems, please read Cygwin related web sites, newsgroups and
+ mailing lists.
+
+* Q: Why is the instruction so long? Is it really that complicated?
+
+ A: Partly it's long because I babble too much, partly because I've
+ described as much as I could about the installation of the needed
+ tools. Once the tools are installed, building is quite easy. I also
+ have tried to make this instruction understandable for people with
+ limited Unix experience. Cygwin is a whole new environment to some
+ Windows users, why careful explanation of environment variables etc
+ seemed to be in place. The short story, for the experienced and
+ impatient is:
+
+ * Get and install complete Cygwin (latest)
+
+ * (Buy and) Install Microsoft Visual studio 2005 and SP1 (or higher)
+
+ * Get and install Sun's JDK 1.4.2
+
+ * Get and install NSIS 2.01 or higher (up to 2.30 tried and working)
+
+ * Get and install OpenSSL 0.9.7c or higher
+
+ * Get and unpack wxWidgets-2.8.9 or higher to `/opt/local/pgm` inside
+ cygwin.
+ * Open `/cygwin/opt/local/pgm/wxWidgets-2.8.9/build/msw/wx.dsw`
+ * Enable `wxUSE_GLCANVAS`, `wxUSE_POSTSCRIPT` and
+ `wxUSE_GRAPHICS_CONTEXT` in `include/wx/msw/setup.h`
+ * Build all unicode release (and unicode debug) packages
+ * Open `/cygwin/opt/local/pgm/wxWidgets-2.8.9/contrib/build/stc/stc.dsw`
+ * Build the unicode release (and unicode debug) packages
+
+ * Get the Erlang source distribution (from
+ <http://www.erlang.org/download.html>) and unpack with Cygwin's `tar`.
+
+ * Set `ERL_TOP` to where you unpacked the source distribution
+
+ * `$ cd $ERL_TOP`
+
+ * Get (from <http://www.erlang.org/download/tcltk85_win32_bin.tar.gz>)
+ and unpack the prebuilt TCL/TK binaries for windows with cygwin tar,
+ standing in `$ERL_TOP`
+
+ * Modify PATH and other environment variables so that all these tools
+ are runnable from a bash shell. Still standing in `$ERL_TOP`, issue
+ the following commands:
+
+ $ eval `./otp_build env_win32`
+ $ ./otp_build autoconf
+ $ ./otp_build configure
+ $ ./otp_build boot -a
+ $ ./otp_build release -a
+ $ ./otp_build installer_win32
+ $ release/win32/otp_win32_<OTP version> /S
+
+ Voila! `Start->Programs->Erlang OTP <OTP version>->Erlang` starts the Erlang
+ Windows shell.
+
+
+Tools you Need and Their Environment
+------------------------------------
+
+You need some tools to be able to build Erlang/OTP on Windows. Most
+notably you'll need Cygwin and Microsoft VC++, but you also might want
+a Java compiler, the NSIS install system and OpenSSL. Only VC++ costs
+money, but then again it costs a lot of money, I know...
+Well' here's the list:
+
+* Cygwin, the very latest is usually best. Get all the development
+ tools and of course all the basic ditto. In fact getting the complete
+ package might be a good idea, as you'll start to love Cygwin after a
+ while if you're accustomed to Unix. Make sure to get jar and also make
+ sure *not* to install a Cygwin'ish Java... The Cygwin jar command is
+ used but Sun's Java compiler and virtual machine...
+
+ URL: <http://www.cygwin.com>
+
+ Get the installer from the web site and use that to install
+ Cygwin. Be sure to have fair privileges. If you're on a NT domain you
+ should consider running `mkpasswd -d` and `mkgroup -d` after the
+ installation to get the user databases correct. See their respective
+ manual pages.
+
+ When you start you first bash shell, you will get an awful prompt. You
+ might also have a `PATH` environment variable that contains backslashes
+ and such. Edit `$HOME/.profile` and `$HOME/.bashrc` to set fair prompts
+ and set a correct PATH. Also do a `export SHELL` in `.profile`. For some
+ non-obvious reason the environment variable `$SHELL` is not exported in
+ bash. Also note that `.profile` is run at login time and `.bashrc` when
+ sub shells are created. You'll need to explicitly source `.bashrc` from
+ `.profile` if you want the commands there to be run at login time (like
+ setting up aliases, shell functions and the like). I personally
+ usually do like this at the end of `.profile`:
+
+ ENV=$HOME/.bashrc
+ export ENV
+ . $ENV
+
+ You might also, if you're a hard core type of person at least, want to
+ setup X-windows (XFree86), that might be as easy as running startx
+ from the command prompt and it might be much harder. Use Google to
+ find help...
+
+ If you don't use X-windows, you might want to setup the Windows
+ console window by selecting properties in the console system menu
+ (upper left corner of the window, the Cygwin icon in the title
+ bar). Especially setting a larger screen buffer size (lines) is useful
+ as it gets you a scrollbar so you can see whatever error messages
+ that might appear...
+
+ If you want to use (t)csh instead of bash you're on your own, I
+ haven't tried and know of no one that has. I expect
+ that you use bash in all shell examples.
+
+* Microsoft Visual Studio 2005 SP1. Please don't skip the service
+ pack! The installer might update your environment so that you can run
+ the `cl` command from the bash prompt, then again it might
+ not... There is always a BAT file in VC\Bin under the installation
+ directory (default `C:\Program Files\Microsoft Visual Studio 8`) called
+ `VCVARS32.BAT`. Either add the environment settings in that file to the
+ global environment settings in Windows or add the corresponding BASH
+ environment settings to your `.profile`/`.bashrc`. For example, in my case
+ I could add the following to `.profile`
+
+ #Visual C++ Root directory as Cygwin style pathname
+ VCROOT=/cygdrive/c/Program\ Files/Microsoft\ Visual\ Studio 8
+
+ # Visual C++ Root directory as Windows style pathname
+ WIN_VCROOT="C:\\Program Files\\Microsoft Visual Studio 8"
+
+ # The PATH variable should be Cygwin'ish
+ PATH=$VCROOT/Common7/IDE:$VCROOT/VC/BIN:$VCROOT/Common7/Tools:\
+ $VCROOT/Common7/Tools/bin:$VCROOT/VC/PlatformSDK/bin:$VCROOT/SDK/v2.0/bin:\
+ $VCROOT/VC/VCPackages:$PATH
+
+ # Lib and INCLUDE should be Windows'ish
+ # Note that semicolon (;) is used to separate Windows style paths but
+ # colon (:) to separate Cygwin ditto!
+
+ LIBPATH=$WIN_VCROOT\\VC\\ATLMFC\\LIB
+
+ LIB=$WIN_VCROOT\\VC\\ATLMFC\\LIB\;$WIN_VCROOT\\VC\\LIB\;\
+ $WIN_VCROOT\\VC\\PlatformSDK\\lib\;$WIN_VCROOT\\SDK\\v2.0\\lib
+
+ INCLUDE=$WIN_VCROOT\\VC\\ATLMFC\\INCLUDE\;$WIN_VCROOT\\VC\\INCLUDE\;\
+ $WIN_VCROOT\\VC\\PlatformSDK\\include
+
+ export PATH LIB INCLUDE
+
+ Make a simple hello world and try to compile it with the `cl` command
+ from within bash. If that does not work, your environment needs
+ fixing. Also remember to fix up the PATH environment, especially old
+ Erlang installations might have inserted quoted paths that Cygwin does
+ not understand. Remove or correct such paths. There should be no
+ backslashes in your path environment variable in Cygwin bash, but LIB
+ and INCLUDE should contain Windows style paths with semicolon,
+ drive letters and backslashes.
+
+ If you wish to use Visual Studio 2008, a couple things need to be tweaked,
+ namely the fact that some of the SDK stuff is installed in (by default)
+ `C:\Program Files\Microsoft SDKs\v6.0A` . Just ensure that that
+ `C:\Program Files\Microsoft SDKs\v6.0A\Lib` is in `LIB` and
+ `C:\Program Files\Microsoft SDKs\v6.0A\Include` is in `INCLUDE`. A symptom
+ of not doing this is errors about finding kernel32.lib and windows.h.
+
+ Additionally, if you encounter errors about mc.exe not being found, you must
+ install the entire Windows SDK (the partial SDK included in visual studio
+ apparently does not include it). After installing it you'll want to add
+ something like: `/c/cygdrive/Program\ Files/Microsoft\ SDKs/v7.0/bin` to
+ your `PATH` to allow the environment to find mc.exe. The next Visual Studio
+ (2010) is expected to include this tool.
+
+* Sun's Java JDK 1.5.0 or higher. Our Java code (jinterface, ic) is
+ written for JDK 1.5.0. Get it for Windows and install it, the JRE is
+ not enough. If you don't care about Java, you can skip this step, the
+ result will be that jinterface is not built.
+
+ URL: <http://java.sun.com>
+
+ Add javac *LAST* to your path environment in bash, in my case this means:
+
+ PATH="$PATH:/cygdrive/c/Program Files/Java/jdk1.5.0_17/bin"
+
+ No `CLASSPATH` or anything is needed. Type `javac` at the bash prompt
+ and you should get a list of available Java options. Make sure by
+ typing `which java` that you use the Java you installed. Note however that
+ Cygwin's `jar.exe` is used, that's why the JDK bin-directory should be
+ added last in the `PATH`.
+
+* Nullsoft NSIS installer system. You need this to build the self
+ installing package. It's a free open source installer that's much
+ nicer to use than the commercial Wise and Install shield
+ installers. This is the installer we use for commercial releases as
+ well from R9C an on.
+
+ URL: <http://www.nullsoft.com/free/nsis>
+
+ Install the lot, especially the modern user interface components, as
+ it's definitely needed. Put `makensis` in your path, in my case:
+
+ PATH=/cygdrive/c/Program\ Files/NSIS:$PATH
+
+ type makensis at the bash prompt and you should get a list of options
+ if everything is OK.
+
+* OpenSSL for Windows. This is if you want the SSL and crypto
+ applications to compile (and run). Go to <http://www.openssl.org>, click
+ on the `Related` link and then on the `Binaries` link (upper right
+ corner of the page last time I looked), you can then reach the
+ "Shining Lights Productions" Web site for Windows binaries
+ distributions. Get the latest or 0.9.7c if you get trouble with the
+ latest. It's a nifty installer. The rest should be handled by
+ `configure`, you needn't put anything in the path or anything.
+
+ If you want to build openssl for windows yourself (which might be
+ possible, as you wouldn't be reading this if you weren't a
+ compile-it-yourself person), you either have to put the resulting
+ DLL's in your path or in the windows system directory and either
+ specify where you put the includes etc with the configure-parameter
+ `--with-ssl=<cygwin path to the root>` or put your installation directly
+ under `c:\OpenSSL`. The directory structure under the installation root
+ for OpenSSL is expected to be one with subdirectories named `include`,
+ `bin` and `lib`, possibly with a `VC` subdirectory of `lib` containing
+ the actual `.lib` files. Note that the cygwin distributed OpenSSL cannot be
+ used, it results in cygwin depending binaries and it has unix style
+ archives (`.a`, not `.lib`).
+
+* Building with wxWidgets. Download wxWidgets-2.8.9 or higher patch
+ release (2.9.* is a developer release which currently does not work
+ with wxErlang).
+
+ Install or unpack it to `DRIVE:/PATH/cygwin/opt/local/pgm`
+ Open from explorer (i.e. by double clicking the file)
+ `C:\cygwin\opt\local\pgm\wxMSW-2.8.10\build\msw\wx.dsw`
+ In Microsoft Visual Studio, click File/Open/File, locate and
+ open: `C:\cygwin\opt\local\pgm\wxMSW-2.8.10\include\wx\msw\setup.h`
+ enable `wxUSE_GLCANVAS`, `wxUSE_POSTSCRIPT` and `wxUSE_GRAPHICS_CONTEXT`
+ Build it by clicking Build/Batch Build and select all unicode release
+ (and unicode debug) packages.
+
+ Open `C:\cygwin\opt\local\pgm\wxMSW-2.8.10\contrib/build/stc/stc.dsw`
+ and batch build all unicode packages.
+
+* The Erlang source distribution (from <http://www.erlang.org/download.html>).
+ The same as for Unix platforms. Preferably use tar from within Cygwin to
+ unpack the source tar.gz (`tar zxf otp_src_R13B04.tar.gz`).
+
+ set the environment ERL_TOP to point to the root directory of the
+ source distribution. Let's say I stood in `$HOME/src` and unpacked
+ `otp_src_R13B04.tar.gz`, I then add the following to `.profile`:
+
+ ERL_TOP=$HOME/src/otp_src_R13B04
+ export $ERL_TOP
+
+* The TCL/TK binaries. You could compile Tcl/Tk for windows yourself,
+ but you can get a stripped down version from our website which is
+ suitable to include in the final binary package. If you want to supply
+ tcl/tk yourself, read the instructions about how the tcl/tk tar file
+ used in the build is constructed under `$ERL_TOP/lib/gs/tcl`. The easy
+ way is to download <http://www.erlang.org/download/tcltk85_win32_bin.tar.gz>
+ and unpack it standing in the `$ERL_TOP` directory. This will create the
+ file `win32.tar.gz` in `$ERL_TOP/lib/gs/tcl/binaries`.
+
+ One last alternative is to create a file named `SKIP` in the
+ `$ERL_TOP/lib/gs/` after configure is run, but that will give you an
+ erlang system without gs (which might be okay as you probably will use
+ wx anyway).
+
+The Shell Environment
+---------------------
+
+So, if you have followed the instructions above, when you start a bash
+shell, you should have an INCLUDE environment with a Windows style
+path, a LIB environment variable also in Windows style, and finally a
+PATH that let's you reach cl, makensis, javac etc from the
+command prompt (use `which cl` etc to verify from bash).
+
+You should also have an `ERL_TOP` environment variable that is *Cygwin
+style*, and points to a directory containing, among other files, the
+script `otp_build`.
+
+A final massage of the environment is needed, and that is done by
+the script `$ERL_TOP/otp_build`. Start bash and do the following, note
+the "back-ticks" (\`), can be quite hard to get on some keyboards, but
+pressing the back-tick key followed by the space bar might do it...
+
+ $ cd $ERL_TOP
+ $ eval `./otp_build env_win32`
+
+If you're unable to produce back-ticks on your keyboard, you can use
+the ksh variant:
+
+ $ cd $ERL_TOP
+ $ eval $(./otp_build env_win32)
+
+This should do the final touch to the environment and building should
+be easy after this. You could run `./otp_build env_win32` without
+`eval` just to see what it does, and to see that the environment it
+sets seems OK. The path is cleaned of spaces if possible (using DOS
+style short names instead), the variables `OVERRIDE_TARGET`, `CC`, `CXX`,
+`AR` and `RANLIB` are set to their respective wrappers and the directories
+`$ERL_TOP/erts/etc/win32/cygwin_tools/vc` and
+`$ERL_TOP/erts/etc/win32/cygwin_tool` are added first in the PATH.
+
+Try now a `which erlc`. That should result in the erlc wrapper script
+(which does not have the .sh extension, for reasons best kept
+untold...). It should reside in `$ERL_TOP/erts/etc/win32/cygwin_tools`.
+You could also try `which cc.sh`, which `ar.sh` etc.
+
+Now you're ready to build...
+
+
+Building and Installing
+-----------------------
+
+Now it's assumed that you have executed `` eval `./otp_build env_win32` ``
+for this particular shell...
+
+Building is easiest using the `otp_build` script. That script takes care
+of running configure, bootstrapping etc on Windows in a simple
+way. The `otp_build` script is the utility we use ourselves to build on
+different platforms and it therefore contains code for all sorts of
+platforms. The principle is, however, that for non-Unix platforms, one
+uses `./otp_build env_<target>` to set up environment and then the
+script knows how to build on the platform "by itself". You've already
+run `./otp_build env_win32` in the step above, so now it's mostly like
+we build on any platform. OK, here are then steps; Assuming you will
+want to build a full installation executable with NSIS, you can omit
+`<installation directory>` and the release will be copied to
+`$ERL_TOP/release/win32`: and there is where the packed self installing
+executable will reside too.
+
+ $ ./otp_build autoconf # Ignore the warning blob about versions of autoconf
+ $ ./otp_build configure <optional configure options>
+ $ ./otp_build boot -a
+ $ ./otp_build release -a <installation directory>
+ $ ./otp_build installer_win32 <installation directory> # optional
+
+Now you will have a file called `otp_win32_R12B.exe` in the
+`<installation directory>`, i.e. `$ERL_TOP/release/win32`.
+
+Lets get into more detail:
+
+`$ ./otp_build autoconf` - This step rebuilds the configure scripts to
+work correctly in the cygwin environment. In an ideal world, this
+would not be needed, but alas, we have encountered several
+incompatibilities between our distributed configure scripts (generated
+on a Linux platform) and the cygwin environment over the
+years. Running autoconf on cygwin ensures that the configure scripts
+are generated in a cygwin-compatible way and that they will work well
+in the next step.
+
+`$ ./otp_build configure` - This runs the newly generated configure scripts
+with options making configure behave nicely. The target machine type is
+plainly `win32`, so a lot of the configure-scripts recognize this
+awkward target name and behave accordingly. The CC variable also makes
+the compiler be cc.sh, which wraps MSVC++, so all configure tests
+regarding the C compiler gets to run the right compiler. A lot of the
+tests are not needed on Windows, but I thought it best to run the
+whole configure anyway. The only configure option you might want to
+supply is `--with-ssl`, which might be needed if you have built your own
+openssl distribution. The Shining Lights distribution should be found
+automatically by configure, if that fails, add a `--with-ssl=<dir>` that
+specifies the root directory of your OpenSSL installation.
+
+`$ ./otp_build boot -a` - This uses the bootstrap directory (shipped
+with the source, `$ERL_TOP/bootstrap`) to build a complete OTP
+system. It first builds an emulator and sets up a minimal OTP system
+under `$ERL_TOP/bootstrap`, then starts to compile the different OTP
+compilers to make the `$ERL_TOP/bootstrap` system potent enough to be
+able to compile all Erlang code in OTP. Then, all Erlang and C code
+under `$ERL_TOP/lib` is built using the bootstrap system, giving a
+complete OTP system (although not installed). When this is done, one
+can run Erlang from within the source tree, just type `$ERL_TOP/bin/erl`
+and you should have a prompt. If you omit the -a flag, you'll get a
+smaller system, that might be useful during development. Now
+exit from Erlang and start making a release of the thing:
+
+`$ ./otp_build release -a` - Builds a commercial release tree from the
+source tree, default is to put it in `$ERL_TOP/release/win32`, you can
+give any directory as parameter (Cygwin style), but it doesn't really matter
+if you're going to build a self extracting installer too. You could of
+course build release to the final directory and then run `./Install.exe`
+standing in the directory where the release was put, that will create
+a fully functional OTP installation. But let's make the nifty
+installer:
+
+`$ ./otp_build installer_win32` - Create the self extracting installer
+executable. The executable `otp_win32_<OTP version>.exe` will be placed
+in the top directory of the release created in the previous step. If
+no release directory is specified, the release is expected to have
+been built to `$ERL_TOP/release/win32`, which also will be the place
+where the installer executable will be placed. If you specified some
+other directory for the release (i.e.
+`./otp_build release -a /tmp/erl_release`), you're expected to give the
+same parameter here, (i.e. `./otp_build installer_win32 /tmp/erl_release`).
+You need to have a full NSIS installation and `makensis.exe` in your
+path for this to work of course. Once you have created the installer,
+you can run it to install Erlang/OTP in the regular way, just run the
+executable and follow the steps in the installation wizard. To get all
+default settings in the installation without any questions asked, you
+run the executable with the parameter `/S` (capital S). like in:
+
+ $ cd $ERL_TOP
+ $ release/win32/otp_win32_R13B04 /S
+ ...
+
+and after a while Erlang will have been installed in
+`C:\Program Files\erl5.7.5`, with shortcuts in the menu etc.
+
+*NOTE* Beginning with R9C, the Windows installer does *not* add Erlang
+to the system wide path. If one wants to have Erlang in the path, one
+has to add it by hand.
+
+The necessary setup of an Erlang installation is actually done by the
+program `Install.exe`, which resides in the release top. That program
+creates `.ini`-files and copies the correct boot scripts. If one has
+the correct directory tree (like after a `./otp_build release -a`), only
+the running of Install.exe is necessary to get a fully functional
+OTP. What the self extracting installer adds is (of course) the
+possibility to distribute the binary easily, together with adding
+shortcuts to the Windows start menu. There is also some adding of
+entries in the registry, to associate `.erl` and `.beam` files with Erlang
+and get nifty icons, but that's not something you'll really need to
+run Erlang. The registry is also used to store uninstall information,
+but if one has not used the self extracting installer, one cannot
+(need not) do any uninstall, one just scratches the release directory
+and everything is gone. Erlang/OTP does not *need* to put anything
+in the Windows registry at all, and does not if you don't use the self
+extracting installer. In other words the installer is pure cosmetics.
+
+
+Development
+-----------
+
+Once the system is built, you might want to change it. Having a test
+release in some nice directory might be useful, but you also can run
+Erlang from within the source tree. The target `local_setup`, makes
+the program `$ERL_TOP/bin/erl.exe` usable and it also uses all the OTP
+libraries in the source tree.
+
+If you hack the emulator, you can then build the emulator executable
+by standing in `$ERL_TOP/erts/emulator` and do a simple
+
+ $ make opt
+
+Note that you need to have run ``(cd $ERL_TOP && eval `./otp_build env_win32`)``
+in the particular shell before building anything on Windows. After
+doing a make opt you can test your result by running `$ERL_TOP/bin/erl`.
+If you want to copy the result to a release directory (say
+`/tmp/erl_release`), you do this (still in `$ERL_TOP/erts/emulator`)
+
+ $ make TESTROOT=/tmp/erl_release release
+
+That will copy the emulator executables.
+
+To make a debug build of the emulator, you need to recompile both
+`beam.dll` (the actual runtime system) and `erlexec.dll`. Do like this
+
+ $ cd $ERL_TOP
+ $ rm bin/win32/erlexec.dll
+ $ cd erts/emulator
+ $ make debug
+ $ cd ../etc
+ $ make debug
+
+and sometimes
+
+ $ cd $ERL_TOP
+ $ make local_setup
+
+So now when you run `$ERL_TOP/erl.exe`, you should have a debug compiled
+emulator, which you will see if you do a:
+
+ 1> erlang:system_info(system_version).
+
+in the erlang shell. If the returned string contains `[debug]`, you
+got a debug compiled emulator.
+
+To hack the erlang libraries, you simply do a `make opt` in the
+specific "applications" directory, like:
+
+ $ cd $ERL_TOP/lib/stdlib
+ $ make opt
+
+or even in the source directory...
+
+ $ cd $ERL_TOP/lib/stdlib/src
+ $ make opt
+
+Note that you're expected o have a fresh Erlang in your path when
+doing this, preferably the plain R13B04 you have built in the previous
+steps. You could also add `$ERL_TOP/bootstrap/bin` to your `PATH` before
+rebuilding specific libraries, that would give you a good enough
+Erlang system to compile any OTP erlang code. Setting up the path
+correctly is a little bit tricky, you still need to have
+`$ERL_TOP/erts/etc/win32/cygwin_tools/vc` and
+`$ERL_TOP/erts/etc/win32/cygwin_tools` *before* the actual emulator
+in the path. A typical setting of the path for using the bootstrap
+compiler would be:
+
+ $ export PATH=$ERL_TOP/erts/etc/win32/cygwin_tools/vc:$ERL_TOP/erts/etc/win32/cygwin_tools:$ERL_TOP/bootstrap/bin:$PATH
+
+That should make it possible to rebuild any library without hassle...
+
+If you want to copy a library (an application) newly built, to a
+release area, you do like with the emulator:
+
+ $ cd $ERL_TOP/lib/stdlib
+ $ make TESTROOT=/tmp/erlang_release release
+
+Remember that:
+
+* Windows specific C-code goes in the `$ERL_TOP/erts/emulator/sys/win32`,
+ `$ERL_TOP/erts/emulator/drivers/win32` or `$ERL_TOP/erts/etc/win32`.
+
+* Windows specific erlang code should be used conditionally and the
+ host OS tested in *runtime*, the exactly same beam files should be
+ distributed for every platform! So write code like:
+
+ case os:type() of
+ {win32,_} ->
+ do_windows_specific();
+ Other ->
+ do_fallback_or_exit()
+ end,
+
+That's basically all you need to get going.
+
+Final Words
+-----------
+My hope is that the possibility to build the whole system on Windows
+will open up for free development on this platform too. There are many
+things one might want to do better in the Windows version, like the
+window-style command prompt as well as pure Cygwin porting. Although i
+realize it's a much larger step to start building on Windows (with all
+the software you need) than for instance on Linux, I sincerely hope
+that some of you will make the effort and start submitting Windows
+friendly patches.
+
+The first build system for Erlang using Cygwin on Windows was created
+by Per Bergkvist. I haven't used his build system, but it's rumored to
+be good. The idea to do this came from his work, so credit is well
+deserved.
+
+Of course this would have been completely impossible without the
+excellent Cygwin package. The guys at Cygnus solutions and Redhat
+deserves a huge THANKS! as well as all the other people in the free
+software community who have helped in creating the magnificent
+software that constitutes Cygwin.
+
+Good luck and Happy Hacking,
+Patrik, OTP
+
+Copyright and License
+---------------------
+
+> %CopyrightBegin%
+>
+> Copyright Ericsson AB 2003-2010. All Rights Reserved.
+>
+> The contents of this file are subject to the Erlang Public License,
+> Version 1.1, (the "License"); you may not use this file except in
+> compliance with the License. You should have received a copy of the
+> Erlang Public License along with this software. If not, it can be
+> retrieved online at http://www.erlang.org/.
+>
+> Software distributed under the License is distributed on an "AS IS"
+> basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+> the License for the specific language governing rights and limitations
+> under the License.
+>
+> %CopyrightEnd%
View
661 INSTALL.md
@@ -0,0 +1,661 @@
+Building and Installing Erlang/OTP
+==================================
+
+Please read the whole file before attempting to build and install Erlang/OTP.
+You can find more information about Open Source Erlang/OTP at:
+
+ <http://www.erlang.org/>
+
+The source code for Erlang/OTP can also be found in a Git repository:
+
+ <http://github.com/erlang/otp>
+
+Portability
+-----------
+
+Erlang/OTP should be possible to build from source on any Unix system,
+including Mac OS X. This document describes how to native compile Erlang/OTP
+on Unix. For detailed instructions on how to
+
+* cross compile Erlang/OTP, see the [`$ERL_TOP/INSTALL-CROSS.md`] [1]
+ document.
+
+* build Erlang/OTP on Windows, see the [`$ERL_TOP/INSTALL-WIN32.md`] [2]
+ document.
+
+ Binary releases for Windows can be found at
+ <http://www.erlang.org/download.html>.
+
+However, you are in any case advised to read this document first, since it
+covers building Erlang/OTP in general as well as other important information.
+
+Daily Build and Test
+--------------------
+At Ericsson we have a "Daily Build and Test" that runs on:
+
+* Solaris 8, 9
+ * Sparc32
+ * Sparc64
+* Solaris 10
+ * Sparc32
+ * Sparc64
+ * x86
+* SuSE Linux/GNU 9.4, 10.1
+ * x86
+* SuSE Linux/GNU 10.0, 10.1
+ * x86
+ * x86_64
+* SuSE Linux/GNU 11.0
+ * x86_64
+* Gentoo Linux/GNU 1.12.11.1
+ * x86
+* MontaVista Linux/GNU 4.0.1
+ * PowerPC
+* FreeBSD 7.1
+ * x86
+* Mac OS X 10.4.11 (Tiger), 10.5.8 (Leopard), 10.6.0 (Snow Leopard)
+ * x86
+* Windows XP SP3, 2003, Vista, 7
+ * x86
+
+We also have the following "Daily Cross Builds":
+
+* SuSE Linux/GNU 10.1 x86 -> SuSE Linux/GNU 10.1 x86_64
+* SuSE Linux/GNU 10.1 x86_64 -> Linux/GNU TILEPro64
+
+and the following "Daily Cross Build Tests":
+
+* SuSE Linux/GNU 10.1 x86_64
+
+Versions Known *not* to Work
+----------------------------
+
+* Suse linux 9.1 is shipped with a patched GCC version 3.3.3, having the
+ rpm named `gcc-3.3.3-41`. That version has a serious optimization bug
+ that makes it unusable for building the Erlang emulator. Please
+ upgrade GCC to a newer version before building on Suse 9.1. Suse Linux
+ Enterprise edition 9 (SLES9) has `gcc-3.3.3-43` and is not affected.
+
+* `gcc-4.3.0` has a serious optimizer bug. It produces an Erlang emulator
+ that will crash immediately. The bug is supposed to be fixed in
+ `gcc-4.3.1`.
+
+* FreeBSD had a bug which caused `kqueue`/`poll`/`select` to fail to detect
+ that a `writev()` on a pipe has been made. This bug should have been fixed
+ in FreeBSD 6.3 and FreeBSD 7.0. NetBSD and DragonFlyBSD probably have or
+ have had the same bug. More information can be found at:
+
+ * <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/sys_pipe.c>
+ * <http://lists.freebsd.org/pipermail/freebsd-arch/2007-September/006790.html>
+
+* `getcwd()` on Solaris 9 can cause an emulator crash. If you have
+ async-threads enabled you can increase the stack size of the
+ async-threads as a temporary workaround. See the `+a` command-line
+ argument in the documentation of `erl(1)`. Without async-threads the
+ emulator is not as vulnerable to this bug, but if you hit it without
+ async-threads the only workaround available is to enable async-threads
+ and increase the stack size of the async-threads. Sun has however
+ released patches that fixes the issue:
+
+ > Problem Description: 6448300 large mnttab can cause stack overrun
+ > during Solaris 9 getcwd
+
+ More information can be found at:
+
+ * <http://sunsolve.sun.com/search/document.do?assetkey=1-21-112874-40-1&searchclause=6448300>
+ * <http://sunsolve.sun.com/search/document.do?assetkey=1-21-114432-29-1&searchclause=6448300>
+
+Required Utilities
+------------------
+
+These are the tools you will need in order to unpack and build Erlang/OTP.
+
+### Unpacking ###
+
+* GNU unzip, or a modern uncompress.
+* A TAR program that understands the GNU TAR format for long filenames
+ (such as GNU TAR).
+
+### Building ###
+
+* GNU make
+* GNU C compiler
+* Perl 5
+* GNU m4 -- If hipe (native code) support is enabled.
+* ncurses (or termcap or termlib) -- The development headers and libraries
+ are needed, often known as ncurses-devel. (Use --without-termcap to build
+ without any of these libraries. Only the old shell (without any line
+ editing) can be used.)
+* OpenSSL -- Optional, but needed for building the Erlang/OTP applications
+ `ssl` and `crypto`. You need the "development package" of OpenSSL, i.e.
+ including the header files. For building the application `ssl` the OpenSSL
+ binary command program `openssl` is also needed.
+ At least version 0.9.7 of OpenSSL is required.
+* Sun Java jdk-1.5.0 or higher -- Optional but needed for building the
+ Erlang/OTP application `jinterface` and parts of `ic` and `orber`. We
+ have also tested IBM's JDK 1.5.0.
+* X Windows -- Optional, but development headers and libraries are needed
+ to build the Erlang/OTP application `gs` on Unix/Linux.
+* `sed` -- There seem to be some problems with some of the `sed` version on
+ Solaris. Make sure `/bin/sed` or `/usr/bin/sed` is used on the Solaris
+ platform.
+* Flex -- Optional, headers and libraries are needed to build the flex
+ scanner for the `megaco` application on Unix/Linux.
+
+If you are building in a Git working directory you also have to have a GNU
+`autoconf` of at least version 2.59. Autoconf is however not needed if you
+build an unmodified version of the released source.
+
+### Installing ###
+
+* An `install` program that can take multiple file names.
+
+How to Build and Install Erlang/OTP
+-----------------------------------
+
+The following instructions are for building using the source tar ball.
+
+The variable `$ERL_TOP` will be mentioned a lot of times. It refers to
+the top directory in the source tree. More information about `$ERL_TOP`
+can be found in the "`make` and `$ERL_TOP`" section below. If you are
+building in git you probably want to take a look at the "Building in Git"
+section below before proceeding.
+
+### Unpacking ###
+
+Step 1: Start by unpacking the Erlang/OTP distribution file with your GNU
+compatible TAR program.
+
+ $ gunzip -c otp_src_R13B04.tar.gz | tar xf -
+ $ zcat otp_src_R13B04.tar.gz | tar xf -
+
+
+Step 2: Now cd into the base directory (`$ERL_TOP`).
+
+ $ cd otp_src_R13B04
+
+### Configuring ###
+
+Step 3: On some platforms Perl may behave strangely if certain locales are
+set, so optionally you may need to set the LANG variable:
+
+ # Bourne shell
+ $ LANG=C; export LANG
+
+or
+
+ # C-Shell
+ $ setenv LANG C
+
+Step 4: Run the following commands to configure the build:
+
+ $ ./configure [ options ]
+
+By default, Erlang/OTP will be installed in `/usr/local/{bin,lib/erlang,man/man1}`.
+To instead install in `<BaseDir>/{bin,lib/erlang,man/man1}`, use the
+`--prefix=<BaseDir>` option.
+
+If you upgraded the source with some patch you may need to clean up
+from previous builds before the new build. Do a `make clean`; see
+"Caveats" below.
+
+### Building ###
+
+Step 5: Build the Erlang/OTP package.
+
+ $ make
+
+### Installing ###
+
+Step 6: Install then Erlang/OTP package
+
+ $ make install
+
+### A Closer Look at the individual Steps ###
+
+Let us go through them in some detail.
+
+#### Configuring ####
+
+Step 4 runs a configuration script created by the GNU autoconf utility, which
+checks for system specific features and then creates a number of makefiles.
+
+The configure script allows you to customize a number of parameters;
+type `./configure --help` or `./configure --help=recursive` for details.
+`./configure --help=recursive` will give help for all `configure` scripts in
+all applications.
+
+One of the things you can specify is where Erlang/OTP should be installed: by
+default Erlang/OTP will be installed in `/usr/local/{bin,lib/erlang,man/man1}`;
+to keep the same structure but install in a different place, `<Dir>` say,
+use the `--prefix` argument like this: `./configure --prefix=<Dir>`.
+
+Some of the available `configure` options are:
+
+ * `--prefix=PATH`: Specify installation prefix.
+ * `--{enable,disable}-threads`: Thread support (enabled by default if
+ possible)
+ * `--{enable,disable}-smp-support`: SMP support (enabled by default if
+ possible)
+ * `--{enable,disable}-kernel-poll`: Kernel poll support (enabled by default
+ if possible)
+ * `--{enable,disable}-hipe`: HiPE support (enabled by default on supported
+ platforms)
+ * `--disable-erlang-mandir`: No private Erlang mandir, i.e., the common
+ mandir under `--prefix`, or `--mandir` will be used
+ * `--enable-darwin-universal`: Build universal binaries on darwin i386.
+ * `--enable-darwin-64bit`: Build 64bit binaries on darwin
+ * `--enable-m64-build`: Build 64bit binaries using the -m64 flag to (g)cc
+ * `--enable-m32-build`: Build 32bit binaries using the -m32 flag to (g)cc
+ * `--{with,without}-termcap`: termcap (without implies that only the old
+ Erlang shell can be used)
+ * `--with-javac=JAVAC`: Specify Java compiler to use
+ * `--{with,without}-javac`: Java compiler (without implies that the
+ `jinterface` application won't be built).
+ * `--{enable,disable}-dynamic-ssl-lib`: Dynamic OpenSSL libraries
+ * `--{enable,disable}-shared-zlib`: Shared zlib library
+ * `--with-ssl=PATH`: Specify location of OpenSSL include and lib
+ * `--{with,without}-ssl`: OpenSSL (without implies that the `crypto`, `ssh`,
+ and `ssl` won't be built)
+
+If you or your system has special requirements please read the
+Makefile for additional configuration information.
+
+#### Building ####
+
+Step 5 builds the Erlang/OTP system. On a fast computer, this will take about
+5 minutes. After completion of this step, you should have a working
+Erlang/OTP system which you can try by typing `bin/erl`. This should start
+up Erlang/OTP and give you a prompt.
+
+#### Installing ####
+
+Step 6 is optional. It installs Erlang/OTP at a standardized location (if you
+change your mind about where you wish to install you can rerun step 4,
+without having to do step 5 again).
+
+##### Alternative Installation Procedures #####
+
+* Staged install using [`DESTDIR`] [3]. You can perform the install
+ phase in a temporary directory and later move the installation into
+ its correct location by use of the `DESTDIR` variable:
+
+ $ make DESTDIR=<tmp install dir> install
+
+ The installation will be created in a location prefixed by `$DESTDIR`.
+ It can, however, not be run from there. It needs to be moved into the
+ correct location before it can be run. If `DESTDIR` have not been set
+ but `INSTALL_PREFIX` has been set, `DESTDIR` will be set to
+ `INSTALL_PREFIX`. Note that `INSTALL_PREFIX` in pre R13B04 was buggy
+ and behaved as `EXTRA_PREFIX` (see below). There are lots of areas of
+ use for an installation procedure using `DESTDIR`, e.g. when creating
+ a package, cross compiling, etc. Here is an example where the
+ installation should be located under `/opt/local`:
+
+ $ ./configure --prefix=/opt/local
+ $ make
+ $ make DESTDIR=/tmp/erlang-build install
+ $ cd /tmp/erlang-build/opt/local
+ $ # gnu-tar is used in this example
+ $ tar -zcf /home/me/my-erlang-build.tgz *
+ $ su -
+ Password: *****
+ $ cd /opt/local
+ $ tar -zxf /home/me/my-erlang-build.tgz
+
+* Install using the `release` target. Instead of doing `make install` you
+ can create the installation in whatever directory you like using the
+ `release` target and run the `Install` script yourself. `RELEASE_ROOT`
+ is used for specifying the directory where the installation should be
+ created. This is what by default ends up under `/usr/local/lib/erlang`
+ if you do the install using `make install`. All installation paths
+ provided in the `configure` phase are ignored, as well as `DESTDIR`,
+ and `INSTALL_PREFIX`. If you want links from a specific `bin` directory
+ to the installation you have to set those up yourself. An example where
+ Erlang/OTP should be located at `/home/me/OTP`:
+
+ $ ./configure
+ $ make
+ $ make RELEASE_ROOT=/home/me/OTP release
+ $ cd /home/me/OTP
+ $ ./Install -minimal /home/me/OTP
+ $ mkdir -p /home/me/bin
+ $ cd /home/me/bin
+ $ ln -s /home/me/OTP/bin/erl erl
+ $ ln -s /home/me/OTP/bin/erlc erlc
+ $ ln -s /home/me/OTP/bin/escript escript
+ ...
+
+ The `Install` script should currently be invoked as follows in the
+ directory where it resides (the top directory):
+
+ $ ./Install [-cross] [-minimal|-sasl] <ERL_ROOT>
+
+ where:
+
+ * `-minimal` Creates an installation that starts up a minimal amount
+ of applications, i.e., only `kernel` and `stdlib` are started. The
+ minimal system is normally enough, and is what `make install` uses.
+ * `-sasl` Creates an installation that also starts up the `sasl`
+ application.
+ * `-cross` For cross compilation. Informs the install script that it
+ is run on the build machine.
+ * `<ERL_ROOT>` - The absolute path to the Erlang installation to use
+ at run time. This is often the same as the current working directory,
+ but does not have to be. It can follow any other path through the
+ file system to the same directory.
+
+ If neither `-minimal`, nor `-sasl` is passed as argument you will be
+ prompted.
+
+* Test install using `EXTRA_PREFIX`. The content of the `EXTRA_PREFIX`
+ variable will prefix all installation paths when doing `make install`.
+ Note that `EXTRA_PREFIX` is similar to `DESTDIR`, but it does *not* have
+ the same effect as `DESTDIR`. The installation can and have to be run
+ from the location specified by `EXTRA_PREFIX`. That is, it can be useful
+ if you want to try the system out, running test suites, etc, before doing
+ the real install without `EXTRA_PREFIX`.
+
+### Symbolic Links in `--bindir` ###
+
+When doing `make install` and the default installation prefix is used,
+relative symbolic links will be created from `/usr/local/bin` to all public
+Erlang/OTP executables in `/usr/local/lib/erlang/bin`. The installation phase
+will try to create relative symbolic links as long as `--bindir` and the
+Erlang bin directory, located under `--libdir`, both have `--exec-prefix` as
+prefix. Where `--exec-prefix` defaults to `--prefix`. `--prefix`,
+`--exec-prefix`, `--bindir`, and `--libdir` are all arguments that can be
+passed to `configure`. One can force relative, or absolute links by passing
+`BINDIR_SYMLINKS=relative|absolute` as arguments to `make` during the install
+phase. Note that such a request might cause a failure if the request cannot
+be satisfied.
+
+### Building in Git ###
+
+When building in a Git working directory you also have to have a GNU `autoconf`
+of at least version 2.59 on your system. This since you need to generate the
+`configure` scripts before you can start building.
+
+The `configure` scripts are generated by invoking `./otp_build autoconf` in
+the `$ERL_TOP` directory. The `configure` scripts also have to be regenerated
+when a `configure.in` or `aclocal.m4` file has been modified. Note that when
+checking out a branch a `configure.in` or `aclocal.m4` file may change
+content, and you may therefore have to regenerate the `configure` scripts
+when checking out a branch. Regenerated `configure` scripts imply that you
+have to run `configure` and build again.
+
+Note that running `./otp_build autoconf` is **not** needed when building an
+unmodified version the released source.
+
+Other useful information can be found at our github wiki:
+<http://wiki.github.com/erlang/otp>
+
+Pre-built Source Tree
+---------------------
+
+The source tree is delivered with a lot of platform independent
+build results already pre-built. If you want to remove these pre-built
+files, invoke `./otp_build remove_prebuilt_files` from the `$ERL_TOP`
+directory. After you have done this, you can build exactly the same way
+as before, but the build process will take a much longer time.
+
+*NOTE*: Doing `make clean` in an arbitrary directory of the source tree,
+may remove files needed for bootstrapping the build. Doing
+`./otp_build save_bootstrap` from the `$ERL_TOP` directory before
+doing `make clean` will ensure that it will be possible to build after
+doing `make clean`. `./otp_build save_bootstrap` will be invoked
+automatically when `make` is invoked from `$ERL_TOP` with either the
+`clean` target, or the default target. It is also automatically invoked
+if `./otp_build remove_prebuilt_files` is invoked.
+
+`make` and `$ERL_TOP`
+---------------------
+
+All the makefiles in the entire directory tree use the environment
+variable `ERL_TOP` to find the absolute path of the installation. The
+`configure` script will figure this out and set it in the top level
+Makefile (which, when building, it will pass on). However, when
+developing it is sometimes convenient to be able to run make in a
+subdirectory. To do this you must set the `ERL_TOP` variable
+before you run make.
+
+For example, assume your GNU make program is called `make` and you
+want to rebuild the application `STDLIB`, then you could do:
+
+ $ cd lib/stdlib; env ERL_TOP=<Dir> make
+
+where `<Dir>` would be what you find `ERL_TOP` is set to in the top level
+Makefile.
+
+Support for SMP (Symmetric Multi Processing)
+--------------------------------------------
+
+An emulator with SMP support will be built by default on most platforms
+if a usable POSIX thread library or native Windows threads is found.
+
+You can force building of an SMP emulator, by using
+`./configure --enable-smp-support`. However, if configure does not
+automatically enable SMP support, the build is very likely to fail.
+
+Use `./configure --disable-smp-support` if you for some reason do not
+want to have the emulator with SMP support built.
+
+If SMP support is enabled, support for threaded I/O will also be turned on
+(also in the emulator without SMP support).
+
+The `erl` command will automatically start the SMP emulator if the
+computer has more than one logical processor. You can force a start
+of the emulator with SMP support by passing `-smp enable` as
+command line arguments to erl, and you can force a start of the
+emulator without SMP support by passing `-smp disable`.
+
+How to install the Erlang/OTP documentation
+-------------------------------------------
+
+For some graphical tools to find the on-line help you have to install
+the HTML documentation on top of the installed OTP applications, i.e.
+
+ $ cd <PrefixDir>/lib/erlang
+ $ gunzip -c otp_html_R<XY>B-<Z>.tar.gz | tar xf -
+
+For `erl -man <page>` to work the Unix manual pages have to be
+installed in the same way, i.e.
+
+ $ cd <PrefixDir>/lib/erlang
+ $gunzip -c otp_man_R<XY>B-<Z>.tar.gz | tar xf -
+
+
+GS (Graphic System)
+-------------------
+
+GS now Tcl/Tk 8.4. It will be searched for when starting GS.
+
+Using HiPE
+----------
+
+HiPE supports the following system configurations:
+
+* x86: All 32-bit and 64-bit mode processors should work.
+
+ * Linux: Fedora Core is supported. Both 32-bit and 64-bit modes are
+ supported.
+
+ NPTL glibc is strongly preferred, or a LinuxThreads
+ glibc configured for "floating stacks". Old non-floating
+ stacks glibcs have a fundamental problem that makes HiPE
+ support and threads support mutually exclusive.
+
+ * Solaris: Solaris 10 (32-bit and 64-bit) and 9 (32-bit) are supported.
+ The build requires a version of the GNU C compiler (gcc)
+ that has been configured to use the GNU assembler (gas).
+ Sun's x86 assembler is emphatically **not** supported.
+
+ * FreeBSD: FreeBSD 6.1 and 6.2 in 32-bit and 64-bit modes should work.
+
+ * MacOSX/Darwin: Darwin 9.8.0 in 32-bit mode should work.
+
+* PowerPC: All 32-bit 6xx/7xx(G3)/74xx(G4) processors should work. 32-bit
+ mode on 970 (G5) and POWER5 processors should work.
+
+ * Linux (Yellow Dog) and Mac OSX 10.4 are supported.
+
+* SPARC: All UltraSPARC processors running 32-bit user code should work.
+
+ * Solaris 9 is supported. The build requires a `gcc` that has been
+ configured to use Sun's assembler and linker. Using the GNU assembler
+ but Sun's linker has been known to cause problems.
+
+ * Linux (Aurora) is supported.
+
+* ARM: ARMv5TE (i.e. XScale) processors should work. Both big-endian and
+ little-endian modes are supported.
+
+ * Linux is supported.
+
+HiPE is automatically enabled on the following systems:
+
+* x86 in 32-bit mode: Linux, Solaris, FreeBSD
+* x86 in 64-bit mode: Linux, Solaris, FreeBSD
+* PowerPC: Linux, MacOSX
+* SPARC: Linux
+* ARM: Linux
+
+On other supported systems you need to `./configure --enable-hipe`.
+
+If you are running on a platform supporting HiPE and if you have not disabled
+HiPE, you can compile a module into native code like this from the Erlang
+shell:
+
+ 1> c(Module, native).
+
+or
+
+ 1> c(Module, [native|OtherOptions]).
+
+Using the erlc program, write like this:
+
+ $ erlc +native Module.erl
+
+The native code will be placed into the beam file and automatically loaded
+when the beam file is loaded.
+
+To add hipe options, write like this from the Erlang shell:
+
+ 1> c(Module, [native,{hipe,HipeOptions}|MoreOptions]).
+
+Use hipe:help_options/0 to print out the available options.
+
+ 1> hipe:help_options().
+
+Mac OS X (Darwin)
+-----------------
+
+We test Mac OS X 10.4.11 (Tiger) and Mac OS X 10.5.x (Leopard) in our daily
+builds (but only on Intel processors).
+
+Make sure that the command `hostname` returns a valid fully qualified host
+name (this is configured in `/etc/hostconfig`).
+
+If you develop linked-in drivers (shared library) you need to link using
+`gcc` and the flags `-bundle -flat_namespace -undefined suppress`. You also
+include `-fno-common` in `CFLAGS` when compiling. Use `.so` as the library
+suffix.
+
+Universal 32bit binaries can be built on an Intel Mac using the
+`--enable-darwin-universal` configure option. There still may occur
+problems with certain applications using this option, but the base
+system should run smoothly.
+
+When building universal binaries on a PowerPC Mac (at least on Tiger),
+you must point out a suitable SDK that contains universal binaries.
+For instance, to build universal binaries for Tiger (10.4):
+
+ $ CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk" \
+ LDFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk" \
+ ./configure --enable-darwin-universal
+
+Also, if you run Leopard, but want to build for Tiger, you must do by
+setting the `MACOSX_DEPLOYMENT_TARGET` environmental variable.
+
+ $ export MACOSX_DEPLOYMENT_TARGET=10.4
+
+Experimental support for 64bit x86 darwin binaries can be enabled
+using the `--enable-darwin-64bit` configure flag. The 64bit binaries are
+best built and run on Leopard, but most of the system also works on
+Tiger (Tiger's 64bit libraries are, however, limited; therefore e.g. `odbc`,
+`crypto`, `ssl` etc. are not supported in Tiger). 64bit PPC binaries are not
+supported and we have no plans to add such support (no machines to
+test on).
+
+Universal binaries and 64bit binaries are mutually exclusive options.
+
+How to Build a Debug Enabled Erlang RunTime System
+--------------------------------------------------
+
+After completing all the normal building steps described above a debug
+enabled runtime system can be built. To do this you have to change
+directory to `$ERL_TOP/erts/emulator`.
+
+In this directory execute:
+
+ $ make debug FLAVOR=$FLAVOR
+
+where `$FLAVOR` is either `plain` or `smp`. The flavor options will
+produce a beam.debug and beam.smp.debug executable respectively. The
+files are installed along side with the normal (opt) versions `beam.smp`
+and `beam`.
+
+To start the debug enabled runtime system execute:
+
+ $ $ERL_TOP/bin/cerl -debug
+
+The debug enabled runtime system features lock violation checking,
+assert checking and various sanity checks to help a developer ensure
+correctness. Some of these features can be enabled on a normal beam
+using appropriate configure options.
+
+There are other types of runtime systems that can be built as well
+using the similar steps just described.
+
+ $ make $TYPE FLAVOR=$FLAVOR
+
+where `$TYPE` is `opt`, `gcov`, `gprof`, `debug`, `valgrind`, or `lcnt`.
+These different beam types are useful for debugging and profiling
+purposes.
+
+Authors
+-------
+Authors are mostly listed in the application's `AUTHORS` files,
+that is `$ERL_TOP/lib/*/AUTHORS` and `$ERL_TOP/erts/AUTHORS`,
+not in the individual source files.
+
+Copyright and License
+---------------------
+
+> %CopyrightBegin%
+>
+> Copyright Ericsson AB 1998-2010. All Rights Reserved.
+>
+> The contents of this file are subject to the Erlang Public License,
+> Version 1.1, (the "License"); you may not use this file except in
+> compliance with the License. You should have received a copy of the
+> Erlang Public License along with this software. If not, it can be
+> retrieved online at http://www.erlang.org/.
+>
+> Software distributed under the License is distributed on an "AS IS"
+> basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+> the License for the specific language governing rights and limitations
+> under the License.
+>
+> %CopyrightEnd%
+
+More Information
+----------------
+
+More information can be found at <http://www.erlang.org>.
+
+
+
+ [1]: INSTALL-CROSS.html "$ERL_TOP/INSTALL-CROSS.md"
+ [2]: INSTALL-WIN32.html "$ERL_TOP/INSTALL-WIN32.md"
+ [3]: http://www.gnu.org/prep/standards/html_node/DESTDIR.html "DESTDIR"
View
55 Makefile.in
@@ -392,16 +392,55 @@ endif
# ---------------------------------------------------------------
# Target only used when building commercial ERTS patches
# ---------------------------------------------------------------
-release_docs docs:
+release_docs docs: html_readmes
ifeq ($(OTP_SMALL_BUILD),true)
- cd $(ERL_TOP)/lib && $(MAKE) TESTROOT=$(RELEASE_ROOT) $@
+ cd $(ERL_TOP)/lib && \
+ ERL_TOP=$(ERL_TOP) $(MAKE) TESTROOT=$(RELEASE_ROOT) $@
else
- cd $(ERL_TOP)/lib && $(MAKE) BUILD_ALL=1 TESTROOT=$(RELEASE_ROOT) $@
- cd $(ERL_TOP)/lib/dialyzer && $(MAKE) BUILD_ALL=1 TESTROOT=$(RELEASE_ROOT) $@
+ cd $(ERL_TOP)/lib && \
+ ERL_TOP=$(ERL_TOP) $(MAKE) BUILD_ALL=1 TESTROOT=$(RELEASE_ROOT) $@
+ cd $(ERL_TOP)/lib/dialyzer && \
+ ERL_TOP=$(ERL_TOP) $(MAKE) BUILD_ALL=1 TESTROOT=$(RELEASE_ROOT) $@
endif
- cd $(ERL_TOP)/erts && $(MAKE) BUILD_ALL=1 TESTROOT=$(RELEASE_ROOT) $@
- cd $(ERL_TOP)/system/doc && $(MAKE) TESTROOT=$(RELEASE_ROOT) $@
-
+ cd $(ERL_TOP)/erts && \
+ ERL_TOP=$(ERL_TOP) $(MAKE) BUILD_ALL=1 TESTROOT=$(RELEASE_ROOT) $@
+ cd $(ERL_TOP)/system/doc && \
+ ERL_TOP=$(ERL_TOP) $(MAKE) TESTROOT=$(RELEASE_ROOT) $@
+
+.PHONY: html_readmes clean_html_readmes
+
+HTML_READMES = INSTALL.html INSTALL-WIN32.html INSTALL-CROSS.html
+
+html_readmes: $(HTML_READMES)
+
+clean_html_readmes:
+ rm -f $(HTML_READMES)
+
+%.html: %.md
+ echo "<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\">" > $@
+ echo "<html xmlns:fn=\"http://www.w3.org/2005/02/xpath-functions\"><head>" >> $@
+ echo "<meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">" >> $@
+ echo "<style type=\"text/css\">" >> $@
+ echo "body {" >> $@
+ echo " margin: 4em 4em 4em 4em;" >> $@
+ echo " background: white;" >> $@
+ echo " font-family: Verdana, Arial, Helvetica, sans-serif;" >> $@
+ echo "}" >> $@
+ echo "code { font-family: courier;font-weight: normal}" >> $@
+ echo "a:link { color: blue; text-decoration: none }" >> $@
+ echo "a:active { color: blue; text-decoration: none }" >> $@
+ echo "a:visited { color: blue; text-decoration: none }" >> $@
+ echo "</style><title>" >> $@
+ cat $< | sed -n "s/[ ]*\([^ ].*[^ ]\)[ ]*/\1/p;/[ ]*[^ ][ ]*/q" >> $@
+ echo "</title></head><body>" >> $@
+ifneq ($(MD2HTML),)
+ $(MD2HTML) $< >> $@
+else
+ echo "<pre>" >> $@
+ cat $< | sed "s|\&|\&amp\;|g;s|\"|\&quot\;|g;s|<|\&lt\;|g;s|>|\&gt\;|g" >> $@
+ echo "</pre>" >> $@
+endif
+ echo "</body></html>" >> $@
# ----------------------------------------------------------------------
ERLANG_EARS=$(BOOTSTRAP_ROOT)/bootstrap/erts
@@ -988,7 +1027,7 @@ $(IBIN_DIR):
# Clean targets
#
-clean: check_recreate_primary_bootstrap
+clean: check_recreate_primary_bootstrap clean_html_readmes
rm -f *~ *.bak config.log config.status prebuilt.files ibin/*
find . -type f -name SKIP -print | xargs $(RM)
cd erts && ERL_TOP=$(ERL_TOP) $(MAKE) clean
View
562 README
@@ -1,562 +0,0 @@
-===========================================================================
- OpenSource Erlang/OTP
-===========================================================================
-
-Please read the whole file before attempting to build and install Erlang.
-You can find more information about Open Source Erlang at:
-
- http://www.erlang.org/
-
-The source code for Erlang/OTP can also be found in a Git repository:
-
- http://github.com/erlang/otp
-
-%CopyrightBegin%
-
-Copyright Ericsson AB 1998-2010. All Rights Reserved.
-
-The contents of this file are subject to the Erlang Public License,
-Version 1.1, (the "License"); you may not use this file except in
-compliance with the License. You should have received a copy of the
-Erlang Public License along with this software. If not, it can be
-retrieved online at http://www.erlang.org/.
-
-Software distributed under the License is distributed on an "AS IS"
-basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
-the License for the specific language governing rights and limitations
-under the License.
-
-%CopyrightEnd%
-
-Portability
------------
-
-Erlang/OTP should be possible to build from source on any Unix
-system, including Mac OS X.
-
-Instructions for building from source on Windows are in the file README.win32.
-Binary releases for Windows can be found at http://www.erlang.org/
-
-At Ericsson we have a "Daily Build and Test" that runs on:
-
- Operating system Versions
- -----------------------------------------------------------
- Solaris/Sparc32 8, 9, 10
- Solaris/Sparc64 10
- Solaris/x86 10
- Linux/Suse x86 9.4, 10.1
- Linux/Suse x86_64 10.0, 10.1, 11.0
- FreeBSD x86 7.1
- Mac OS X/Intel 10.4.11 (Tiger), 10.5.8 (Leopard)
- Windows XP SP3, 2003, Vista
-
-We have also done some testing on Mac OS 10.6.0 (Snow Leopard).
-
-Versions known *not* to work
--------------------------------------
-
-Suse linux 9.1 is shipped with a patched GCC version 3.3.3, having the
-rpm named gcc-3.3.3-41. That version has a serious optimization bug
-that makes it unusable for building the Erlang emulator. Please
-upgrade GCC to a newer version before building on Suse 9.1. Suse Linux
-Enterprise edition 9 (SLES9) has gcc-3.3.3-43 and is not affected.
-
-gcc-4.3.0 has a serious optimizer bug. It produces an Erlang emulator
-that will crash immediately. The bug is supposed to be fixed in gcc-4.3.1.
-
-FreeBSD had a bug which caused kqueue/poll/select to fail to detect
-that a writev() on a pipe has been made. This bug should have been fixed
-in FreeBSD 6.3 and FreeBSD 7.0. NetBSD and DragonFlyBSD probably have or
-have had the same bug. More information can be found at:
- * http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/sys_pipe.c
- * http://lists.freebsd.org/pipermail/freebsd-arch/2007-September/006790.html
-
-getcwd() on Solaris 9 can cause an emulator crash. If you have async-threads
-enabled you can increase the stack size of the async-threads as a temporary
-workaround. See the +a command-line argument in the documentation of erl(1).
-Without async-threads the emulator isn't as vulnerable to this bug, but if
-you hit it without async-threads the only workaround available is to enable
-async-threads and increase the stack size of the async-threads. Sun has
-however released patches that fixes the issue:
-
-Problem Description: 6448300 large mnttab can cause stack overrun during
-Solaris 9 getcwd
-
-More information can be found at:
- * http://sunsolve.sun.com/search/document.do?assetkey=1-21-112874-40-1&searchclause=6448300
- * http://sunsolve.sun.com/search/document.do?assetkey=1-21-114432-29-1&searchclause=6448300
-
-Required utilities
-------------------
-
-These are the tools you will need in order to unpack and build Erlang/OTP.
-
-Unpacking
-
- * GNU unzip, or a modern uncompress.
- * A TAR program that understands the GNU TAR format for long filenames (such
-as GNU TAR).
-
-Compiling
-
- * GNU make
- * GNU C compiler
- * Perl 5
- * GNU m4 -- If hipe (native code) support is enabled.
- * ncurses (or termcap or termlib) -- The development headers and libraries
- are needed, often known as ncurses-devel. (Use --without-termcap to build
- without any of these libraries. Only the old shell (without any line
- editing) can be used.)
- * OpenSSL -- Optional, but needed for building the Erlang/OTP applications
- 'ssl' and 'crypto'. You need the "development package" of OpenSSL, i.e.
- including the header files. For building the application 'ssl' the OpenSSL
- binary command program 'openssl' is also needed.
- At least version 0.9.7 of OpenSSL is required.
- * Sun Java jdk-1.5.0 or higher -- Optional but needed for building the
- Erlang/OTP application 'jinterface' and parts of 'ic' and 'orber'. We
- have also tested IBM's JDK 1.5.0.
- * X Windows -- Optional, but development headers and libraries are needed
- to build the Erlang/OTP application 'gs' on Unix/Linux.
- * sed -- There seem to be some problems with some of the 'sed' version on
- Solaris. Make sure "/bin/sed" or "/usr/bin/sed" is used on the Solaris
- platform.
- * Flex -- Optional, headers and libraries are needed to build the flex
- scanner for the megaco application on Unix/Linux.
-
-Installing
-
- * An 'install' program that can take multiple file names.
-
-How to build and install Erlang/OTP
------------------------------------
-
-If you are building in a Git repository, see
-
- http://wiki.github.com/erlang/otp
-
-The following instructions are for building using the source tar ball.
-
-Step 1: Start by unpacking the Erlang/OTP distribution file with your GNU
-compatible TAR program.
-
- $ gunzip -c otp_src_R13B03.tar.gz | tar xf -
- $ zcat otp_src_R13B03.tar.gz | tar xf -
-
-Step 2: Now cd into the base directory.
-
- $ cd otp_src_R13B03
-
-Step 3: On some platforms Perl may behave strangely if certain locales are
-set, so optionally you may need to set the LANG variable:
-
- # Bourne shell
- $ LANG=C; export LANG
-or
- # C-Shell
- $ setenv LANG C
-
-Step 4: Run the following commands to configure the build:
-
- $ ./configure [ options ]
-
-By default, Erlang/OTP will be installed in /usr/local/{bin,lib/erlang,man/man1}.
-To instead install in <BaseDir>/{bin,lib/erlang,man/man1}, use the --prefix=<BaseDir>
-option.
-
-If you upgraded the source with some patch you may need to clean up
-from previous builds before the new build. Do a "make clean"; see
-"Caveats" below.
-
-Step 5: Build the Erlang/OTP package.
-
- $ make
-
-Step 6: Install then Erlang/OTP package
-
- $ make install
-
-Let's go through them in some detail:
-
-Step 4 runs a configuration script created by the GNU autoconf utility, which
-checks for system specific features and then creates a number of makefiles.
-
-The configure script allows you to customize a number of parameters;
-type "./configure --help" for details.
-
-One of the things you can specify is where Erlang/OTP should be installed: by
-default Erlang/OTP will be installed in /usr/local/{bin,lib/erlang,man/man1};
-to keep the same structure but install in a different place, <Dir> say,
-use the --prefix argument like this:
-"./configure --prefix=<Dir>".
-
-This step will also configure any additional libraries unpacked in step 3
-(if you didn't add any of the extra libraries configure will issue a warning
-saying that there is no configuration information in lib; this warning can
-safely be ignored).
-
-You can also specify where the OpenSSL include and library files are
-located, or alternatively disable the use of SSL and Crypto.
-(The details can be found by typing './configure --help'.)
-
-Other options are:
-
- --enable-smp-support See the next section.
-
- --disable-smp-support See the next section.
-
- --disable-threads Disable support for threaded I/O;
- this option also disables building of the SMP
- emulator. (See the next section.)
-
- --enable-threads Enable support for threaded I/O.
- (This is the default if SMP support is enabled.
- See the next section.)
-
- --disable-hipe Disable HiPE (High-Performance Erlang).
- HiPE will automatically be enabled on supported
- platforms.
-
-Step 5 builds the Erlang/OTP system. On a fast computer, this will take about
-5 minutes. After completion of this step, you should have a working
-Erlang/OTP system which you can try by typing "bin/erl". This should start
-up Erlang/OTP and give you a prompt.
-
-Step 6 is optional. It installs Erlang/OTP at a standardized location (if you
-change your mind about where you wish to install you can rerun step 4,
-without having to do step 5 again).
-
-Alternative installation procedures:
-* Staged install using DESTDIR. You can perform the install phase in a
- temporary directory and later move the installation into its correct location
- by use of the DESTDIR variable: 'make DESTDIR=<tmp install dir> install'
- The installation will be created in a location prefixed by $DESTDIR. It
- can, however, not be run from there. It needs to be moved into the correct
- location before it can be run. If DESTDIR have not been set but INSTALL_PREFIX
- has been set, DESTDIR will be set to INSTALL_PREFIX. Note that INSTALL_PREFIX
- in pre R13B04 was buggy and behaved as EXTRA_PREFIX (see below). There are
- lots of areas of use for an installation procedure using DESTDIR, e.g. when
- creating a package, cross compiling, etc. Here is an example where the
- installation should be located under /opt/local:
- $ ./configure --prefix=/opt/local
- $ make
- $ mkdir /tmp/erlang-build
- $ make DESTDIR=/tmp/erlang-build install
- $ cd /tmp/erlang-build/opt/local
- $ # gnu-tar is used in this example
- $ tar -zcf /home/me/my-erlang-build.tgz *
- $ su -
- Password: *****
- $ cd /opt/local
- $ tar -zxf /home/me/my-erlang-build.tgz
-* Test install using EXTRA_PREFIX. Note that EXTRA_PREFIX is similar to
- DESTDIR, but it does not have the same effect as DESTDIR. The EXTRA_PREFIX
- variable will prefix all installation paths, and the installation can and
- have to be run from there. That is, it can be useful if you want to try the
- system out, running test suites, etc, before doing the real install without
- EXTRA_PREFIX.
-* Install using the `release' target. Instead of doing `make install' you can
- creat the installation in whatever directory you like using the `release'
- target and run the `Install' script yourself. RELEASE_ROOT is used for
- specifying the directory where the installation should be created. This is
- what by default ends up under `/usr/local/lib/erlang' if you do the install
- using `make install'. All installation paths provided in the `configure'
- phase are ignored, as well as DESTDIR, and INSTALL_PREFIX. If you want links
- from a specific `bin' directory to the installation you have to set those up
- yourself. An example where Erlang/OTP should be located at /home/me/OTP:
- $ ./configure
- $ make
- $ make RELEASE_ROOT=/home/me/OTP release
- $ cd /home/me/OTP
- $ ./Install -minimal /home/me/OTP
- $ mkdir -p /home/me/bin
- $ cd /home/me/bin
- $ ln -s /home/me/OTP/bin/erl erl
- $ ln -s /home/me/OTP/bin/erlc erlc
- $ ln -s /home/me/OTP/bin/escript escript
- ...
- The `Install' script should currently be invoked as follows in the
- directory where it resides:
- `./Install [-cross] [-minimal|-sasl] <ERL_ROOT>'
- where:
- -minimal - Creates an installation that starts up a minimal amount
- of applications, i.e., only kernel and stdlib are started.
- The minimal system is normally enough.
- -sasl - Creates an installation that also starts up the sasl
- application.
- -cross - For cross compilation. Informs the install script that it
- is run on the build machine.
- <ERL_ROOT> - The absolute path to the Erlang installation to use at run
- time. This is often the same as the current working
- directory, but does not have to be. It can follow any other
- path through the file system to the same directory.
-
- If neither -minimal, nor -sasl is passed as argument you will be prompted.
-
-When doing `make install' and the default installation prefix is used, relative
-symbolic links will be created from /usr/local/bin to all public executables in
-the Erlang installation. The installation phase will try to create relative
-symbolic links as long as `--bindir' and the Erlang bin directory, located under
-`--libdir', both have `--exec-prefix' as prefix. Where `--exec-prefix'
-defaults to `--prefix'. `--prefix', `--exec-prefix', `--bindir', and `--libdir'
-are all arguments that can be passed to `configure'. One can however force
-relative, or absolute links by passing BINDIR_SYMLINKS=relative|absolute
-as arguments to make during the install phase. Note that such a request might
-cause a failure if the request cannot be satisfied.
-
-The source tree is delivered with a lot of platform independent
-build results already pre-built. If you want to remove these pre-built
-files, invoke './otp_build remove_prebuilt_files' from the $ERL_TOP
-directory. After you have done this, you can build exactly the same way
-as before, but the build process will take a much longer time.
-
-NOTE: Doing 'make clean' in an arbitrary directory of the source tree,
-may remove files needed for bootstrapping the build. Doing
-'./otp_build save_bootstrap' from the $ERL_TOP directory before
-doing 'make clean' will ensure that it will be possible to build after
-doing 'make clean'. './otp_build save_bootstrap' will be invoked
-automatically when 'make' is invoked from ERL_TOP with either the
-clean target, or the default target. It is also automatically invoked
-if './otp_build remove_prebuilt_files' is invoked.
-
-If you or your system has special requirements please read the
-Makefile for additional configuration information.
-
-Cross compiling Erlang/OTP
---------------------------
-The support for cross compiling Erlang/OTP is in its early stage of
-development, and should be considered as experimental. For more
-information see: $ERL_TOP/xcomp/README
-
-How to build a debug enabled Erlang runtime system
---------------------------------------------------
-
-After completing all the normal building steps described above a debug
-enabled runtime system can be built. To do this you have to change
-directory to $ERL_TOP/erts/emulator.
-
-In this directory execute:
-
- make debug FLAVOR=$FLAVOR
-
-where $FLAVOR is either "plain" or "smp". The flavor options will
-produce a beam.debug and beam.smp.debug executable respectively. The
-files are installed along side with the normal (opt) versions beam.smp
-and beam.
-
-To start the debug enabled runtime system execute:
-
- $ERL_TOP/bin/cerl -debug
-
-The debug enabled runtime system features lock violation checking,
-assert checking and various sanity checks to help a developer ensure
-correctness. Some of these features can be enabled on a normal beam
-using appropriate configure options.
-
-There are other types of runtime systems that can be built as well
-using the similar steps just described.
-
- make $TYPE FLAVOR=$FLAVOR
-
-where $TYPE is opt, gcov, gprof, debug, valgrind, lcnt. These
-different beam types are useful for debugging and profiling purposes.
-
-
-Support for SMP (Symmetric Multi Processing)
---------------------------------------------
-
-An emulator with SMP support will be built by default on most platforms
-if a usable POSIX thread library or native Windows threads is found.
-
-You can force building of an SMP emulator, by using
-"./configure --enable-smp-support". However, if configure doesn't
-automatically enable SMP support, the build is very likely to fail.
-
-Use "./configure --disable-smp-support" if you for some reason don't
-want to have the emulator with SMP support built.
-
-If SMP support is enabled, support for threaded I/O will also be turned on
-(also in the emulator without SMP support).
-
-The 'erl' command will automatically start the SMP emulator if the
-computer has more than one logical processor. You can force a start
-of the emulator with SMP support by passing '-smp enable' as
-command line arguments to erl, and you can force a start of the
-emulator without SMP support by passing '-smp disable'.
-
-How to install the Erlang/OTP documentation
--------------------------------------------
-
-For some graphical tools to find the on-line help you have to install
-the HTML documentation on top of the installed OTP applications, i.e.
-
- $ cd <PrefixDir>/lib/erlang
- $ gunzip -c otp_html_R<XY>B-<Z>.tar.gz | tar xf -
-
-For "erl -man <page>" to work the Unix manual pages have to be
-installed in the same way, i.e.
-
- $ cd <PrefixDir>/lib/erlang
- $gunzip -c otp_man_R<XY>B-<Z>.tar.gz | tar xf -
-
-
-GS (Graphic System)
--------------------
-
-GS now Tcl/Tk 8.4. It will be searched for when starting GS.
-
-Using HiPE
-----------
-
-HiPE supports the following system configurations:
-
-x86:
- All 32-bit and 64-bit mode processors should work.
-
- Linux:
- Fedora Core is supported.
- Both 32-bit and 64-bit modes are supported.
-
- NPTL glibc is strongly preferred, or a LinuxThreads
- glibc configured for "floating stacks". Old non-floating
- stacks glibcs have a fundamental problem that makes HiPE
- support and threads support mutually exclusive.
-
- Solaris:
- Solaris 10 (32-bit and 64-bit) and 9 (32-bit) are supported.
-
- The build requires a version of the GNU C compiler (gcc)
- that has been configured to use the GNU assembler (gas).
- Sun's x86 assembler is emphatically /not/ supported.
-
- FreeBSD:
- FreeBSD 6.1 and 6.2 in 32-bit and 64-bit modes should work.
-
- MacOSX/Darwin:
- Darwin 9.8.0 in 32-bit mode should work.
-
-PowerPC:
- All 32-bit 6xx/7xx(G3)/74xx(G4) processors should work. 32-bit mode on
- 970 (G5) and POWER5 processors should work.
-
- Linux (Yellow Dog) and Mac OSX 10.4 are supported.
-
-SPARC:
- All UltraSPARC processors running 32-bit user code should work.
-
- Solaris 9 and Linux (Aurora) are supported.
-
- On Solaris the build requires a gcc that has been configured to use Sun's
- assembler and linker. Using the GNU assembler but Sun's linker has been
- known to cause problems.
-
-ARM:
- ARMv5TE (i.e. XScale) processors should work. Both big-endian and
- little-endian modes are supported.
-
- Linux is supported.
-
-HiPE is automatically enabled on the following systems:
- x86 in 32-bit mode: Linux, Solaris, FreeBSD
- x86 in 64-bit mode: Linux, Solaris, FreeBSD
- PowerPC: Linux, MacOSX
- SPARC: Linux
- ARM: Linux
-
-On other supported systems you need to "./configure --enable-hipe".
-
-If you are running on a platform supporting HiPE and if you have not disabled
-HiPE, you can compile a module into native code like this from the Erlang
-shell:
-
- 1> c(Module, native).
-
-or
-
- 1> c(Module, [native|OtherOptions]).
-
-Using the erlc program, write like this:
-
- $ erlc +native Module.erl
-
-The native code will be placed into the beam file and automatically loaded
-when the beam file is loaded.
-
-To add hipe options, write like this from the Erlang shell:
-
- 1> c(Module, [native,{hipe,HipeOptions}|MoreOptions]).
-
-Use hipe:help_options/0 to print out the available options.
-
- 1> hipe:help_options().
-
-Mac OS X (Darwin)
------------------
-
-We test Mac OS X 10.4.11 (Tiger) and Mac OS X 10.5.x (Leopard) in our daily
-builds (but only on Intel processors).
-
-Make sure that the command "hostname" returns a valid fully qualified host
-name (this is configured in "/etc/hostconfig").
-
-If you develop linked-in drivers (shared library) you need to link
-using "gcc" and the flags '-bundle -flat_namespace -undefined
-suppress'. You also include '-fno-common' in CFLAGS when
-compiling. Use ".so" as the library suffix.
-
-Universal 32bit binaries can be built on an Intel Mac using the
-'--enable-darwin-universal' configure option. There still may occur
-problems with certain applications using this option, but the base
-system should run smoothly.
-
-When building universal binaries on a PowerPC Mac (at least on Tiger),
-you must point out a suitable SDK that contains universal binaries.
-For instance, to build universal binaries for Tiger (10.4):
-
- $ CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk" \
- LDFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk" \
- ./configure --enable-darwin-universal
-
-Also, if you run Leopard, but want to build for Tiger, you must do by setting the MACOSX_DEPLOYMENT_TARGET environmental variable.
-
- $ export MACOSX_DEPLOYMENT_TARGET=10.4
-
-Experimental support for 64bit x86 darwin binaries can be enabled
-using the '--enable-darwin-64bit' configure flag. The 64bit binaries are
-best built and run on Leopard, but most of the system also works on
-Tiger (Tiger's 64bit libraries are, however, limited; therefore e.g. odbc,
-crypto, ssl etc. are not supported in Tiger). 64bit PPC binaries are not
-supported and we have no plans to add such support (no machines to
-test on).
-
-Universal binaries and 64bit binaries are mutually exclusive options.
-
-Make and the variable "ERL_TOP"
--------------------------------
-
-All the makefiles in the entire directory tree use the environment
-variable ERL_TOP to find the absolute path of the installation. The
-configure script will figure this out and set it in the top level
-Makefile (which, when building, it will pass on). However, when
-developing it is sometimes convenient to be able to run make in a
-subdirectory. To do this you must set the ERL_TOP variable
-before you run make.
-
-For example, assume your GNU make program is called "make" and you
-want to rebuild the application STDLIB, then you could do:
-
- $ cd lib/stdlib; env ERL_TOP=<Dir> make
-
-where <Dir> would be what you find ERL_TOP is set to in the top level
-Makefile.
-
-Authors
--------
-Authors are mostly listed in the application's AUTHORS files,
-that is $ERL_TOP/lib/*/AUTHORS and $ERL_TOP/erts/AUTHORS,
-not in the individual source files.
-
-
-More Information
-----------------
-
-More information can be found at http://www.erlang.org/.
View
76 README.md
@@ -0,0 +1,76 @@
+Erlang/OTP
+==========
+
+**Erlang** is a programming language used to build massively scalable soft
+real-time systems with requirements on high availability. Some of its
+uses are in telecom, banking, e-commerce, computer telephony and
+instant messaging. Erlang's runtime system has built-in support for
+concurrency, distribution and fault tolerance.
+
+**OTP** is set of Erlang libraries and design principles providing
+middle-ware to develop these systems. It includes its own distributed
+database, applications to interface towards other languages, debugging
+and release handling tools.
+
+More information can be found at [erlang.org] [1].
+
+Building and Installing
+-----------------------
+
+Information on building and installing Erlang/OTP can be found
+in the `INSTALL.md` document.
+
+Contributing to Erlang/OTP
+--------------------------
+
+Here are the [instructions for submitting patches] [2].
+
+In short:
+
+* We prefer to receive proposed updates via email on the
+ [`erlang-patches`] [3] mailing list rather than through a pull request.
+ Pull requests are not practical because we have a strict policy never to
+ merge any untested changes to the development branch (the only exception
+ being **obviously** correct changes, such as corrections of typos).
+
+* We merge all proposed updates to the `pu` (*proposed updates*) branch,
+ typically within one working day.
+
+* At least once a day, the contents of the `pu` branch will be built on
+ several platforms (Linux, Solaris, Mac OS X, Windows, and so on) and
+ automatic test suites will be run. We will email you if any problems are
+ found.
+
+* If a proposed change builds and passes the tests, it will be reviewed
+ by one or more members of the Erlang/OTP team at Ericsson. The reviewer
+ may suggest improvements that are needed before the change can be accepted
+ and merged.
+
+* Once or twice a week, a status email called "What's cooking in Erlang/OTP"
+ will be sent to the [`erlang-patches`] [3] mailing list.
+
+Copyright and License
+---------------------
+
+> %CopyrightBegin%
+>
+> Copyright Ericsson AB 2010. All Rights Reserved.
+>
+> The contents of this file are subject to the Erlang Public License,
+> Version 1.1, (the "License"); you may not use this file except in
+> compliance with the License. You should have received a copy of the
+> Erlang Public License along with this software. If not, it can be
+> retrieved online at http://www.erlang.org/.
+>
+> Software distributed under the License is distributed on an "AS IS"
+> basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+> the License for the specific language governing rights and limitations
+> under the License.
+>
+> %CopyrightEnd%
+
+
+
+ [1]: http://www.erlang.org
+ [2]: http://wiki.github.com/erlang/otp/submitting-patches
+ [3]: http://www.erlang.org/faq.html
View
763 README.win32
@@ -1,763 +0,0 @@
-How to build Erlang/OTP on Windows.
------------------------------------
-Table of contents
-
-1. Introduction
-2. Answers to some "frequently asked questions"
-3. Tools you need and their environment
-4. The shell environment
-5. Building and installing
-6. Development
-7. Final words
-
-%CopyrightBegin%
-
-Copyright Ericsson AB 2003-2009. All Rights Reserved.
-
-The contents of this file are subject to the Erlang Public License,
-Version 1.1, (the "License"); you may not use this file except in
-compliance with the License. You should have received a copy of the
-Erlang Public License along with this software. If not, it can be
-retrieved online at http://www.erlang.org/.
-
-Software distributed under the License is distributed on an "AS IS"
-basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
-the License for the specific language governing rights and limitations
-under the License.
-
-%CopyrightEnd%
-
-
-
-Introduction
-------------
-
-This file describes how to build the Erlang emulator and the OTP
-libraries on Windows. The instructions apply to versions of Windows
-supporting the Cygwin emulated gnuish environment for Windows. We've
-built on the following platforms: Windows 2000 Professional, Windows
-2003 server, Windows XP Home/Professional, and Windows Vista. Any
-Windows95'ish platform will surely get you into trouble, what I'm not
-sure of, but it certainly will...
-
-The procedure described uses Cygwin as a build environment, you run
-the bash shell in Cygwin and uses gnu make/configure/autoconf etc to
-do the build. The emulator C-source code is, however, mostly compiled
-with Microsoft Visual C++(tm), producing a native Windows binary. This
-is the same procedure as we use to build the pre-built binaries. The
-fact that we use VC++ and not gcc is explained further in the FAQ
-section.
-
-I describe the build procedure to make it possible for open source
-customers to build the emulator, given that they have the needed
-tools. The binary Windows releases is still a preferred alternative if
-one does not have Microsoft's development tools and/or don't want to
-install Cygwin.
-
-To use Cygwin, one needs basic experience from a Unix environment, if
-one does not know how to set environment variables, run programs etc
-in a Unix environment, one will be quite lost in the Cygwin
-ditto. I can unfortunately not teach all the world how to use
-Cygwin and bash, neither how to install Cygwin nor perform basic tasks
-on a computer. Please refer to other documentation on the net for
-help, or use the binary release instead if you have problems using the
-tools.
-
-However, if you feel comfortable with the environment and build
-system, and have all the necessary tools, you have a great opportunity
-to make the Erlang/OTP distribution for Windows better. Please submit
-any suggestions and patches to the appropriate mailing lists (see
-http://www.erlang.org) to let them find their way into the next
-version of Erlang. If making changes to the build system (like
-makefiles etc) please bear in mind that the same makefiles are used on
-Unix/VxWorks/OSEDelta, so that your changes don't break other
-platforms. That of course goes for C-code too, system specific code
-resides in the $ERL_TOP/erts/emulator/sys/win32 and $ERL_TOP/erts/etc/win32
-directories mostly. The $ERL_TOP/erts/emulator/beam directory is for
-common code.
-
-Before the R9C release of Erlang/OTP, the Windows release was built
-partly on a Unix (Solaris) box and partly on a Windows box, using Perl
-hacks to communicate and sync between the two machines. R9C was the
-first release ever built solely on Windows, where no Unix machine is
-needed at all. Now we've used this build procedure for a couple of
-releases, and it has worked fine for us. Still, there might be all
-sorts of troubles on different machines and with different
-setups. I'll try to give hints wherever I've encountered difficulties,
-but please share your experiences by using the mailing list
-erlang_questions@erlang.org. I cannot of course help everyone with all
-their problems, please try to solve the problems and submit
-solutions/workarounds. Remember, it's all about sharing, not about
-demanding...
-
-Lets go then, I'll start with a little FAQ, based on in house questions
-and misunderstandings.
-
-
-Answers to "frequently asked questions"
----------------------------------------
-
-Q: So, now I can build Erlang using GCC on Windows?
-
-A: No, unfortunately not. You'll need Microsoft's Visual C++ still, a
-Bourne-shell script (cc.sh) wraps the Visual C++ compiler and runs it
-from within the Cygwin environment. All other tools needed to build
-Erlang are free-ware/open source, but not the C compiler.
-
-Q: Why haven't you got rid of VC++ then, you ******
-
-A: Well, partly because it's a good compiler - really! Actually it's
-been possible in late R11-releases to build using mingw instead of
-visual C++ (you might see the remnants of that in some scripts and
-directories). Unfortunately the development of the SMP version for
-Windows broke the mingw build and we chose to focus on the VC++ build
-as the performance has been much better in the VC++ versions. The
-mingw build will be back, but as long as VC++ gives better
-performance, the commercial build will be a VC++ one.
-
-Q: OK, VC++ you need, but now you've started to demand a very recent
-(and expensive) version of Visual studio, not the old and stable VC++
-6.0 that was used in earlier versions. Why?
-
-A: The SMP version of Erlang needs features in the Visual Studio
-2005. Can't live without them. Besides the new compiler gives the
-Erlang emulator a ~40% performance boost(!)
-
-Q: Can/will I build a Cygwin binary with the procedure you describe?
-
-A: No, the result will be a pure Windows binary, and as far as I know,
-it's not possible to make a Cygwin binary yet. That is of course
-something desirable, but there are still some problems with the
-dynamic linking (dynamic Erlang driver loading) as well as the TCP/IP
-emulation in Cygwin, which, I'm sure of, will improve, but still has
-some problems. Fixing those problems might be easy or might be hard.
-I suggest you try yourself and share your experience. No one would be
-happier if a simple ./configure && make would produce a fully fledged
-Cygwin binary. Ericsson does however not pay me to do a Cygwin port, so
-such a port would have to happen in spare time, which is a limited resource...
-
-Q: Hah, I saw you, you used GCC even though you said you didn't!
-
-A: OK, I admit, one of the files is compiled using Cygwin's GCC and
-the resulting object code is then converted to MS VC++ compatible coff
-using a small C hack. It's because that particular file, beam_emu.c
-benefits immensely from being able to use the GCC labels-as-values
-extension, which boosts emulator performance by up to 50%. That does
-unfortunately not (yet) mean that all of OTP could be compiled using
-GCC, that particular source code does not do anything system specific
-and actually is adopted to the fact that GCC is used to compile it on
-Windows.
-
-Q: So now there's a MS VC++ project file somewhere and I can build OTP
-using the nifty VC++ GUI!
-
-A: No, never. The hassle of keeping the project files up to date and
-do all the steps that constitute an OTP build from within the VC++ GUI
-is simply not worth it, maybe even impossible. A VC++ project
-file for Erlang/OTP will never happen, at least I will never make
-one. Clicking around in super-multi-tab'd dialogs to add a file or
-compiler option when it's so much easier in a makefile is simply not
-my style.
-
-Q: So how does it all work then?
-
-A: Cygwin is the environment, which closely resembles the environments
-found on any Unix machine. It's almost like you had a virtual Unix
-machine inside Windows. Configure, given certain parameters, then
-creates makefiles that are used by the Cygwin gnu-make to built the
-system. Most of the actual compilers etc are not, however, Cygwin
-tools, so I've written a couple of wrappers (Bourne-shell scripts),
-which reside in $ERL_TOP/etc/win32/cygwin_tools and they all do
-conversion of parameters and switches common in the Unix environment
-to fit the native Windows tools. Most notable is of course the paths,
-which in Cygwin are Unix-like paths with "forward slashes" (/) and no
-drive letters, the Cygwin specific command 'cygpath' is used for most
-of the path conversions. Luckily most compilers accept forward slashes
-instead of backslashes as path separators, one still have to get the
-drive letters etc right, though. The wrapper scripts are not general
-in the sense that, for example, cc.sh would understand and translates
-every possible gcc option and passes correct options to cl.exe. The
-principle is that the scripts are powerful enough to allow building of
-Erlang/OTP, no more, no less. They might need extensions to cope with
-changes during the development of Erlang, that's one of the reasons I
-made them into shell-scripts and not Perl-scripts, I believe they are
-easier to understand and change that way. I might be wrong though,
-cause another reason I didn't write them in Perl is because I've never
-liked Perl and my Perl code is no pleasant reading...
-
-In $ERL_TOP, there is a script called otp_build, that script handles
-the hassle of giving all the right parameters to configure/make and
-also helps you set up the correct environment variables to work with
-the Erlang source under Cygwin.
-
-Q: You use and need Cygwin, but then you haven't taken the time to
-port Erlang to the Cygwin environment but instead focus on your
-commercial release, is that really ethical?
-
-A: No, not really, but see this as a step in the right direction. I'm
-aiming at GCC compiled emulators and a Cygwin version, but I really
-need to do other things as well... In time, but don't hold your
-breath...
-
-Q: Can I build something that looks exactly as the commercial release.
-
-A: Yes, we use the exactly same build procedure.
-
-Q: Which version of Cygwin and other tools do you use then?
-
-A: For Cygwin we try to use the latest releases available when
-building. What versions you use shouldn't really matter, I try to
-include workarounds for the bugs I've found in different Cygwin
-releases, please help me to add workarounds for new Cygwin-related
-bugs as soon as you encounter them. Also please do submit bug reports
-to the appropriate Cygwin developers. The Cygwin GCC we used for R13B
-was version 3.4.4. We used VC++ 8.0 (i.e. Visual studio 2005 SP1),
-Sun's JDK 1.5.0_17, NSIS 2.37, and Win32 OpenSSL 0.9.8e. Please read
-the next section for details on what you need.
-
-Q: Can you help me setup X in Cygwin?
-
-A: No, unfortunately I haven't got time to help with Cygwin related
-user problems, please read Cygwin related web sites, newsgroups and
-mailing lists.
-
-Q: Why is the instruction so long? Is it really that complicated?
-
-A: Partly it's long because I babble too much, partly because I've
-described as much as I could about the installation of the needed
-tools. Once the tools are installed, building is quite easy. I also
-have tried to make this instruction understandable for people with
-limited Unix experience. Cygwin is a whole new environment to some
-Windows users, why careful explanation of environment variables etc
-seemed to be in place. The short story, for the experienced and
-impatient is:
-
-* Get and install complete Cygwin (latest)
-* (Buy and) Install Microsoft Visual studio 2005 and SP1 (or higher)
-* Get and install Sun's JDK 1.4.2
-* Get and install NSIS 2.01 or higher (up to 2.30 tried and working)
-* Get and install OpenSSL 0.9.7c or higher
-* Get and unpack wxWidgets-2.8.9 or higher to /opt/local/pgm inside cygwin
- - open /cygwin/opt/local/pgm/wxWidgets-2.8.9/build/msw/wx.dsw
- - enable wxUSE_GLCANVAS, wxUSE_POSTSCRIPT and wxUSE_GRAPHICS_CONTEXT
- in include/wx/msw/setup.h
- - build all unicode release (and unicode debug) packages
- - open /cygwin/opt/local/pgm/wxWidgets-2.8.9/contrib/build/stc/stc.dsw
- - build the unicode release (and unicode debug) packages
-* Get and unpack the erlang source distribution with Cygwin's tar.
-* set ERL_TOP to where you unpacked the source distribution
-* $ cd $ERL_TOP
-* Get (from http://www.erlang.org/download/tcltk85_win32_bin.tar.gz)
-and unpack the prebuilt TCL/TK binaries for windows with cygwin tar,
-standing in $ERL_TOP
-* Modify PATH and other environment variables so that all these tools
-are runnable from a bash shell. Still standing in $ERL_TOP, issue the following
-commands:
-$ eval `./otp_build env_win32`
-$ ./otp_build autoconf
-$ ./otp_build configure
-$ ./otp_build boot -a
-$ ./otp_build release -a
-$ ./otp_build installer_win32
-$ release/win32/otp_win32_<OTP version> /S
-
-Voila! "Start->Programs->Erlang OTP <OTP version>->Erlang" starts the Erlang
-Windows shell.
-
-
-Tools you need and their environment
-------------------------------------
-
-You need some tools to be able to build Erlang/OTP on Windows. Most
-notably you'll need Cygwin and Microsoft VC++, but you also might want
-a Java compiler, the NSIS install system and OpenSSL. Only VC++ costs
-money, but then again it costs a lot of money, I know...
-Well' here's the list:
-
-* Cygwin, the very latest is usually best. Get all the development
-tools and of course all the basic ditto. In fact getting the complete
-package might be a good idea, as you'll start to love Cygwin after a
-while if you're accustomed to Unix. Make sure to get jar and also make
-sure *not* to install a Cygwin'ish Java... The Cygwin jar command is
-used but Sun's Java compiler and virtual machine...
-
-URL: http://www.cygwin.com
-
-- get the installer from the web site and use that to install
-Cygwin. Be sure to have fair privileges. If you're on a NT domain you
-should consider running "mkpasswd -d" and "mkgroup -d" after the
-installation to get the user databases correct. See their respective
-manual pages.
-
-When you start you first bash shell, you will get an awful prompt. You
-might also have a PATH environment variable that contains backslashes
-and such. Edit $HOME/.profile and $HOME/.bashrc to set fair prompts
-and set a correct PATH. Also do a "export SHELL" in .profile. For some
-non-obvious reason the environment variable $SHELL is not exported in
-bash. Also note that .profile is run at login time and .bashrc when
-sub shells are created. You'll need to explicitly source .bashrc from
-.profile if you want the commands there to be run at login time (like
-setting up aliases, shell functions and the like). I personally
-usually do like this at the end of .profile:
-------------------
-ENV=$HOME/.bashrc
-export ENV
-. $ENV
-----------------
-
-You might also, if you're a hard core type of person at least, want to
-setup X-windows (XFree86), that might be as easy as running startx
-from the command prompt and it might be much harder. Use Google to
-find help...
-
-If you don't use X-windows, you might want to setup the Windows
-console window by selecting properties in the console system menu
-(upper left corner of the window, the Cygwin icon in the title
-bar). Especially setting a larger screen buffer size (lines) is useful
-as it gets you a scrollbar so you can see whatever error messages
-that might appear...
-
-If you want to use (t)csh instead of bash you're on your own, I
-haven't tried and know of no one that has. I expect
-that you use bash in all shell examples.
-
-* Microsoft Visual Studio 2005 SP1. Please don't skip the service
-pack! The installer might update your environment so that you can run
-the 'cl' command from the bash prompt, then again it might
-not... There is always a BAT file in VC\Bin under the installation
-directory (default C:\Program Files\Microsoft Visual Studio 8) called
-VCVARS32.BAT. Either add the environment settings in that file to the
-global environment settings in Windows or add the corresponding BASH
-environment settings to your .profile/.bashrc. For example, in my case
-I could add the following to .profile
-------------------------------------------------------------
-#Visual C++ Root directory as Cygwin style pathname
-VCROOT=/cygdrive/c/Program\ Files/Microsoft\ Visual\ Studio 8
-
-# Visual C++ Root directory as Windows style pathname
-WIN_VCROOT="C:\\Program Files\\Microsoft Visual Studio 8"
-
-# The PATH variable should be Cygwin'ish
-PATH=$VCROOT/Common7/IDE:$VCROOT/VC/BIN:$VCROOT/Common7/Tools:\
-$VCROOT/Common7/Tools/bin:$VCROOT/VC/PlatformSDK/bin:$VCROOT/SDK/v2.0/bin:\
-$VCROOT/VC/VCPackages:$PATH
-
-# Lib and INCLUDE should be Windows'ish
-# Note that semicolon (;) is used to separate Windows style paths but
-# colon (:) to separate Cygwin ditto!
-
-LIBPATH=$WIN_VCROOT\\VC\\ATLMFC\\LIB
-
-LIB=$WIN_VCROOT\\VC\\ATLMFC\\LIB\;$WIN_VCROOT\\VC\\LIB\;\
-$WIN_VCROOT\\VC\\PlatformSDK\\lib\;$WIN_VCROOT\\SDK\\v2.0\\lib
-
-INCLUDE=$WIN_VCROOT\\VC\\ATLMFC\\INCLUDE\;$WIN_VCROOT\\VC\\INCLUDE\;\
-$WIN_VCROOT\\VC\\PlatformSDK\\include
-
-export PATH LIB INCLUDE
---------------------------------------------------------------
-
-Make a simple hello world and try to compile it with the 'cl' command
-from within bash. If that does not work, your environment needs
-fixing. Also remember to fix up the PATH environment, especially old
-Erlang installations might have inserted quoted paths that Cygwin does
-not understand. Remove or correct such paths. There should be no
-backslashes in your path environment variable in Cygwin bash, but LIB
-and INCLUDE should contain Windows style paths with semicolon,
-drive letters and backslashes.
-
-If you wish to use Visual Studio 2008, a couple things need to be tweaked,
-namely the fact that some of the SDK stuff is installed in (by default)
-C:\Program Files\Microsoft SDKs\v6.0A . Just ensure that that
-C:\Program Files\Microsoft SDKs\v6.0A\Lib is in LIB and
-C:\Program Files\Microsoft SDKs\v6.0A\Include is in INCLUDE. A symptom of not
-doing this is errors about finding kernel32.lib and windows.h.
-
-Additionally, if you encounter errors about mc.exe not being found, you must
-install the entire Windows SDK (the partial SDK included in visual studio
-apparently does not include it). After installing it you'll want to add
-something like: /c/cygdrive/Program\ Files/Microsoft\ SDKs/v7.0/bin to your
-PATH to allow the environment to find mc.exe. The next Visual Studio (2010) is
-expected to include this tool.
-
-* Sun's Java JDK 1.5.0 or higher. Our Java code (jinterface, ic) is
-written for JDK 1.5.0. Get it for Windows and install it, the JRE is
-not enough. If you don't care about Java, you can skip this step, the
-result will be that jinterface is not built.
-
-URL: http://java.sun.com
-
-Add javac *LAST* to your path environment in bash, in my case this means:
---------------------------------------------------------------
-PATH="$PATH:/cygdrive/c/Program Files/Java/jdk1.5.0_17/bin"
---------------------------------------------------------------
-No CLASSPATH or anything is needed. Type "javac" at the bash prompt
-and you should get a list of available Java options. Make sure by
-typing "which java" that you use the Java you installed. Note however that
-Cygwin's jar.exe is used, that's why the JDK bin-directory should be
-added last in the PATH.
-
-* Nullsoft NSIS installer system. You need this to build the self
-installing package. It's a free open source installer that's much
-nicer to use than the commercial Wise and Install shield
-installers. This is the installer we use for commercial releases as
-well from R9C an on.
-URL: http://www.nullsoft.com/free/nsis
-Install the lot, especially the modern user interface components, as
-it's definitely needed. Put "makensis" in your path, in my case:
---------------------------------------------------------------
-PATH=/cygdrive/c/Program\ Files/NSIS:$PATH
---------------------------------------------------------------
-type makensis at the bash prompt and you should get a list of options
-if everything is OK.
-
-* OpenSSL for Windows. This is if you want the SSL and crypto
-applications to compile (and run). Go to http://www.openssl.org, click
-on the "Related" link and then on the "Binaries" link (upper right
-corner of the page last time I looked), you can then reach the
-"Shining Lights Productions" Web site for Windows binaries
-distributions. Get the latest or 0.9.7c if you get trouble with the
-latest. It's a nifty installer. The rest should be handled by
-configure, you needn't put anything in the path or anything.
-
-If you want to build openssl for windows yourself (which might be
-possible, as you wouldn't be reading this if you weren't a
-compile-it-yourself person), you either have to put the resulting
-DLL's in your path or in the windows system directory and either
-specify where you put the includes etc with the configure-parameter
---with-ssl=<cygwin path to the root> or put your installation directly
-under c:\OpenSSL. The directory structure under the installation root
-for OpenSSL is expected to be one with subdirectories named "include",
-"bin" and "lib", possibly with a "VC" subdirectory of "lib" containing
-the actual .lib files. Note that the cygwin distributed OpenSSL cannot be
-used, it results in cygwin depending binaries and it has unix style
-archives (.a, not .lib).
-
-* Building with wxWidgets. Download wxWidgets-2.8.9 or higher patch
-release (2.9.* is a developer release which currently does not work
-with wxErlang).
-Install or unpack it to DRIVE:/PATH/cygwin/opt/local/pgm
-Open from explorer (i.e. by double clicking the file)
-C:\cygwin\opt\local\pgm\wxMSW-2.8.10\build\msw\wx.dsw
-In Microsoft Visual Studio, click File/Open/File, locate and
-open: C:\cygwin\opt\local\pgm\wxMSW-2.8.10\include\wx\msw\setup.h
-enable wxUSE_GLCANVAS, wxUSE_POSTSCRIPT and wxUSE_GRAPHICS_CONTEXT
-Build it by clicking Build/Batch Build and select all unicode release
-(and unicode debug) packages.
-Open C:\cygwin\opt\local\pgm\wxMSW-2.8.10\contrib/build/stc/stc.dsw
-and batch build all unicode packages.
-
-* The Erlang source distribution. The same as for Unix
-platforms. Preferably use tar from within Cygwin to unpack the source
-tar.gz (tar zxf otp_src_R13B03.tar.gz).
-
-set the environment ERL_TOP to point to the root directory of the
-source distribution. Let's say I stood in $HOME/src and unpacked
-otp_src_R13B03.tar.gz, I then add the following to .profile:
---------------------------------------------------------
-ERL_TOP=$HOME/src/otp_src_R13B03
-export $ERL_TOP
---------------------------------------------------------
-
-* The TCL/TK binaries. You could compile Tcl/Tk for windows yourself,
-but you can get a stripped down version from our website which is
-suitable to include in the final binary package. If you want to supply <