Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Merge branch 'pan/win64-fixes'

* pan/win64-fixes:
  Update INSTALL-WIN32.md to reflect changes in R15B
  Make erl_alloc.c use correct strtol variant on windows
  Set absolute limit on number of threads in ethread_SUITE

OTP-9130
  • Loading branch information...
commit f20b520b0d2d990ab70b56345b63a8b508edde1a 2 parents 40bc5cf + e3b1ff5
Patrik Nyblom bufflig authored
615 INSTALL-WIN32.md
Source Rendered
@@ -6,29 +6,31 @@ Introduction
6 6
7 7 This file describes how to build the Erlang emulator and the OTP
8 8 libraries on Windows. The instructions apply to versions of Windows
9   -supporting the Cygwin emulated gnuish environment for Windows. We've
10   -built on the following platforms: Windows 2000 Professional, Windows
11   -2003 server, Windows XP Home/Professional, and Windows Vista. Any
12   -Windows95'ish platform will surely get you into trouble, what I'm not
13   -sure of, but it certainly will...
14   -
15   -The procedure described uses Cygwin as a build environment, you run
16   -the bash shell in Cygwin and uses gnu make/configure/autoconf etc to
17   -do the build. The emulator C-source code is, however, mostly compiled
18   -with Microsoft Visual C++™, producing a native Windows binary. This
19   -is the same procedure as we use to build the pre-built binaries. The
20   -fact that we use VC++ and not gcc is explained further in the FAQ
21   -section.
  9 +supporting the Cygwin emulated gnuish environment for Windows or the
  10 +Msys ditto. We've built on the following platforms: Windows 2003
  11 +server, Windows XP Home/Professional, Windows Vista and Windows 7 (32
  12 +and 64 bit). You can probably build on Windows 2000, but you will not
  13 +be able to install the latest Microsoft SDK, so you have to go back to
  14 +some earlier compiler. Any Windows95'ish platform will surely get you
  15 +into trouble, what I'm not sure of, but it certainly will...
  16 +
  17 +The procedure described uses either Cygwin or Msys as a build
  18 +environment, you run the bash shell in Cygwin/Msys and use gnu
  19 +make/configure/autoconf etc to do the build. The emulator C-source
  20 +code is, however, mostly compiled with Microsoft Visual C++™,
  21 +producing a native Windows binary. This is the same procedure as we
  22 +use to build the pre-built binaries. The fact that we use VC++ and not
  23 +gcc is explained further in the FAQ section.
22 24
23 25 I describe the build procedure to make it possible for open source
24 26 customers to build the emulator, given that they have the needed
25 27 tools. The binary Windows releases is still a preferred alternative if
26 28 one does not have Microsoft's development tools and/or don't want to
27   -install Cygwin.
  29 +install Cygwin or Msys.
28 30
29   -To use Cygwin, one needs basic experience from a Unix environment, if
  31 +To use Cygwin/Msys, one needs basic experience from a Unix environment, if
30 32 one does not know how to set environment variables, run programs etc
31   -in a Unix environment, one will be quite lost in the Cygwin
  33 +in a Unix environment, one will be quite lost in the Cygwin os Msys
32 34 ditto. I can unfortunately not teach all the world how to use
33 35 Cygwin and bash, neither how to install Cygwin nor perform basic tasks
34 36 on a computer. Please refer to other documentation on the net for
@@ -41,11 +43,11 @@ to make the Erlang/OTP distribution for Windows better. Please submit
41 43 any suggestions and patches to the appropriate [mailing lists] [1] to let
42 44 them find their way into the next version of Erlang. If making changes
43 45 to the build system (like makefiles etc) please bear in mind that the
44   -same makefiles are used on Unix/VxWorks/OSEDelta, so that your changes
  46 +same makefiles are used on Unix/VxWorks, so that your changes
45 47 don't break other platforms. That of course goes for C-code too, system
46 48 specific code resides in the `$ERL_TOP/erts/emulator/sys/win32` and
47 49 `$ERL_TOP/erts/etc/win32` directories mostly. The
48   -`$ERL_TOP/erts/emulator/beam directory` is for common code.
  50 +`$ERL_TOP/erts/emulator/beam` directory is for common code.
49 51
50 52 Before the R9C release of Erlang/OTP, the Windows release was built
51 53 partly on a Unix (Solaris) box and partly on a Windows box, using Perl
@@ -61,6 +63,21 @@ their problems, please try to solve the problems and submit
61 63 solutions/workarounds. Remember, it's all about sharing, not about
62 64 demanding...
63 65
  66 +Starting with R15B, our build system runs both on Cygwin and Msys
  67 +(MinGW's fork of an early cygwin version). Msys is a smaller package
  68 +to install and may on some machines run slightly faster. If Cygwin
  69 +gives you trouble, try Msys instead, and v.v. Beginning with R15B
  70 +there is also a native 64bit version of Erlang for 64bit Windows 7
  71 +(only). These instructions apply to both the 32bit VM and the 64bit
  72 +ditto.
  73 +
  74 +Note that even if you build a 64bit VM, most of the directories and
  75 +files involved are still named win32. You can view the name win32 as
  76 +meaning any windows version not beeing 16bit. A few occurences of the
  77 +name Win64 are however present in the system, for example the
  78 +installation file for a 64 bit windows version of Erlang is by default
  79 +named `otp_win64_<version>.exe`.
  80 +
64 81 Lets go then, I'll start with a little FAQ, based on in house questions
65 82 and misunderstandings.
66 83
@@ -70,10 +87,13 @@ Frequently Asked Questions
70 87
71 88 * Q: So, now I can build Erlang using GCC on Windows?
72 89
73   - A: No, unfortunately not. You'll need Microsoft's Visual C++ still, a
74   - Bourne-shell script (cc.sh) wraps the Visual C++ compiler and runs it
75   - from within the Cygwin environment. All other tools needed to build
76   - Erlang are free-ware/open source, but not the C compiler.
  90 + A: No, unfortunately not. You'll need Microsoft's Visual C++
  91 + still, a Bourne-shell script (cc.sh) wraps the Visual C++ compiler
  92 + and runs it from within the Cygwin environment. All other tools
  93 + needed to build Erlang are free-ware/open source, but not the C
  94 + compiler. The Windows SDK is however enough to build Erlang, you
  95 + do not need to buy Visual C++, just download the SDK (SDK version
  96 + 7.1 == Visual studio 2010).
77 97
78 98 * Q: Why haven't you got rid of VC++ then, you \*\*\*\*\*\*?
79 99
@@ -83,18 +103,22 @@ Frequently Asked Questions
83 103 directories). Unfortunately the development of the SMP version for
84 104 Windows broke the mingw build and we chose to focus on the VC++ build
85 105 as the performance has been much better in the VC++ versions. The
86   - mingw build will be back, but as long as VC++ gives better
  106 + mingw build will possibly be back, but as long as VC++ gives better
87 107 performance, the commercial build will be a VC++ one.
88 108
89   -* Q: OK, VC++ you need, but now you've started to demand a very recent
  109 +* Q: OK, you need VC++, but now you've started to demand a very recent
90 110 (and expensive) version of Visual studio, not the old and stable VC++
91 111 6.0 that was used in earlier versions. Why?
92 112
93   - A: The SMP version of Erlang needs features in the Visual Studio 2005.
94   - Can't live without them. Besides the new compiler gives the Erlang
95   - emulator a ~40% performance boost(!). Alternatively you can build Erlang
96   - successfully using the free (proprietary) Visual Studio 2008 Express
97   - edition C++ compiler.
  113 + A: Well, it's not expensive, it's free (as in free beer). Just
  114 + download and install the latest Windows SDK from Microsoft and all
  115 + the tools you need are there. The included debugger (WinDbg) is
  116 + also quite usable, it's what I used when porting Erlang to 64bit
  117 + Windows. Another reason to use the latest Microsoft compilers is
  118 + DLL compatibility. DLL's using a new version of the standard
  119 + library might not load if the VM is compiled with an old VC++
  120 + version, why we should aim to use the latest freely available SDK
  121 + and compiler.
98 122
99 123 * Q: Can/will I build a Cygwin binary with the procedure you describe?
100 124
@@ -112,15 +136,15 @@ Frequently Asked Questions
112 136
113 137 * Q: Hah, I saw you, you used GCC even though you said you didn't!
114 138
115   - A: OK, I admit, one of the files is compiled using Cygwin's GCC and
116   - the resulting object code is then converted to MS VC++ compatible coff
117   - using a small C hack. It's because that particular file, `beam_emu.c`
118   - benefits immensely from being able to use the GCC labels-as-values
119   - extension, which boosts emulator performance by up to 50%. That does
120   - unfortunately not (yet) mean that all of OTP could be compiled using
121   - GCC, that particular source code does not do anything system specific
122   - and actually is adopted to the fact that GCC is used to compile it on
123   - Windows.
  139 + A: OK, I admit, one of the files is compiled using Cygwin's or
  140 + MinGW's GCC and the resulting object code is then converted to MS
  141 + VC++ compatible coff using a small C hack. It's because that
  142 + particular file, `beam_emu.c` benefits immensely from being able
  143 + to use the GCC labels-as-values extension, which boosts emulator
  144 + performance by up to 50%. That does unfortunately not (yet) mean
  145 + that all of OTP could be compiled using GCC, that particular
  146 + source code does not do anything system specific and actually is
  147 + adopted to the fact that GCC is used to compile it on Windows.
124 148
125 149 * Q: So now there's a MS VC++ project file somewhere and I can build OTP
126 150 using the nifty VC++ GUI?
@@ -135,31 +159,36 @@ Frequently Asked Questions
135 159
136 160 * Q: So how does it all work then?
137 161
138   - A: Cygwin is the environment, which closely resembles the environments
139   - found on any Unix machine. It's almost like you had a virtual Unix
140   - machine inside Windows. Configure, given certain parameters, then
141   - creates makefiles that are used by the Cygwin gnu-make to built the
142   - system. Most of the actual compilers etc are not, however, Cygwin
143   - tools, so I've written a couple of wrappers (Bourne-shell scripts),
144   - which reside in `$ERL_TOP/etc/win32/cygwin_tools` and they all do
145   - conversion of parameters and switches common in the Unix environment
146   - to fit the native Windows tools. Most notable is of course the paths,
147   - which in Cygwin are Unix-like paths with "forward slashes" (/) and no
148   - drive letters, the Cygwin specific command `cygpath` is used for most
149   - of the path conversions. Luckily most compilers accept forward slashes
150   - instead of backslashes as path separators, one still have to get the
151   - drive letters etc right, though. The wrapper scripts are not general
152   - in the sense that, for example, cc.sh would understand and translates
153   - every possible gcc option and passes correct options to cl.exe. The
154   - principle is that the scripts are powerful enough to allow building of
155   - Erlang/OTP, no more, no less. They might need extensions to cope with
156   - changes during the development of Erlang, that's one of the reasons I
157   - made them into shell-scripts and not Perl-scripts, I believe they are
158   - easier to understand and change that way. I might be wrong though,
159   - cause another reason I didn't write them in Perl is because I've never
160   - liked Perl and my Perl code is no pleasant reading...
161   -
162   - In `$ERL_TOP`, there is a script called `otp_build`, that script handles
  162 + A: Cygwin or Msys is the environment, which closely resembles the
  163 + environments found on any Unix machine. It's almost like you had a
  164 + virtual Unix machine inside Windows. Configure, given certain
  165 + parameters, then creates makefiles that are used by the
  166 + Cygwin/Msys gnu-make to built the system. Most of the actual
  167 + compilers etc are not, however, Cygwin/Msys tools, so I've written
  168 + a couple of wrappers (Bourne-shell scripts), which reside in
  169 + `$ERL_TOP/etc/win32/cygwin_tools` and
  170 + `$ERL_TOP/etc/win32/msys_tools`. They all do conversion of
  171 + parameters and switches common in the Unix environment to fit the
  172 + native Windows tools. Most notable is of course the paths, which
  173 + in Cygwin/Msys are Unix-like paths with "forward slashes" (/) and
  174 + no drive letters, the Cygwin specific command `cygpath` is used
  175 + for most of the path conversions in a Cygwin environment, other
  176 + tools are used (when needed) in the corresponding Msys
  177 + environment. Luckily most compilers accept forward slashes instead
  178 + of backslashes as path separators, but one still have to get the drive
  179 + letters etc right, though. The wrapper scripts are not general in
  180 + the sense that, for example, cc.sh would understand and translates
  181 + every possible gcc option and passes correct options to
  182 + cl.exe. The principle is that the scripts are powerful enough to
  183 + allow building of Erlang/OTP, no more, no less. They might need
  184 + extensions to cope with changes during the development of Erlang,
  185 + that's one of the reasons I made them into shell-scripts and not
  186 + Perl-scripts, I believe they are easier to understand and change
  187 + that way. I might be wrong though, cause another reason I didn't
  188 + write them in Perl is because I've never liked Perl and my Perl
  189 + code is no pleasant reading...
  190 +
  191 + In `$ERL_TOP`, there is a script called `otp_build`. That script handles
163 192 the hassle of giving all the right parameters to `configure`/`make` and
164 193 also helps you set up the correct environment variables to work with
165 194 the Erlang source under Cygwin.
@@ -177,17 +206,19 @@ Frequently Asked Questions
177 206
178 207 A: Yes, we use the exactly same build procedure.
179 208
180   -* Q: Which version of Cygwin and other tools do you use then?
  209 +* Q: Which version of Cygwin/Msys and other tools do you use then?
181 210
182   - A: For Cygwin we try to use the latest releases available when
183   - building. What versions you use shouldn't really matter, I try to
184   - include workarounds for the bugs I've found in different Cygwin
185   - releases, please help me to add workarounds for new Cygwin-related
186   - bugs as soon as you encounter them. Also please do submit bug reports
187   - to the appropriate Cygwin developers. The Cygwin GCC we used for %OTP-REL%
188   - was version 3.4.4. We used VC++ 8.0 (i.e. Visual studio 2005 SP1),
189   - Sun's JDK 1.5.0\_17, NSIS 2.37, and Win32 OpenSSL 0.9.8e. Please read
190   - the next section for details on what you need.
  211 + A: For Cygwin and Msys alike, we try to use the latest releases
  212 + available when building. What versions you use shouldn't really
  213 + matter, I try to include workarounds for the bugs I've found in
  214 + different Cygwin/Msys releases, please help me to add workarounds
  215 + for new Cygwin/Msys-related bugs as soon as you encounter
  216 + them. Also please do submit bug reports to the appropriate Cygwin
  217 + adn/or Msys developers. The GCC we used for %OTP-REL% was version
  218 + 4.7.0 (MinGW 64bit) and 4.3.4 (Cygwin 32bit). We used VC++ 10.0
  219 + (i.e. Visual studio 2010), Sun's JDK 1.5.0\_17 (32bit) and Sun's
  220 + JDK 1.7.0\_1 (64bit), NSIS 2.46, and Win32 OpenSSL 0.9.8r. Please
  221 + read the next section for details on what you need.
191 222
192 223 * Q: Can you help me setup X in Cygwin?
193 224
@@ -201,24 +232,21 @@ Frequently Asked Questions
201 232 described as much as I could about the installation of the needed
202 233 tools. Once the tools are installed, building is quite easy. I also
203 234 have tried to make this instruction understandable for people with
204   - limited Unix experience. Cygwin is a whole new environment to some
  235 + limited Unix experience. Cygwin/Msys is a whole new environment to some
205 236 Windows users, why careful explanation of environment variables etc
206 237 seemed to be in place. The short story, for the experienced and
207 238 impatient is:
208 239
209   - * Get and install complete Cygwin (latest)
210   -
211   - * (Buy and) Install Microsoft Visual studio 2005 and SP1 (or higher)
  240 + * Get and install complete Cygwin (latest) or complete MinGW with msys
212 241
213   - * Alternatively install the free MS Visual Studio 2008 Express [msvc++]
214   - and the Windows SDK [32bit-SDK] or [64bit-SDK] depending on the Windows
215   - platform you are running.
  242 + * Install Microsofts Windows SDK 7.1 (and .Net 4)
216 243
217   - * Get and install Sun's JDK 1.4.2
  244 + * Get and install Sun's JDK 1.5.0 or higher
218 245
219 246 * Get and install NSIS 2.01 or higher (up to 2.46 tried and working)
220 247
221   - * Get and install OpenSSL 0.9.7c or higher (up to 1.0.0a tried & working)
  248 + * Get, build and install OpenSSL 0.9.8r or higher (up to 1.0.0a
  249 + tried & working) with static libs.
222 250
223 251 * Get the Erlang source distribution (from
224 252 <http://www.erlang.org/download.html>) and unpack with Cygwin's `tar`.
@@ -251,10 +279,9 @@ Tools you Need and Their Environment
251 279 ------------------------------------
252 280
253 281 You need some tools to be able to build Erlang/OTP on Windows. Most
254   -notably you'll need Cygwin and Microsoft VC++, but you also might want
255   -a Java compiler, the NSIS install system and OpenSSL. Only VC++ costs
256   -money, but then again it costs a lot of money, I know...
257   -Well' here's the list:
  282 +notably you'll need Cygwin or Msys and Microsofts Windows SDK, but
  283 +you also might want a Java compiler, the NSIS install system and
  284 +OpenSSL. Well' here's the list:
258 285
259 286 * Cygwin, the very latest is usually best. Get all the development
260 287 tools and of course all the basic ditto. In fact getting the complete
@@ -263,6 +290,10 @@ Well' here's the list:
263 290 sure *not* to install a Cygwin'ish Java... The Cygwin jar command is
264 291 used but Sun's Java compiler and virtual machine...
265 292
  293 + If you are going to build a 64bit Windows version, you should make
  294 + sure to get MinGWs 64bit gcc installed with cygwin. It's in one of
  295 + the development packages.
  296 +
266 297 URL: <http://www.cygwin.com>
267 298
268 299 Get the installer from the web site and use that to install
@@ -302,72 +333,205 @@ Well' here's the list:
302 333 haven't tried and know of no one that has. I expect
303 334 that you use bash in all shell examples.
304 335
305   -* Microsoft Visual Studio 2005 SP1. Please don't skip the service
306   - pack! The installer might update your environment so that you can run
307   - the `cl` command from the bash prompt, then again it might
308   - not... There is always a BAT file in VC\Bin under the installation
309   - directory (default `C:\Program Files\Microsoft Visual Studio 8`) called
310   - `VCVARS32.BAT`. Either add the environment settings in that file to the
311   - global environment settings in Windows or add the corresponding BASH
312   - environment settings to your `.profile`/`.bashrc`. For example, in my case
313   - I could add the following to `.profile`
314   -
315   - #Visual C++ Root directory as Cygwin style pathname
316   - VCROOT=/cygdrive/c/Program\ Files/Microsoft\ Visual\ Studio 8
317   -
318   - # Visual C++ Root directory as Windows style pathname
319   - WIN_VCROOT="C:\\Program Files\\Microsoft Visual Studio 8"
320   -
321   - # The PATH variable should be Cygwin'ish
322   - PATH=$VCROOT/Common7/IDE:$VCROOT/VC/BIN:$VCROOT/Common7/Tools:\
323   - $VCROOT/Common7/Tools/bin:$VCROOT/VC/PlatformSDK/bin:$VCROOT/SDK/v2.0/bin:\
324   - $VCROOT/VC/VCPackages:$PATH
325   -
326   - # Lib and INCLUDE should be Windows'ish
327   - # Note that semicolon (;) is used to separate Windows style paths but
328   - # colon (:) to separate Cygwin ditto!
329   -
330   - LIBPATH=$WIN_VCROOT\\VC\\ATLMFC\\LIB
331   -
332   - LIB=$WIN_VCROOT\\VC\\ATLMFC\\LIB\;$WIN_VCROOT\\VC\\LIB\;\
333   - $WIN_VCROOT\\VC\\PlatformSDK\\lib\;$WIN_VCROOT\\SDK\\v2.0\\lib
334   -
335   - INCLUDE=$WIN_VCROOT\\VC\\ATLMFC\\INCLUDE\;$WIN_VCROOT\\VC\\INCLUDE\;\
336   - $WIN_VCROOT\\VC\\PlatformSDK\\include
337   -
338   - export PATH LIB INCLUDE
339   -
340   - Make a simple hello world and try to compile it with the `cl` command
341   - from within bash. If that does not work, your environment needs
342   - fixing. Also remember to fix up the PATH environment, especially old
343   - Erlang installations might have inserted quoted paths that Cygwin does
344   - not understand. Remove or correct such paths. There should be no
345   - backslashes in your path environment variable in Cygwin bash, but LIB
346   - and INCLUDE should contain Windows style paths with semicolon,
347   - drive letters and backslashes.
348   -
349   - If you wish to use Visual Studio 2008, a couple things need to be tweaked,
350   - namely the fact that some of the SDK stuff is installed in (by default)
351   - `C:\Program Files\Microsoft SDKs\v6.0A` . Just ensure that that
352   - `C:\Program Files\Microsoft SDKs\v6.0A\Lib` is in `LIB` and
353   - `C:\Program Files\Microsoft SDKs\v6.0A\Include` is in `INCLUDE`. A symptom
354   - of not doing this is errors about finding kernel32.lib and windows.h.
355   -
356   - Additionally, if you encounter errors about mc.exe not being found, you must
357   - install the entire Windows SDK (the partial SDK included in visual studio
358   - apparently does not include it). After installing it you'll want to add
359   - something like: `/c/cygdrive/Program\ Files/Microsoft\ SDKs/v7.0/bin` to
360   - your `PATH` to allow the environment to find mc.exe. The next Visual Studio
361   - (2010) is expected to include this tool.
362   -
363   - Alternatively install the free MS Visual Studio 2008 Express [msvc++] and
364   - the Windows SDK [32bit-SDK] or [64bit-SDK] depending on the Windows
365   - platform you are running, which includes the missing mc.exe message
366   - compiler.
367   -
368   -[msvc++]: http://download.microsoft.com/download/E/8/E/E8EEB394-7F42-4963-A2D8-29559B738298/VS2008ExpressWithSP1ENUX1504728.iso
369   -[32bit-SDK]: http://download.microsoft.com/download/2/E/9/2E911956-F90F-4BFB-8231-E292A7B6F287/GRMSDK_EN_DVD.iso
370   -[64bit-SDK]: http://download.microsoft.com/download/2/E/9/2E911956-F90F-4BFB-8231-E292A7B6F287/GRMSDKX_EN_DVD.iso
  336 +* Alternatively you download MinGW and Msys. You'll find the latest
  337 + installer at:
  338 +
  339 + URL: <http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/>
  340 +
  341 + Make sure to install everything they've got.
  342 +
  343 + To be able to build the 64bit VM, you will also need the 64bit
  344 + MinGW compiler from:
  345 +
  346 + URL: <http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/>
  347 +
  348 + The latest version should do it. Make sure you download the
  349 + `mingw-w64-bin_i686-mingw_<something>.zip`, not a linux
  350 + version. You unzip the package on top of your MinGW installation
  351 + (`c:\MinGW`) and that's it.
  352 +
  353 + Setting up your environment in Msys is similar to setting it up in
  354 + Cygwin.
  355 +
  356 +* Microsofts Windows SDK version 7.1 (corresponding to VC++ 10.0 and
  357 + Visual Studio 2010). You'll find it here:
  358 +
  359 + URL: <http://www.microsoft.com/download/en/details.aspx?id=8279>
  360 +
  361 + but before you install that, you need to have .Net 4 installed,
  362 + you'll find that here:
  363 +
  364 + URL: <http://www.microsoft.com/download/en/details.aspx?id=17851>
  365 +
  366 + Use the web installer for the SDK, at least when I tried
  367 + downloading the whole package as an image, I got SDK 7.0 instead,
  368 + which is not what you want...
  369 +
  370 + There will be a Windows command file in `%PROGRAMFILES%\Mirosoft
  371 + SDKs\Windows\v7.1\Bin\SetEnv.cmd` that set's the appropriate
  372 + environment for a Windows command prompt. This is not appropriate
  373 + for bash, so you'll need to convert it to bash-style environments
  374 + by editing your `.bash_profile`. In my case, where the SDK is
  375 + installed in the default directory and `%PROGRAMFILES%` is
  376 + `C:\Program Files`, the commands for setting up a 32bit build
  377 + environment (on a 64bit or 32bit machine) look like this (in cygwin):
  378 +
  379 + # Some common paths
  380 + C_DRV=/cygdrive/c
  381 + PRG_FLS=$C_DRV/Program\ Files
  382 +
  383 + # nsis
  384 + NSIS_BIN=$PRG_FLS/NSIS
  385 + # java
  386 + JAVA_BIN=$PRG_FLS/Java/jdk1.6.0_16/bin
  387 +
  388 + ##
  389 + ## MS SDK
  390 + ##
  391 +
  392 + CYGWIN=nowinsymlinks
  393 + MVS10="$PRG_FILES/Microsoft Visual Studio 10.0"
  394 + WIN_MVS10="C:\\Program Files\\Microsoft Visual Studio 10.0"
  395 + SDK10="$PRG_FILES/Microsoft SDKs/Windows/v7.1"
  396 + WIN_SDK10="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1"
  397 +
  398 + PATH="$NSIS_BIN:\
  399 + $MVS10/Common7/IDE:\
  400 + $MVS10/Common7/Tools:\
  401 + $MVS10/VC/Bin:\
  402 + $MVS10/VC/Bin/VCPackages:\
  403 + $SDK10/Bin/NETFX 4.0 Tools:\
  404 + $SDK10/Bin:\
  405 + /usr/local/bin:/usr/bin:/bin:\
  406 + /cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:\
  407 + /cygdrive/c/WINDOWS/system32/Wbem:\
  408 + $JAVA_BIN"
  409 +
  410 + LIBPATH="$WIN_MVS10\\VC\\LIB"
  411 +
  412 + LIB="$WIN_MVS10\\VC\\LIB;$WIN_SDK10\\LIB"
  413 +
  414 + INCLUDE="$WIN_MVS10\\VC\\INCLUDE;$WIN_SDK10\\INCLUDE;$WIN_SDK10\\INCLUDE\\gl"
  415 +
  416 + export CYGWIN PATH LIBPATH LIB INCLUDE
  417 +
  418 + If you're using Msys instead, the only thing you need to change is
  419 + the `C_DRV` setting, which would read:
  420 +
  421 + C_DRV=/c
  422 +
  423 + And of course you might need to change `C:\Program Files` etc if
  424 + you're using a non-english version of Windows (XP). Note that in
  425 + later versions of Windows, the national adoptions of the program
  426 + files directories etc are not on the file system but only in the
  427 + explorer, so even if explorer says that your programs reside in
  428 + e.g. `C:\Program`, they might still reside in `C:\Program Files`
  429 + in reality...
  430 +
  431 + If you are building a 64 bit verision of Erlang, you should set up
  432 + PATHs etc a little differently. I use the following script to
  433 + make things work in both Cygwin and Msys:
  434 +
  435 + make_winpath()
  436 + {
  437 + P=$1
  438 + if [ "$IN_CYGWIN" = "true" ]; then
  439 + cygpath -d "$P"
  440 + else
  441 + (cd "$P" && /bin/cmd //C "for %i in (".") do @echo %~fsi")
  442 + fi
  443 + }
  444 +
  445 + make_upath()
  446 + {
  447 + P=$1
  448 + if [ "$IN_CYGWIN" = "true" ]; then
  449 + cygpath "$P"
  450 + else
  451 + echo "$P" | /bin/sed 's,^\([a-zA-Z]\):\\,/\L\1/,;s,\\,/,g'
  452 + fi
  453 + }
  454 +
  455 + # Some common paths
  456 + if [ -x /usr/bin/msysinfo ]; then
  457 + # Without this the path conversion won't work
  458 + COMSPEC='C:\Windows\SysWOW64\cmd.exe'
  459 + MSYSTEM=MINGW32
  460 + export MSYSTEM COMSPEC
  461 + IN_CYGWIN=false
  462 + else
  463 + CYGWIN=nowinsymlinks
  464 + export CYGWIN
  465 + IN_CYGWIN=true
  466 + fi
  467 +
  468 + if [ "$IN_CYGWIN" = "true" ]; then
  469 + PATH=/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:\
  470 + /cygdrive/c/windows/system32:/cygdrive/c/windows:/cygdrive/c/windows/system32/Wbem
  471 + else
  472 + PATH=/usr/local/bin:/mingw/bin:/bin:/c/Windows/system32:/c/Windows:\
  473 + /c/Windows/System32/Wbem
  474 + fi
  475 +
  476 + if [ "$IN_CYGWIN" = "true" ]; then
  477 + C_DRV=/cygdrive/c
  478 + else
  479 + C_DRV=/c
  480 + fi
  481 +
  482 + PRG_FLS64=$C_DRV/Program\ Files
  483 + PRG_FLS32=$C_DRV/Program\ Files\ \(x86\)
  484 + VISUAL_STUDIO_ROOT32=$PRG_FLS32/Microsoft\ Visual\ Studio\ 10.0
  485 + MS_SDK_ROOT64=$PRG_FLS64/Microsoft\ SDKs/Windows/v7.1
  486 +
  487 + # Okay, now mangle the paths and get rid of spaces by using short names
  488 + WIN_VCROOT32=`make_winpath "$VISUAL_STUDIO_ROOT32"`
  489 + VCROOT32=`make_upath $WIN_VCROOT32`
  490 + WIN_SDKROOT64=`make_winpath "$MS_SDK_ROOT64"`
  491 + SDKROOT64=`make_upath $WIN_SDKROOT64`
  492 + WIN_PROGRAMFILES32=`make_winpath "$PRG_FLS32"`
  493 + PROGRAMFILES32=`make_upath $WIN_PROGRAMFILES32`
  494 +
  495 + WIN_PROGRAMFILES64=`make_winpath "$PRG_FLS64"`
  496 + PROGRAMFILES64=`make_upath $WIN_PROGRAMFILES64`
  497 +
  498 + # nsis
  499 + NSIS_BIN=$PROGRAMFILES32/NSIS
  500 + # java
  501 + JAVA_BIN=$PROGRAMFILES64/Java/jdk1.7.0_01/bin
  502 +
  503 + ## The PATH variable should be Unix'ish
  504 + VCPATH=$VCROOT32/Common7/IDE:$VCROOT32/VC/BIN/amd64:$VCROOT32/Common7/Tools:\
  505 + $VCROOT32/VC/VCPackages:$SDKROOT64/bin/NETFX4~1.0TO/x64:$SDKROOT64/bin/x64:\
  506 + $SDKROOT64/bin
  507 +
  508 + ## Microsoft SDK libs
  509 +
  510 + LIBPATH=$WIN_VCROOT32\\VC\\LIB\\amd64
  511 + LIB=$WIN_VCROOT32\\VC\\LIB\\amd64\;$WIN_SDKROOT64\\LIB\\X64
  512 + INCLUDE=$WIN_VCROOT32\\VC\\INCLUDE\;$WIN_SDKROOT64\\include\;\
  513 + $WIN_SDKROOT64\\include\\gl
  514 +
  515 + # Put nsis, c compiler and java in path
  516 + PATH=$NSIS_BIN:$VCPATH:$PATH:$JAVA_BIN
  517 +
  518 + # Make sure LIB and INCLUDE is available for others
  519 + export PATH LIBPATH LIB INCLUDE
  520 +
  521 + All this is derived from the SetEnv.cmd command file mentioned
  522 + earlier. The bottom line is to set the PATH so that NSIS and
  523 + Microsoft SDK is found before the Msys/Cygwin tools and that Java
  524 + is last in the PATH.
  525 +
  526 + Make a simple hello world (maybe one that prints out
  527 + `sizeof(void *)`) and try to compile it with the `cl` command from within
  528 + bash. If that does not work, your environment needs fixing. Also
  529 + remember to fix up the PATH environment, especially old Erlang
  530 + installations might have inserted quoted paths that Cygwin/Msys
  531 + does not understand. Remove or correct such paths. There should be
  532 + no backslashes in your path environment variable in Cygwin bash,
  533 + but LIB and INCLUDE should contain Windows style paths with
  534 + semicolon, drive letters and backslashes.
371 535
372 536 * Sun's Java JDK 1.5.0 or higher. Our Java code (jinterface, ic) is
373 537 written for JDK 1.5.0. Get it for Windows and install it, the JRE is
@@ -378,11 +542,11 @@ Well' here's the list:
378 542
379 543 Add javac *LAST* to your path environment in bash, in my case this means:
380 544
381   - PATH="$PATH:/cygdrive/c/Program Files/Java/jdk1.5.0_17/bin"
  545 + `PATH="$PATH:/cygdrive/c/Program Files/Java/jdk1.5.0_17/bin"`
382 546
383 547 No `CLASSPATH` or anything is needed. Type `javac` at the bash prompt
384 548 and you should get a list of available Java options. Make sure by
385   - typing `which java` that you use the Java you installed. Note however that
  549 + typing `type java` that you use the Java you installed. Note however that
386 550 Cygwin's `jar.exe` is used, that's why the JDK bin-directory should be
387 551 added last in the `PATH`.
388 552
@@ -402,29 +566,75 @@ Well' here's the list:
402 566 type makensis at the bash prompt and you should get a list of options
403 567 if everything is OK.
404 568
405   -* OpenSSL for Windows. This is if you want the SSL and crypto
406   - applications to compile (and run). Go to <http://www.openssl.org>, click
407   - on the `Related` link and then on the `Binaries` link (upper right
408   - corner of the page last time I looked), you can then reach the
409   - "Shining Lights Productions" Web site for Windows binaries
410   - distributions. Get the latest 32-bit installer, or use 0.9.7c if you get
411   - trouble with the latest, and install to C:\OpenSSL which is where the
412   - Makefiles are expecting to find it. It's a nifty installer. The rest should
413   - be handled by `configure`, you needn't put anything in the path or anything.
414   -
415   - If you want to build openssl for windows yourself (which might be
416   - possible, as you wouldn't be reading this if you weren't a
417   - compile-it-yourself person), you either have to put the resulting
418   - DLL's in your path or in the windows system directory and either
419   - specify where you put the includes etc with the configure-parameter
420   - `--with-ssl=<cygwin path to the root>` or put your installation directly
421   - under `c:\OpenSSL`. The directory structure under the installation root
422   - for OpenSSL is expected to be one with subdirectories named `include`,
423   - `bin` and `lib`, possibly with a `VC` subdirectory of `lib` containing
424   - the actual `.lib` files. Note that the cygwin distributed OpenSSL cannot be
425   - used, it results in cygwin depending binaries and it has unix style
426   - archives (`.a`, not `.lib`).
  569 +* OpenSSL. This is if you want the SSL and crypto applications to
  570 + compile (and run). There are prebuilt binaries available, but I
  571 + strongly recommend building this yourself. It's quite easy.
  572 +
  573 + First get the source from
  574 +
  575 + URL: <http://openssl.org/source/>
  576 +
  577 + I would recommend using 0.9.8r.
  578 +
  579 + Download the tar file and unpack it (using your bash prompt) into
  580 + a directory of your choise.
  581 +
  582 + You will need a Windowish Perl for the build. ActiveState has one:
  583 +
  584 + URL: <http://www.activestate.com/activeperl/downloads>
  585 +
  586 + Download and install that. Disable options to associate it with
  587 + the .pl suffix and/or adding things to PATH, they are not needed.
  588 +
  589 + Now fire up the Microsoft Windows SDK command prompt in RELEASE
  590 + mode for the architecture you are going to build. The easiest is
  591 + to copy the shortcut from the SDKs start menu item and edit the
  592 + command line in the shortcut (Right click->Properties) to end with
  593 + `/Release`. Make sure the banner when you double click your
  594 + shortcut (the text in the resulting command window) says
  595 + `Targeting Windows XP x64 Release` if you are going to do a 64 bit
  596 + build and `Targeting Windows XP x86 Release` if you are building a
  597 + 32 bit version.
  598 +
  599 + Now cd to where you unpacked the OpenSSL source using your Release
  600 + Windows command prompt (it should be on the same drive as where
  601 + you are going to install it if everything is to work smothly).
  602 +
  603 + `C:\> cd <some dir>`
  604 +
  605 + Add ActiveState (or some other windows perl, not cygwins) to your PATH:
  606 +
  607 + `C:\...\> set PATH=C:\Perl\bin;%PATH%`
  608 +
  609 + Configure OpenSSL for 32 bit:
427 610
  611 + `C:\...\> perl Configure VC-WIN32 --prefix=/OpenSSL`
  612 +
  613 + Or for 64 bit:
  614 +
  615 + `C:\...\> perl Configure VC-WIN64A --prefix=/OpenSSL-Win64`
  616 +
  617 + Do some setup (for 32 bit):
  618 +
  619 + `C:\...\> ms\do_win32`
  620 +
  621 + The same for 64 bit:
  622 +
  623 + `C:\...\> ms\do_win64a`
  624 +
  625 + Then build static libraries and install:
  626 +
  627 + `C:\...\> nmake -f ms\nt.mak`
  628 + `C:\...\> nmake -f ms\nt.mak install`
  629 +
  630 + That's it - you now have your perfectly consistent static build of
  631 + openssl. If you want to get rid of any possibly patented
  632 + algorithms in the lib, just read up on the OpenSSL FAQ and follow
  633 + the instructions.
  634 +
  635 + The installation locations chosen are where configure will look
  636 + for OpenSSL, so try to keep them as is.
  637 +
428 638 * Building with wxWidgets. Download wxWidgets-2.8.9 or higher patch
429 639 release (2.9.\* is a developer release which currently does not work
430 640 with wxErlang).
@@ -473,6 +683,9 @@ Well' here's the list:
473 683 erlang system without gs (which might be okay as you probably will use
474 684 wx anyway).
475 685
  686 + Note that there is no special 64bit version of TCL/TK needed, you
  687 + can use the 32bit program even for a 64bit build.
  688 +
476 689 The Shell Environment
477 690 ---------------------
478 691
@@ -500,6 +713,12 @@ the ksh variant:
500 713 $ cd $ERL_TOP
501 714 $ eval $(./otp_build env_win32)
502 715
  716 +If you are building a 64 bit version, you supply `otp_build` with an architecture parameter:
  717 +
  718 + $ cd $ERL_TOP
  719 + $ eval `./otp_build env_win32 x64`
  720 +
  721 +
503 722 This should do the final touch to the environment and building should
504 723 be easy after this. You could run `./otp_build env_win32` without
505 724 `eval` just to see what it does, and to see that the environment it
@@ -509,10 +728,11 @@ style short names instead), the variables `OVERRIDE_TARGET`, `CC`, `CXX`,
509 728 `$ERL_TOP/erts/etc/win32/cygwin_tools/vc` and
510 729 `$ERL_TOP/erts/etc/win32/cygwin_tool` are added first in the PATH.
511 730
512   -Try now a `which erlc`. That should result in the erlc wrapper script
  731 +Try now a `type erlc`. That should result in the erlc wrapper script
513 732 (which does not have the .sh extension, for reasons best kept
514   -untold...). It should reside in `$ERL_TOP/erts/etc/win32/cygwin_tools`.
515   -You could also try `which cc.sh`, which `ar.sh` etc.
  733 +untold...). It should reside in `$ERL_TOP/erts/etc/win32/cygwin_tools`
  734 +or `$ERL_TOP/erts/etc/win32/msys_tools`. You could also try `which
  735 +cc.sh`, which `ar.sh` etc.
516 736
517 737 Now you're ready to build...
518 738
@@ -520,8 +740,8 @@ Now you're ready to build...
520 740 Building and Installing
521 741 -----------------------
522 742
523   -Now it's assumed that you have executed `` eval `./otp_build env_win32` ``
524   -for this particular shell...
  743 +Now it's assumed that you have executed `` eval `./otp_build env_win32` `` or
  744 +`` eval `./otp_build env_win32 x64` `` for this particular shell...
525 745
526 746 Building is easiest using the `otp_build` script. That script takes care
527 747 of running configure, bootstrapping etc on Windows in a simple
@@ -613,6 +833,13 @@ Lets get into more detail:
613 833 $ release/win32/otp_win32_%OTP-REL% /S
614 834 ...
615 835
  836 + or
  837 +
  838 + $ cd $ERL_TOP
  839 + $ release/win32/otp_win64_%OTP-REL% /S
  840 + ...
  841 +
  842 +
616 843 and after a while Erlang/OTP-%OTP-REL% will have been installed in
617 844 `C:\Program Files\erl%ERTS-VSN%\`, with shortcuts in the menu etc.
618 845
@@ -735,6 +962,22 @@ Remember that:
735 962
736 963 That's basically all you need to get going.
737 964
  965 +Using GIT
  966 +---------
  967 +
  968 +You might want to check out versions of the source code from GitHUB. That is possible directly in cygwin, but not in Msys. There is a project MsysGIT:
  969 +
  970 +URL:<http://code.google.com/p/msysgit/>
  971 +
  972 +that makes a nice Git port. The msys prompt you get from MsysGIT is
  973 +however not compatible with the full version from MinGW, so you will
  974 +need to check out files using MsysGITs command prompt and then switch
  975 +to a common Msys command prompt for building. Also all test suites
  976 +cannot be built as MsysGIT/Msys does not handle symbolic links. To
  977 +build test suites on Windows, you will need Cygwin for now. Hopefully
  978 +all symbolic links will disappear from our repository soon and this
  979 +issue will disappear.
  980 +
738 981 Final Words
739 982 -----------
740 983 My hope is that the possibility to build the whole system on Windows
@@ -752,11 +995,15 @@ be good. The idea to do this came from his work, so credit is well
752 995 deserved.
753 996
754 997 Of course this would have been completely impossible without the
755   -excellent Cygwin package. The guys at Cygnus solutions and Redhat
756   -deserves a huge THANKS! as well as all the other people in the free
757   -software community who have helped in creating the magnificent
  998 +excellent Cygwin. The guys at Cygnus solutions and
  999 +Redhat deserves a huge THANKS! as well as all the other people in the
  1000 +free software community who have helped in creating the magnificent
758 1001 software that constitutes Cygwin.
759 1002
  1003 +Also the people developing the alternative command prompt Msys anfd
  1004 +the MinGW compiler are worth huge THANKS! The 64bit port would have
  1005 +been impossible without the 64bit MinGW compiler.
  1006 +
760 1007 Good luck and Happy Hacking,
761 1008 Patrik, OTP
762 1009
6 erts/emulator/beam/erl_alloc.c
@@ -1095,7 +1095,7 @@ get_kb_value(char *param_end, char** argv, int* ip)
1095 1095 char *param = argv[*ip]+1;
1096 1096 char *value = get_value(param_end, argv, ip);
1097 1097 errno = 0;
1098   - tmp = (Sint) strtol(value, &rest, 10);
  1098 + tmp = (Sint) ErtsStrToSint(value, &rest, 10);
1099 1099 if (errno != 0 || rest == value || tmp < 0 || max < ((Uint) tmp))
1100 1100 bad_value(param, param_end, value);
1101 1101 if (max == (Uint) tmp)
@@ -1112,7 +1112,7 @@ get_byte_value(char *param_end, char** argv, int* ip)
1112 1112 char *param = argv[*ip]+1;
1113 1113 char *value = get_value(param_end, argv, ip);
1114 1114 errno = 0;
1115   - tmp = (Sint) strtol(value, &rest, 10);
  1115 + tmp = (Sint) ErtsStrToSint(value, &rest, 10);
1116 1116 if (errno != 0 || rest == value || tmp < 0)
1117 1117 bad_value(param, param_end, value);
1118 1118 return (Uint) tmp;
@@ -1126,7 +1126,7 @@ get_amount_value(char *param_end, char** argv, int* ip)
1126 1126 char *param = argv[*ip]+1;
1127 1127 char *value = get_value(param_end, argv, ip);
1128 1128 errno = 0;
1129   - tmp = (Sint) strtol(value, &rest, 10);
  1129 + tmp = (Sint) ErtsStrToSint(value, &rest, 10);
1130 1130 if (errno != 0 || rest == value || tmp < 0)
1131 1131 bad_value(param, param_end, value);
1132 1132 return (Uint) tmp;
8 erts/emulator/beam/sys.h
@@ -256,6 +256,7 @@ typedef unsigned int Eterm;
256 256 typedef unsigned int Uint;
257 257 typedef int Sint;
258 258 #define ERTS_SIZEOF_ETERM SIZEOF_INT
  259 +#define ErtsStrToSint strtol
259 260 #else
260 261 #error Found no appropriate type to use for 'Eterm', 'Uint' and 'Sint'
261 262 #endif
@@ -288,6 +289,7 @@ typedef long Sint;
288 289 #define SWORD_CONSTANT(Const) Const##L
289 290 #define UWORD_CONSTANT(Const) Const##UL
290 291 #define ERTS_SIZEOF_ETERM SIZEOF_LONG
  292 +#define ErtsStrToSint strtol
291 293 #elif SIZEOF_VOID_P == SIZEOF_INT
292 294 typedef unsigned int Eterm;
293 295 typedef unsigned int Uint;
@@ -295,6 +297,7 @@ typedef int Sint;
295 297 #define SWORD_CONSTANT(Const) Const
296 298 #define UWORD_CONSTANT(Const) Const##U
297 299 #define ERTS_SIZEOF_ETERM SIZEOF_INT
  300 +#define ErtsStrToSint strtol
298 301 #elif SIZEOF_VOID_P == SIZEOF_LONG_LONG
299 302 typedef unsigned long long Eterm;
300 303 typedef unsigned long long Uint;
@@ -302,6 +305,11 @@ typedef long long Sint;
302 305 #define SWORD_CONSTANT(Const) Const##LL
303 306 #define UWORD_CONSTANT(Const) Const##ULL
304 307 #define ERTS_SIZEOF_ETERM SIZEOF_LONG_LONG
  308 +#if defined(__WIN32__)
  309 +#define ErtsStrToSint _strtoi64
  310 +#else
  311 +#define ErtsStrToSint strtoll
  312 +#endif
305 313 #else
306 314 #error Found no appropriate type to use for 'Eterm', 'Uint' and 'Sint'
307 315 #endif
12 erts/test/ethread_SUITE_data/ethread_tests.c
@@ -82,6 +82,7 @@ static void
82 82 print_eol(void)
83 83 {
84 84 fprintf(stderr, EOL);
  85 + fflush(stderr);
85 86 }
86 87
87 88 static void print_line(char *frmt,...)
@@ -826,6 +827,7 @@ detached_thread_test(void)
826 827 * Tests
827 828 */
828 829 #define MTT_TIMES 10
  830 +#define MTT_HARD_LIMIT (80000)
829 831
830 832 static int mtt_terminate;
831 833 static ethr_mutex mtt_mutex;
@@ -866,14 +868,20 @@ mtt_create_join_threads(void)
866 868 while (1) {
867 869 if (ix >= no_tids) {
868 870 no_tids += 100;
  871 + if (no_tids > MTT_HARD_LIMIT) {
  872 + print_line("Hit the hard limit on number of threads (%d)!",
  873 + MTT_HARD_LIMIT);
  874 + break;
  875 + }
869 876 tids = (ethr_tid *) realloc((void *)tids, sizeof(ethr_tid)*no_tids);
870 877 ASSERT(tids);
871 878 }
872 879 res = ethr_thr_create(&tids[ix], mtt_thread, NULL, NULL);
873   - if (res != 0)
  880 + if (res != 0) {
874 881 break;
  882 + }
875 883 ix++;
876   - } while (res == 0);
  884 + }
877 885
878 886 no_threads = ix;
879 887
0  test
No changes.

0 comments on commit f20b520

Please sign in to comment.
Something went wrong with that request. Please try again.