[Draft] Win32 Build Instructions

201 views
Skip to first unread message

Pavan

unread,
Mar 16, 2013, 10:46:34 AM3/16/13
to juli...@googlegroups.com
Well, I've successfully built win32 package for Julia (from github master) today. Here is how I made it work:
  1. My Environment: Lenovo Thinkpad x220, Core i5 2540M, 8 GB, Win 7 64bit Professional Version
  2. Download MinGW+ MSYS Innosetup installer from this url 
  3. Run this installer to choose from options: Destination Directory (Default- C:\MinGW), MinGW compiler suite (selected C, C++, Fortran), MSYS Basic System (selected), MinGW Developer Toolkit packages (selected). Based on your connection speed, it may take a while to download packages.
  4. Set path by choosing ControlPanel > System and Security > System > Advanced System Settings > (Advanced) Environment Variables > Path and add to the end of line: C:\MinGW\bin;C:\MinGW\msys\1.0\bin;
  5. At command prompt, type - "mingw-get install wget" - to install wget
  6. Download Python-2.6.7_msys.7z from here and extract files (using 7-Zip) to respective locations in C:\MinGw\msys\1.0 path, i.e., bin, lib, libs, to get Python 2.6.7 
  7. Download Julia as a zip file (or) git clone the repo - git clone https://github.com/JuliaLang/julia.git
  8. I had to make couple of changes before doing a "make here"
      1. Change deps/Makefile -> Line 780: Comment out tar zxf $< and added a new line 778: tar zxf arpack-ng_$(ARPACK_VER) -> as I was getting errors related to arpack/depcomp. I haven't tried the other suggestion of using 7-zip to delete "depcomp" and proceed further. 
      2. Add the following line -  _CRTIMP int __cdecl _resetstkoflw (void); - to C:\MinGW\include\malloc.h at Line 76. This helped in tackling _resetstkoflw errors being showed in compiling codegen.cpp
  9. Do a "make" from the julia top directory to create julia executable in usr/bin directory
  10. Add Julia  to System Path and start using it! Here is my console pic: http://imgur.com/qMOGC5i 

Would welcome your suggestions and comments here. I'll try for a win64 build some time next week.

/Pavan

J Luis

unread,
Mar 16, 2013, 11:06:48 AM3/16/13
to juli...@googlegroups.com
Pavan

For the 64 build I had to do what you describe in 8.2 as well. The rest is equal. Install mingw64 and run the make from a shell where it comes first in the path.
I still can't figure out why my regular Windows python persists in poping out first and raising the error of unknown symbol in libstd++-6.dll, even  though the right version (from mingw) is located higher in path order.

Joaquim

Eric Davies

unread,
Mar 17, 2013, 1:05:19 PM3/17/13
to juli...@googlegroups.com
Thanks to both of you! Luckily Julia Studio allows me to run 32-bit Julia on Windows without building from source, but up until now I've not known what to do for 64-bit Windows. I got to the libstd problem and wasn't sure how to proceed--good to know there is a solution.

WANG

unread,
Mar 23, 2013, 12:48:44 AM3/23/13
to juli...@googlegroups.com
8.1 is fixed according to http://forge.scilab.org/index.php/p/arpack-ng/source/tree/master/CHANGES in their next version 3.1.3

在 2013年3月16日星期六UTC+8下午10时46分34秒,Pavan写道:

WANG

unread,
Mar 23, 2013, 12:52:49 AM3/23/13
to juli...@googlegroups.com
I think we can use "*.bat" files in "contrib/windows/" instead of No. 10 here.
It would be nice if you could add this note to github. It helps a lot

在 2013年3月16日星期六UTC+8下午10时46分34秒,Pavan写道:

Jeff Bezanson

unread,
Mar 23, 2013, 2:06:19 AM3/23/13
to juli...@googlegroups.com
Thanks, this is very helpful! Would it make sense to add the function
prototype in 8.2 to our code?

WANG

unread,
Mar 23, 2013, 5:57:32 AM3/23/13
to juli...@googlegroups.com
Cheers!
I followed the instruction and build one on my Win7 32-bit computer.

In order to get rid of 8.1 , I downloaded the source code by cloning the git repository:
rename the folder to arpack-ng_3.1.2 and do "tar zcvf arpack-ng_3.1.2.tar.gz arpack-ng_3.1.2"
mv the tar.gz file to /deps/

在 2013年3月16日星期六UTC+8下午10时46分34秒,Pavan写道:

Viral Shah

unread,
Mar 23, 2013, 8:54:18 AM3/23/13
to juli...@googlegroups.com
I have sent a message to Sylvestre Ledru, who maintains arpack-ng.

-viral

Pavan

unread,
Mar 24, 2013, 3:16:01 AM3/24/13
to juli...@googlegroups.com
Thanks Wang!

Yes, arpack-ng_3.1.2 doesn't work with "tar"  (8.1 doesn't work) and it seems there are two alternatives :
  1. use unreleased version 3.1.3 (CHANGES here) or 
  2. deprecated 3.1.1 version (change deps/Versions.make -> ARPACK_VER=3.1.1)

/Pavan

Pavan

unread,
Mar 24, 2013, 3:17:54 AM3/24/13
to juli...@googlegroups.com
Jeff - This function prototype needs to be part of malloc.h which gets disrtributed with MinGW. Are you suggesting that we have a patch for malloc.h in Julia?

/Pavan

Pavan

unread,
Mar 24, 2013, 3:20:01 AM3/24/13
to juli...@googlegroups.com
Viral - Would it make sense if we build arpack from git repo through deps/Makefile?

/Pavan

Viral Shah

unread,
Mar 24, 2013, 9:13:40 AM3/24/13
to juli...@googlegroups.com
arpack-ng will have a new release (3.1.3) in a week or so. Best to just wait for that.

Patching MingW's malloc.h seems really sketchy. How do we fix that?

-viral

Jameson

unread,
Mar 24, 2013, 9:45:57 PM3/24/13
to juli...@googlegroups.com
We can suggest people use newer versions of MinGW. This has the simultaneous benefit of compiling 64 bit code, and not being over 5 years behind (check the time stamps on the websites if you don't believe me). The only downside is it is slightly harder to install, since it appears to be meant to be used on linux primarily. Although on the plus side, steps 2-6 & 8 are covered by untar-ing two files.

Keno and I agreed back when 3.1.2 was first released that wasn't much point in complicating the ARPACK makefile dependency to handle this easy manual fix. We could mirror a binary with the mistake removed, but with the next release imminent now, it won't really help anyone.
Reply all
Reply to author
Forward
0 new messages