LLVM / JIT Support in Mac OS X

Just In Time (JIT) compiler using LLVM backend is an experimental feature in Octave, which will make Octave capable of compiling during run-time. It can significantly speed up loops and even other parts of the program as well. The development of JIT for Octave is beeyond the scope of my project, and at it is a separate GSoC project of some other student. Here is how I added JIT support in the Octave build.

Natively compiling LLVM using MXE and then using it to compile Octave is the standard way to get JIT support. This process has been followed to compile Octave for MinGW. However I saw that there are many discrepancies while following this process in Mac OS X. If you read the previous post in this blog, I had stated about the problems I had faced with dynamic library path names. I saw that there is a similar problem with the llvm-config utility and it turned out to be a self-referential symbolic link.
This is the result of ls -l ./usr/bin/llvm-config
lrwxr-xr-x  1 root  staff  48 Sep 11 02:29 ./usr/bin/llvm-config -> /Users/mac6-user1/mxe-octave/usr/bin/llvm-config

On a Mac OS X system, there is no special need to compile LLVM separately because it is the default compiler present. The llvm-config utility happens to be installed in the path /opt/local/libexec/llvm-3.3/bin/llvm-config. I added this path in the environment variable LLVM_CONFIG and explicitly specified the --enable-jit option in the configure and Octave successfully compiled with JIT. Here are the configure details.

LLVM CPPFLAGS:               -isystem /opt/local/libexec/llvm-3.3/include
LLVM LDFLAGS:                -L/opt/local/libexec/llvm-3.3/lib
LLVM libraries:              -lLLVMInstrumentation -lLLVMArchive -lLLVMLinker -lLLVMIRReader -lLLVMBitReader -lLLVMAsmParser -lLLVMDebugInfo -lLLVMOption -lLLVMipo -lLLVMVectorize -lLLVMBitWriter -lLLVMTableGen -lLLVMSystemZCodeGen -lLLVMSystemZAsmParser -lLLVMSystemZDesc -lLLVMSystemZInfo -lLLVMSystemZAsmPrinter -lLLVMHexagonCodeGen -lLLVMHexagonAsmPrinter -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc -lLLVMNVPTXInfo -lLLVMNVPTXAsmPrinter -lLLVMMBlazeDisassembler -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeAsmPrinter -lLLVMMBlazeAsmParser -lLLVMMBlazeInfo -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMXCoreAsmPrinter -lLLVMMipsDisassembler -lLLVMMipsCodeGen -lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc  -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMAArch64Disassembler -lLLVMAArch64CodeGen -lLLVMAArch64AsmParser -lLLVMAArch64Desc -lLLVMAArch64Info -lLLVMAArch64AsmPrinter -lLLVMAArch64Utils -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCAsmPrinter -lLLVMPowerPCAsmParser -lLLVMPowerPCInfo -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInterpreter -lLLVMMCJIT -lLLVMJIT -lLLVMCodeGen -lLLVMObjCARCOpts -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport

JIT compiler for loops:             yes

The final evaluation is close and since I have already a working build of Octave for Mac OS X, I will push all my code to my repo mxe-octave-anirudha now.

Support for sparse matrices

It took me some time to figure out a way to enable functionality for sparse matrices in Octave. Initially, the configure script was unable to find the location where the sparse matrix libraries are present. I had to specify the paths in src/octave.mk like this:

--with-umfpack-includedir='$(HOST_INCDIR)' \
--with-umfpack-libdir='$(HOST_LIBDIR)' \
--with-cxsparse-includedir='$(HOST_INCDIR)' \
--with-cxsparse-libdir='$(HOST_LIBDIR)' \

Manually specifying the paths worked, and Octave was built with the appropriate CPPFLAGS and LDFLAGS. The configure details of the libraries which add the functionality of sparse matrices in Octave are given below:

AMD CPPFLAGS: -I/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/include
AMD LDFLAGS: -L/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/lib
AMD libraries: -lamd

CAMD CPPFLAGS: -I/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/include
CAMD LDFLAGS: -L/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/lib
CAMD libraries: -lcamd

CCOLAMD CPPFLAGS: -I/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/include
CCOLAMD LDFLAGS: -L/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/lib
CCOLAMD libraries: -lccolamd

COLAMD CPPFLAGS: -I/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/include
COLAMD LDFLAGS: -L/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/lib
COLAMD libraries: -lcolamd

CXSPARSE CPPFLAGS: -I/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/include
CXSPARSE LDFLAGS: -L/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/lib
CXSPARSE libraries: -lcxsparse

UMFPACK CPPFLAGS: -I/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/include
UMFPACK LDFLAGS: -L/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/lib
UMFPACK libraries: -lumfpack

CHOLMOD CPPFLAGS: -I/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/include
CHOLMOD LDFLAGS: -L/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/lib
CHOLMOD libraries: -lcholmod

Even if Octave is built this way, you are likely to see some errors like the one below:

dyld: Library not loaded: libcholmod.so
Referenced from: /Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/bin/octave
Reason: image not found
Trace/BPT trap: 5

The hint to solve this came from Alexander Hansen. He suggested that /Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/bin/octave wants to link “libcholmod.so”, which would be /Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/lib/libcholmod.so . When I did otool -L /Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/bin/octave, I saw that the sparse matrix libraries like libcholmod.so and friends had just the names in the list of links, which should have been actual absolute paths. “otool” is a command that displays specified parts of object files or libraries.

One solution which seemed valid to me was to change the install names of these dynamic shared libraries. Fortunately there is already a tool in Mac OS X called “install_name_tool” to do this job. The dynamic library libcholmod.so can be made visible to octave by the following command:

install_name_tool -change "libcholmod.so" "/Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/lib/libcholmod.so" /Users/mac6-user1/mxe/mxe-octave-anirudha/usr/x86_64-apple-darwin12.2.1/bin/octave

I also had to recompile Octave with a new LDFLAG in order to reserve enough space for changing all dynamic shared library paths. I added this in the src/octave.mk file:
LDFLAGS=-Wl,-headerpad_max_install_names

There are a few other libraries which have this error, and can be fixed by following the above procedure. Finally when all the install names in the faulty libraries/object files are fixed, Octave is ready to be launched.

Java Support in Mac OS X

For Octave to be compiled with Java support enabled we need to have some requisite JDK installation and header files available in the host system where Octave is built. For cross-mingw compilation, it was fairly difficult. You can refer to the previous posts on this blog related to adding Java support for more information.

For Mac OS X, I installed the latest Oracle Java SE Development Kit from Oracle’s website. You need to accept the Oracle Binary Code License Agreement for Java SE to download the software.
checking for java... /usr/bin/java
checking for javac... /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/javac
checking for jar... /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/jar
checking for Java version... 1.6.0_51
checking for libjvm.dylib... /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries
checking for include file <jni.h>... /System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers

This is the platform specific jni_md.h file  used by configure. It comes with the JDK installation for Mac OS X.

The following are extracts of the configure details of Octave:

Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Java JVM path: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries
Java CPPFLAGS: -I/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/include -I/System/Library/Frameworks/JavaVM.framework/Home/include -I/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Headers -I/System/Library/Frameworks/Jav$
Java libraries: -framework JavaVM



Build Java interface: yes


Reusing MXE Octave to build Octave for Mac OS X

It is interesting to see that MXE Octave has become more capable than the original MXE. It can not only be used to cross-compile Octave, but is now capable of natively compiling Octave (mingw and msvc) as well. Since I have used MXE Octave to complete the first half of the project to cross-compile Octave to Windows, it is wise to re-use the same to natively compile Octave under Mac OS X. The builds, as far as I can say are supported on a range of platforms. This wouldn’t have been possible if I were to build an app bundle.

On the Mac I am using for my work, config.guess returns x86_64-apple-darwin12.2.1. Also the command gcc -dumpmachine returns i686-apple-darwin11. Hence the target I am using to compile Octave is i686-apple-darwin11. Using x86_64-apple-darwin12.2.1 as the target results in many errors like "Undefined symbols for architecture x86_64: "

I am writing some of the things I did to build a very basic version of Octave (lacks support for many libraries) for Mac OS X using my repo mxe-octave-anirudha.

• Since GCC doesn’t work for native builds yet, so I used the system GCC provided by XCode. The variable USE_SYSTEM_GCC is automatically set to yes if we pass the --enable-native-build option to configure.
• Till now I have compiled everything using the cross compile configurations making changes wherever required. On my system, the configure was unable to find the Fortran compiler. I had to manually add the path MXE_F77 := /opt/local/bin/gfortran-mp-4.7 in the Makefile as well as add set(CMAKE_Fortran_COMPILER /opt/local/bin/gfortran-mp-4.7) in usr/x86_64-apple-darwin12.2.1/share/cmake/mxe-conf.cmake. This was necessary for packages like BLAS, Lapack, and Octave. I will later commit a patch to detect the Fortran compiler path automatically.
• The compilation is likely to stop when dbus is built. This is because dbus needs root privileges during build, else it will throw “Permission denied” error. Running sudo make dbus works fine.
• Since we are building for a 64-bit target, we must use ./Configure darwin64-x86_64-cc instead of ./config to build package openssl.
• Compiling Qt succeeds but MXE_PKG_CONFIG is unable to extract the QT_LDFLAGS and QT_LIBS. It is perhaps the reason why the build of Octave fails when GUI is enabled. The variable (PKG)_CONFIGURE_ENV must be set correctly for Mac OS X. To get past Qt build I used the MSVC configurations. The command pkg-config --libs-only-L ./usr/x86_64-apple-darwin12.2.1/lib/pkgconfig/QtCore.pc returns nothing, which might be the reason why Octave doesn’t build with GUI.
• I had to disable Readline support by adding --disable-readline in src/octave.mk. Since my repo uses Octave 3.7.5 I had to add the patch to make ctrl-c abort the actual octave command in linux (bug #37672). In Octave 3.7.6, the patch has been merged, so it must be removed from the src folder.

After the build completed, Octave was configured for “x86_64-apple-darwin12.2.1”. I will be pushing the changesets to my repo soon. Octave can be launched by doing  ./usr/x86_64-apple-darwin12.2.1/bin/octave. It will launch the CLI version of Octave since GUI was disabled during build. Here is a screenshot.

Octave for Mac OS X

Having passed the mid-term evaluations of GSoC, it is time to start my work on making Octave available for Mac OS X. I have never used a Mac, so I will utilize the coming days in studying about the build system of Mac OS X. Thanks to the Director of our university for giving me access to a Mac Pro at Mobile Computing Lab. I have full physical access to it till 5pm. After that, I am permitted to use the machine through TeamViewer/SSH/Telnet (I haven’t figured it out yet).

At this moment, creating a new Mac OS X App Bundle using Macports seems most practical to me. App bundles are directory hierarchies, with the top-level directory having a name that ends with a .app extension. Using Macports, we can produce binary packages with standalone installers that are pre-compiled. The final app bundle doesn’t require Macports to be installed on the target system. All the dependencies will be a part of the bundle. A dmg disk image of the fiinal package is also desirable. The .app bundle can also be run directly like any normal app without any installation. This is just like executing the file bin/octave.exe in Windows version of Octave, where all the dependencies are pre-built.

There is a real app bundle already existing for Octave 3.2 by Thomas Treichl. I am not sure if working on this will be a good idea. It is very old and I have known that the scripts in it might not work properly for newer versions of Octave, while digging up the mailing list. As of now, using Macports seems a good option to me. It also has some great documentation to help me get started. I also know that Ben Abbott had used this approach to produce working app bundles for Octave. I will discuss about the project with the Octave community and write another blog article about what I am going to do exactly in this second half of GSoC.

Java Support in Octave

The trick I was using earlier to get Java support in Octave was merely a workaround. My mentor Michael told me that cross-compiling Octave with Java support was not working out of the box. Firstly, including Java support required us to get a local Windows installation of JDK. Only the Windows version of JDK had the file jvm.dll which was checked during configure. Linux version of java (OpenJDK) didn’t have that file. After some discussion, I came to know that jvm.dll is not required to build Octave with Java. Apparently the only files necessary to get Java support was jni.h and the platform dependent jni_md.h.

To remove jvm.dll checking, I used the following patch:

diff --git a/src/octave-2-no-jvm-check.patch b/src/octave-2-no-jvm-check.patch
new file mode 100644
--- /dev/null
+++ b/src/octave-2-no-jvm-check.patch
@@ -0,0 +1,18 @@
+This file is part of MXE.
+See index.html for further information.
+
+Contains patch to remove checking for jvm.dll during integration of Java support in Octave
+
+diff -r bb713af2e1d9 configure.ac
+--- a/configure.ac	Tue Jul 30 00:49:37 2013 -0400
++++ b/configure.ac	Thu Aug 01 02:57:25 2013 +0530
+@@ -2441,9 +2441,6 @@
+     darwin*)
+       jvmlib=libjvm.dylib
+     ;;
+-    mingw* | cygwin*)
+-      jvmlib=jvm.dll
+-    ;;
+     *)
+       jvmlib=libjvm.so
+     ;;

The process of exporting all missing symbols has now been added as a patch. So there is no need to make the change in the original package, get the sha1 checksum and update octave.mk.

Even though jvm.dll checking was removed, the compiler complained about missing jni_md.h file. OpenJDK had the file jni.h, but it was not enough to build Java enabled Octave. So Michael suggested something much better. He said that it should be possible to download the two header files and put them somewhere into the include directory of mxe-octve (like usr/i686-pc-mingw32/include/java/) and then make Octave to use them. I have pushed a changeset in my repo to do this. Now, one will be able to build Octave with Java enabled without having to hack the –with-java-homedir, –with-java-includedir, and –with-java-libdir options. The using of separate JNI headers during build is limited just to cross-compilation. For native builds, Octave would compile just like it did before. See the new src/octave.mk file here.

GSoC Update

There have been a lot of changes in the project lately, thanks to Michael, Philip, and others. It is now possible to cross-compile Octave with Java support enabled. Earlier I was having trouble getting Java support. The fix was to patch configure.ac of Octave to add “-Wl,–export-all-symbols” to the load flags (see bug# 39454), recalculate its SHA1 checksum, and put it in the src/octave.mk file.

Meanwhile, Jordi has set up a Mercurial repo for me where I can make my changes publicly available. Here is the public link to my repo. I have done some work on the installer scripts. Hopefully we will have a fully working installer for Octave before the mid-term evaluations. I also found some time to learn about how to use Mercurial from Hg Init. It helped me understand the basics of Mercurial in a very short time. I seem to like Mercurial now. :)

During this week, I will focus on adding more features to the installer script. I will write another post detailing about the planned features in the installer, and also about the work I have already done.

Cheers!

Writing an installer for GNU Octave

It’s time I updated my blog about the recent things I have been working on. After my last post, I have moved back to my college for a new academic semester (I am in 3rd semester now). During the last weekend, I was without an active internet connection since our Internet backbone was disrupted due to heavy lightning. Luckily, Internet has been restored now.

With more and more features being added into mxe-octave, I thought it was time to look into the installer that will be used to distribute Octave. Initially, I had started my work on NSIS. Patrick Noffke who has offered to be my backup mentor for this project suggested me to use Windows Installer XML (WiX) because of some reasons which I did find valid. Unlike NSIS which produces .exe installers, WiX produces an MSI file (.msi) which is more stable if built properly.  According to me, WiX is more customizable if compared with NSIS, which needs external plugins for adding most features. Uninstalls are automatically handled by the MSI and is very reliable.

I have written a working installer for Octave which can perform a  basic installation. I will add some option for letting the user choose the BLAS library (reference BLAS or OpenBLAS) during the next week. The WXS file which I composed can be found here. Before building the MSI file from it, you must make sure the path to all the files are set correctly. The installer has Mondo user interface with red and white colour scheme. All the contents of Octave are compressed inside an archive octave.cab. WiX provides us the choice to either embed the CAB file in the MSI installer or keep it separate. I chose to keep it embedded in order to produce a single file output, which will be easier to download.

There are two challenges I am facing right now. One is to find some way to automate the process of adding new files to the WXS file for new builds from mxe-octave. We already have a shell script in mxe-octave to generate an NSI file from the built octave directory. The other problem is to eliminate the need of a Windows installation to build an MSI from the WXS file. I am not sure if it is even needed since the XML file doesn’t need to be written from scratch. I also don’t know how to implement this as of now. I will try to complete the deliverables of the project first.

That’s all for now. See you next week.

Enabled Java in native MinGW but yet to add full support

Since my last update, I have been working only on natively compiling mxe-octave in MinGW/MSYS environment. My mentor Michael Goffioul had advised me to enable more features in my build like LLVM/JIT and Java. But including Java in my cross build was a pain. I was interrupted by missing DLL files (jvm.dll) which do not happen to exist in OpenJDK on Linux. Unwillingly enough, I had to try using the Java installation present in Windows while still cross compiling from Linux. This I had achieved by specifying in the configure options to search for the Java SDK installed inside Windows. Philip Nienhuis had previously tried the same thing using a symlink trick but his work was also interrupted by similar errors. To sum up, I couldn’t get Java enabled in cross-builds which forced me to switch to native builds in MinGW. I will probably continue my work on native builds.

I am specifying the configuration details related to Java libraries from mxe-octave/log/octave.txt. It might be useful for those who are trying to get Java support in native builds.


checking for java... /c/Java/jdk1.7.0_25/jre/bin/java
checking for javac... /c/Java/jdk1.7.0_25/bin/javac
checking for jar... /c/Java/jdk1.7.0_25/bin/jar
checking for Java version... 1.7.0_25
checking for jvm.dll... c:\Java\jdk1.7.0_25\jre\bin/client
checking for include file <jni.h>... /c/Java/jdk1.7.0_25/include



Java home: /c/Java/jdk1.7.0_25
Java JVM path: c:\Java\jdk1.7.0_25\jre\bin/client
Java CPPFLAGS: -I/c/Java/jdk1.7.0_25/include -I/c/Java/jdk1.7.0_25/include/win32
Java libraries: -ladvapi32


The configure options I used:
--with-java-homedir="/c/Java/jdk1.7.0_25"
--with-java-includedir="/c/Java/jdk1.7.0_25"

If configure options are specified then it overrides environment variables. Still I am mentioning it:
JAVA_HOME="/c/Java"

So the details of my current build are as follows:

Build Octave GUI: yes
JIT compiler for loops: no
Build Java interface: yes
Do internal array bounds checking: no
Use octave_allocator: no
Build static libraries: no
Build shared libraries: yes
Dynamic Linking: yes (LoadLibrary)
Include support for GNU readline: yes
64-bit array dims and indexing: no


Java support is yet to be actually added in my build. I am facing the same problem which Philips has reported here.

In my build I also have Ghostscript included (in pstoedit package). I had experienced an issue which you can see here. If anyone else is experiencing this, you can either add ac_cv_path_GS="/c/gs/gs9.07/bin' to the configure options (like I did), or more simply rename your file gswin32.exe to gs.exe (See #36076 in Octave bug tracker).

Since I couldn’t launch Octave GUI on my Windows 8 (there seems to be a problem specific to Windows 8), I asked a friend of mine to test my Octave build who was kind enough to send me screenshots of the GUI.

Update on cross building mxe-octave

It’s time for another update on my GSoC project (yes I know I should blog more often). I was inactive for a couple of days due to lack of internet access. When I came back, I had a new laptop with Intel Core i5 processor which is much faster than the old Intel Atom powered laptop I owned. So now I am able to produce faster builds, not to forget that now I can compile parallely using multiple cores (I can do make octave -j4).

I did a fresh install of OpenSUSE on my laptop. For some time I was having trouble installing Mecurial because auto-refreshing of the configured repositories was failing. Figured out that I was hitting a faulty mirror. After fixing that, I went ahead to cross build the latest version of mxe-octave. As of now, there have been many new packages added to mxe-octave like FFTW, PCRE, freetype, expat, fontconfig, GLPK, libpng, qrupdate, HDF5, QHull, libxml2, jasper, TIFF, lcms, GraphicsMagick, ITSOL, and OpenBLAS. I have successfully produced another cross build which can be downloaded here.

However, I could not add the package ITSOL in my build. Apparently this package is not built automatically, and I had to do make itsol to build it during which I was thrown this error:

/home/ani/mxe-octave/usr/bin/i686-pc-mingw32-gcc -c -O2  -I./INC -DLINUX -o OBJ/systimer.o -c SRC/systimer.c
SRC/systimer.c:28:23: fatal error: sys/times.h: No such file or directory
compilation terminated.
make[2]: *** [OBJ/systimer.o] Error 1

I chose to ignore the package and continued without ITSOL. I will work on its fix later.

I was interrupted many times while building the packages gmp, Lapack, BLAS (reference BLAS) and FFTW. The problem with gmp was pretty lame since I had passed both the options –enable-static and –enable-shared in ./configure because of which I got an error “cannot build both static and DLL, since gmp.h is different for each”. The error disappeared when I did ./configure –enable-shared –disable-static.
For the package FFTW, I bypassed the error by forcing the local implementation of malloc() during configure by modifying the build specs in the src/fftw.mk file. The problem was solved when I added –with-our-malloc as options in all the occurrences of ./configure. See this discussion regarding the error.
The packages lapack and blas failed to build due to missing FORTRAN Compiler. See the issue and my solution in this discussion. It was nice of Michael to explain me the real reason behind the error.

The following is an extract from the log of octave. It tells us about the features enabled in my current build.

Build Octave GUI:                   yes
JIT compiler for loops:             no
Build Java interface:               no
Do internal array bounds checking:  no
Use octave_allocator:               no
Build static libraries:             no
Build shared libraries:             yes
Dynamic Linking:                    yes (LoadLibrary)
Include support for GNU readline:   yes
64-bit array dims and indexing:     no

Though my build has GUI enabled in it, yet I haven’t been able to launch Octave GUI in Windows 8 environment. See this reportage in the mailing list about the issue.
I am also unable to get JIT support despite using the option –enable-jit during ./configure and successfully building LLVM. Experimental Java support in MXE is also yet to added.

During this week, I have also started with a native build of mxe-octave in MinGW on Windows 8. I am presently unable to proceed further because libpng fails to build at some point. I will investigate more into this issue and ask in the mailing list, along with the issues I faced with JIT support, and ITSOL package.

Since I already have a working version of Octave, I will start my work on building the installer for Octave using NSIS. I will dedicate a blog post summing up the ideas of the installer given by my mentor.

That’s all for now.
Cheers!