This is a survey of the build dependencies of numerical software on Windows.
Fast numerics need optimized libraries for BLAS and LAPACK. They also need a Fortran compiler to make use of standard Fortran numerical libraries.
Most numerical programming development happens in Unix, and most open-source software is cross-platform. Building many numerical libraries needs a Unix-like build system such as make and autoconf.
A selected list:
All of these need to compile Fortran code and use BLAS / LAPACK libraries - see below.
Common compiler collections on WindowsSee Visual Studio page on Wikipedia. This is the platform compiler for Windows. Express edition is free to download. Compiles C and C++, but Microsoft does not make a Fortran compiler.
See MSVC and Python for a list of MS Visual C versions and download links.
Free x86 and AMD64 (x86-64) VC90 c-compilers for Python-2.7 are now available from Microsoft.
Cygwin is a Unix-like environment on Windows. It includes the full GNU compiler collection and the Unix build tools. gcc compilers link against a C runtime in a Cygwin-specific DLL providing a POSIX compatibility layer. This can cause problems when different libraries compile against different versions of the DLL. It is easy to run into problems with multiple copies of the DLL
MinGW is a port of of the GNU compiler collection to Windows that links against the Microsoft C runtime libraries. It is 32-bit only.
See MingGW-w64 sourceforge page and section in MinGW wikipedia article
Another port of of the GNU compiler collection to Windows implementing multilib (32- and 64- bit compilation from the same compiler).
Much younger than the MinGW project, and under rapid development.
See Intel C compilers. Seem to be somewhere upward of $1000 for Windows C compiler.
See the Intel developer license page.
The license that appears to apply to the Intel run-times, linked statically or dynamically, is the Intel EULA for software development products. See this discussion for more detail.
Relevant clauses for us are:
- Distribution of the Redistributables is also subject to the following limitations: [...] (d) will provide the Redistributables subject to a license agreement that prohibits disassembly and reverse engineering of the Redistributables except in cases when you provide Your Product subject to an open source license that is not an Excluded License, for example, the BSD license, or the MIT license, (e) will indemnify, hold harmless, and defend Intel and its suppliers from and against any claims or lawsuits, including attorney's fees, that arise or result from Your modifications, derivative works or Your distribution of Your Product.
"Redistributables" does cover run-time DLLs, and probably also applies to statically linked object code - see discussion.
With this license, distributing our binaries under a BSD license, we don't have to add the disassembly clause to the license agreement, but we do have to pay Intel's legal fees if someone sues Intel because of a problem in Numpy / Scipy.
Also see below for discussion of Intel Fortran compiler.
See: mingwpy discussion of BLAS / LAPACK.
The options for a 64-bit Fortran compiler on Windows are:
If all Fortran code is compatible with Fortran 77, it is also possible to compile the Fortran code with a C compiler by converting the Fortran code to C with f2c.
Mixing Cygwin / MinGW and Visual StudioVarious problems can arise - see OpenBLAS with VS and MSVC and MinGW DLLs for examples.
Applications and DLLs have to make sure that they do not use different MSVC runtime libraries in the same process.
MinGW-w64 lacks intrinsic support for choosing MSVC run-times as a gcc option. For example, Python 3.3 was compiled with MSVC 10 (VS 2010). A Python extension will be in the same process as Python, and so will also need to link against the MSVC 10 run-times.
The workaround is to create and patch the gcc specs file for the particular MSVC runtime you want to link against.
Another option is using cross-compilers like MXE. MXE does MinGW builds from Linux.
If a program tries to load a DLL called mylibrary.dll, Windows has to decide which directories it should search for mylibrary.dll.
Applications and libraries often need to ship DLLs, and they need to make sure the application / libraries finds the correct version.
One place that Windows looks for DLLs is on the system $PATH (the %PATH% variable in cmd.exe, or $env:PATH in Powershell). It is not safe in general to put our own mylibrary.dll into some system directory like WINDOWS/system because another application may depend on a different version of the DLL that is also called mylibrary.dll.
For reference here is the standard DLL search algorithm. See this exploration of DLL search settings for more explanation.
Alternative strategies for finding the right DLL are:
Putting the required DLL in the same directory as the calling executable, assuming the standard search order is in place.
Using the LOAD_WITH_ALTERED_SEARCH_PATH flag to the DLL loading call LoadLibraryEx. In this case you get the alternate DLL search algorithm, which looks in the directory containing the loading DLL instead of the directory containing the calling executable.
Setting an extra DLL search directory with SetDllDirectory. The Microsoft documentation on the LoadLibraryEx call says this about SetDllDirectory:
However, be aware that using SetDllDirectory effectively disables safe DLL search mode while the specified directory is in the search path and it is not thread safe. If possible, it is best to use AddDllDirectory to modify a default process search path.
See the standard DLL search algorithm for more detail on safe DLL search mode.
Adding a specific directory to the search path with AddDllDirectory (dead link). This only works for updated Windows 7 and later.
Using private assemblies to specify a set of DLLs specific to the application.
See Building numpy / scipy (dead link).
Standard Windows compile uses:
Standard numpy and scipy binary releases on Windows use pre-compiled ATLAS libraries and are 32-bit only because of the difficulty of compiling ATLAS on 64-bit Windows. Because of the problem of locating DLLs, ATLAS is linked statically.
See building R from source and R Windows toolset.
In the Windows toolset page, a typical quote:
We have found that the build process for R is quite sensitive to the choice of tools: please follow our instructions exactly, even to the choice of particular versions of the tools
The R build depends on a customized set of Windows tools for R. These include copies of Cygwin command line tools and a copy of the MinGW-w64 toolchain
So, R uses:
See Octave for Windows and Octave-forge Windows directory.
Octave Windows binary releases on the main sourceforge site are behind compared with Mac (3.6.4 vs 3.8.0). The top of the Octave Windows page says:
GNU Octave is primarily developed on GNU/Linux and other POSIX conformal systems. The ports of GNU Octave to Windows use different approaches to get most of the original Octave and adapt it to Microsoft Windows idiosyncrasies (eg: dynamic libraries, file paths, permissions, environment variables, GUI system, etc). Bear this in mind and don't panic if you get unexpected results.
There is a current Octave build for windows (dead link) using the MXE cross compiler.
Tools, BLAS and Fortran use are a little confusing across the range of Octave builds:
See installing sage from source
Sage can only be built on Cygwin on Windows. Uses:
See compiling scilab for Windows
The instructions include this command to checkout requirements for Windows:
svn export --force --username anonymous --password Scilab svn://svn.scilab.org/scilab/trunk/Dev-Tools/SE/Prerequirements/Windows scilab
This fetches a large number of Windows binary packages that appear to include compiled reference BLAS, ATLAS, OpenBLAS, MKL, Python, java.
So:
Julia uses MinGW-builds - binary builds of dual 32- / 64-bit MinGW compilers.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4