Eclipse MinGW x64

Eclipse CDT with MinGW w64

This tutorial discusses how you can use MinGW 64-bit and Eclipse to build an application.  This tutorial is based on 64-bit MinGW (probably version 4.5--the version is not clear from the download page) and Eclipse Galieo (SR2 Build ID:2010 02 18-1602) and Eclipse Helios (SR1 for Windows 64 bit, eclipse-cpp-helios-SR1-win32-x86_64). The following parts of this tutorial assume that you already installed Eclipse and MinGW 64-bit at your preferred paths and will only discuss how you can change Eclipse settings to build and run your applications.

Get Compiler

The first task is to obtain a proper MinGW w64 compiler.  Although our target platform is Windows 64-bit, the compiler may be a 32-bit application that performs cross-compilation for you.  You can choose your preferred version from here.  There are some significant different for personal and automated builds (as of Dec 2010).  For example, the sezero build I used (mingw-w64-bin_x86_64-mingw_20101003_sezero) is 64-bit binary producing 64-bit application, while a binary from the automated build (mingw-w64-1.0-bin_i686-mingw_20101129) is 32-bit binary generating 64-bit application.  Technically, the automated build performs cross-compilation, while the sezero build performs native compilation.  As sezero build has a conventional directory structures and file names (same as MinGW 32-bit), I recommend using the sezero build.  It will save you a lot of time and you will not encounter some naming troubles in later steps.

In summary, from the link provided above, it is best if you go to the 'Personal Builds' section and download the latest sezero build.  This is probably the best way to use Windows 64-bit to generate 64-bit applications.

Change Compiler Settings (Galieo SR2)

1. Go to menu Project->Properties.
   
   
2. Go to node C/C++ Build->Environment.
   
   
3. Update the path variable according to your MinGW w64 installation.  For example, change it to C:\MinGW_w64\bin. 
   
   
4. Switch to topic C/C++ Build->Settings.
   
   
5. [update (Dec 27, 2010): some recent MinGW versions (native compilation) come with 'as', 'g++', and 'gcc' commands. This step may be unnecessary for your MinGW build. However, some versions (cross-compilation) still have this issue and this step is required.  If you use sezero build, this step is probably unnecessary.]
   
   There are four commands to update: GCC Assembler, GCC C++ Assembler, GCC C Compiler, and MinGW C++ Linker.  Correct commands depends on the platform of MinGW w64 you choose.  No worry.  It is quite obvious to know what commands to use, as the command names are in the format [platform prefix]-[default command].exe.  For example, we need to update the command 'as', 'g++', 'gcc', and 'g++' for GCC assembler, C++ compiler, C compiler and C++ linker, respectively.  The correct commands may be 'x86_64-w64-mingw32-as', 'x86_64-w64-mingw32-g++', 'x86_64-w64-mingw32-gcc', and 'x86_64-w64-mingw32-g++', respectively.
   
   

Change Compiler Settings (Helios SR1)

Eclipse Helios is virtually blank regarding compiler configurations, but it seems to be compatible with various GCC toolchains (Mac, Solaris, Cygwin, MinGW, and Linux).  Our first task is to choose a proper toolchain as follows.

1. Go to menu Project->Properties.
2. Go to node 'Tool Chain Editor.' (The spelling of toolchain in Eclipse is not consistent.  There are both 'tool chain' and 'toolchain.')
3. Set the current toolchain to 'MinGW GCC.'
4. Set the current builder to 'CDT Internal Builder.'  You are free to use 'GNU Make Builder' if you prefer.
5. Go to node 'Settings.'
6. Change the path of compiler/assembler commands.  For example, highlight 'GCC C++ Compiler' and change the command to 'C:\MinGW_64bit\bin\g++' if you save MinGW at C:\MinGW_64bit.
    

There is no path variable any more, but there is a new node called 'Discovery Options' inside 'C/C++ Build.'  If we check 'Automate discovery paths and symbols,' most path settings are not necessary during program compilation.

If you employ OpenMP, you might want to see more detail at this site.  Basically, you have to change the miscellaneous flag of GCC C++ Compiler and MinGW C++ Linker to include -fopenmp.  Remember, however, that we have to change run-time settings, as OpenMP requires additional run-time libraries.

Change Default Include Folders

(This step is required for Galieo, but not for Helios.  If you use Helios and choose 'Automate discovery paths and symbols' in 'C/C++ Build,' the defualt include folders should be correct right of the beginning.)

It is quite painful in this part, as Eclipse uses the C:/mingw by default.  If you have multiple versions of MinGW, you have to change them.  Fortunately, (almost) all include files are all the same among versions.  Therefore, if we add header files to the default MinGW installation path, things should work across versions.  These are, however, the include paths for the Eclipse editor.  This means that Eclipse source-code editor can parse and show some hints if we add header files to the default 32-bit MinGW path, even though we are going to use 64-bit MinGW to perform actual program compilation.  Therefore, for actual compilation, we need true addendum to an include folder that a compiler uses.  See an example below.

Example: add OpenGL header files to Eclipse for actual compilation.
If we want to add header files to a 'global' include folder, such as GL, the include folder that will make things work has a platform prefix, say 'x86_64-w64-mingw32\include'.  This is the case when we call gcc with the same prefix from a bin directory, such as 'x86_64-w64-mingw32-gcc.exe'.  Addition of header files in other directories has no effect in actual compilation.

Change Run-Time Settings

At this step, you can build your 64-bit application, but you probably see that you cannot run it, even within the Eclipse environment itself.  Your program might just be terminated without any reported error message.  To deal with the problem, you also need to change run-time settings as follows.

1. Go to menu 'Run->Run Configurations...'
2. Go to tab 'Environment'.
3. Create a environment variable by using the 'New' button.
4. In a new popup window, set 'Name' to PATH and 'Value' to $PATH;C:\MinGW_64bit\bin, provided that C:\MinGW_64bit is the installation folder for your 64-bit MinGW.  Note: if you have more paths to include, separate them with a semi-colon.
   
   

Alternatively, you can set Windows environment path variable to include the MinGW path.  Nonetheless, if you have both 32-bit and 64-bit MinGW in the paths, some DLL names may cause DLL conflict and you may get 32-bit library instead of 64-bit library when you call your program.  If your machine, however, has only 64-bit MinGW, using the Windows path variable is probably the most convenient way because you will have no need to create a path variable in Eclipse run-time settings for this purpose again.  Nevertheless, dealing with Eclipse run-time settings does not need admin previlage to execute and it is always a viable option.

Because setting the Eclipse environment variable does not change any path variable outside Eclipse, we cannot run the application by double clicking on it or calling at command prompt, unless path variable for the executable session is set.  To temporarily change Windows path variable, a command 'set path=%path$;C:\MinGW_64bit\bin' may be used [ref:http://vlaurie.com/computers2/Articles/environment.htm].  Again, separate library paths with a semi-colon if you have multiple library paths to add.  This effectively appends the MinGW path to the existing path variable, specifically for the command prompt session.  Therefore, it may be a bit awkward if we want to call an executable file from Windows Explorer, as a batch file may need to be created.

OpenMP Note: for sezero's MinGW build, you may need to unpack pthreads-w64.zip into the root of your MinGW folder (C:\MinGW_64bit) so that required OpenMP run-time libraries are available in a proper place.

Tips: some error messages from Windows may not show up in Eclipse when we run or debug our programs within Eclipse environment.  Try using a command prompt (cmd.exe) and you may see more informative error messages.

Optional: Using MSYS to check if the compiled application is 64-bit

There are at least two ways to check if an application is 64-bit or 32-bit.  The easiest way is to run it and see its process name in the Windows Task Manager.  If the process name has a suffix *32, it is 32-bit.  If there is no such suffix, it is 64-bit.  There is another way.  It is less convenient in my opinion, but you can probably use it to check your application programmatically without running it at all.  This is possible if you use MSYS as discussed below.

1. Copy the executable file to a place where MSYS environment can reach.  This is probably your home folder in C:\msys.
   
   
2. Enter 'file my_executable.exe'.  For MSYS 1.0.11 32 bits (I ran it on 64-bit Windows 7), a 64-bit executable will get a message 'my_executable.exe: PE executable for MS Windows'.  There is nothing about 32-bit or 64-bit tags showing up.  A 32-bit executable, however, will get a message 'my_executable.exe: PE executable for MS Windows (console) Intel 80386 32-bit'.  Namely, a 32-bit executable gets a clear description about its platform, while a 64-bit executable does not get any definite description.  This is analogous to what the Task Manager does.
   
   For more recent version of MSYS, the file command gives PE32 for a 32-bit executable and PE32+ for a 64-bit executable.
   

Pinyo Taeprasartsit
(May, Dec 2010)

This document can be viewed at my blog and my Google docs.  I welcome questions, comments, and suggestions.  Please leave a message in my blog if you have any.  Thank you.