Tuesday, May 25, 2010

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)

Go to menu Project->Properties.

Go to node C/C++ Build->Environment.

Update the path variable according to your MinGW w64 installation. For example, change it to C:\MinGW_w64\bin.

Switch to topic C/C++ Build->Settings.

[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.

Go to menu Project->Properties.

Go to node 'Tool Chain Editor.' (The spelling of toolchain in Eclipse is not consistent. There are both 'tool chain' and 'toolchain.')

Set the current toolchain to 'MinGW GCC.'

Set the current builder to 'CDT Internal Builder.' You are free to use 'GNU Make Builder' if you prefer.

Go to node 'Settings.'

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.

Go to menu 'Run->Run Configurations...'

Go to tab 'Environment'.

Create a environment variable by using the 'New' button.

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.

Copy the executable file to a place where MSYS environment can reach. This is probably your home folder in C:\msys.

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.

Thanks alot for the quick reply.I am confused with using/compiling MinGW64.1)Do I need to have MinGW sources from http://www.mingw.org/ before preparing MinGW64 ?Could you notedown important steps on compiling it ?2)I want to build QT 64 bit (LPGL version).Can I use MinGW64 for this?3) I am using CMake as my build system.Do I have to specify special parameters when building my project as 64bit build?

1) If you want to build an application using MinGW, you don't need MinGW source.

If you want to compile MinGW-w64 compiler yourself, you need source from http://sourceforge.net/projects/mingw-w64/files/

Make sure that you get w64, not w32.

Unfortunately, I have never tried building MinGW myself. I just grabbed a compiled binary package from Sourceforge.

If you are looking for a binary version, try going to 'Toolchains targetting Win64'->'Personal Build' in Sourceforge's download tree. It may contain what you want, as automated builds may not be as up-to-date as you like (sezero's builds usually include important patches for you).

2) Building Qt 64-bit using MinGW is not a simple task. I tried building Qt 4.6 months ago and failed, but I believe that current situation of Qt 4.7 is much better. The problem I encountered was a conflict of exception models of MinGW w64 and Qt. Floating-point precision was also an issue.

Some people reported success in building Qt 64bit using MinGW, but they needed some tweaks. This is not surprising since MinGW w64 is not supported by Nokia (http://doc.trolltech.com/4.7/supported-platforms.html).

If you really want to give it a shot, you can get proper Qt source from http://gitorious.org/+qt-mingw-w64/qt/qt-mingw-w64-qt

I probably try it myself in late December. If you find anything useful, please share it with me too.

3) Sorry, I cannot answer this question.

I never created any CMake build configuration. I only use CMake configurations from other people to build a program.

Sorry ,one more question.If I use 32bit QT libraries and compile my application in 64bit, can I access higher memory addresses more than 4GB limit ?In my application ,I need to allocate memory more than 6Gb,with 32bit its not possible.Thanks again

I don't think you can link your 64-bit application to a 32-bit library (at least that is what I experienced).

The differences in function-calling conventions of 32-bit and 64-bit binaries may prevent you to get a successful link. I don't know if there is any trick to get around the problem or not.

I myself have to resort to Visual C++ for 64-bit development in Windows as Visual C++ is much more mature and better supported. You can use 64-bit Qt in Visual C++ 2008 and 2010 fine, but some codes that are specific to GCC may need to change.

I think you have tried to use Qt and MinGW this hard because you like opensource products (or your workplace forces you to use them). I like opensource and GCC too, but I currently don't have time to tinker with 64-bit Qt using MinGW. So, I gave up about this. (Just for now; I will have my revenge later when time permits.)

However, I can point you to 64-bit Qt binary built by MinGW w64. You can download the binary that is ready to use at http://www.drangon.org/mingw/.

By the way, if you use the binary from drangon.org, please tell me if you can get that binary to work with your project. I think I tried it myself months ago, but my memory about that is completely gone.

This is an excellent article. I wanted to try out Eclipse for the platform independent coding that we do... So far, we never used Linux for our development. All we used to do was develop in Windows (using VC using plain C++) and then deploy in Linux to see if there are any bugs after deployment in Linux. Hopefully, I can see if Eclipse CDT can help with Mingw.

I tried the package you built, FreeGlut-2.6.0-MinGW-64bit-O2.zip, and it worked. However all the function names have an extra underscore prepended to them. See http://www.agner.org/optimize/calling_conventions.pdf tables 20 and 21, where you can see that the extra underscore should not be there. It's possible to work around this, but the most flexible approach is blocked by compiler bugs, see http://groups.google.com/group/comp.lang.fortran/msg/bbfd64300090163c?hl=en , so it would be easier for me if you could just rebuild the package without the underscores.Thanks in advance, James.

Thank you for your comment. Honestly, I did not know about that convention before. Also, I don't know how to turn that extra undersore on and off. That extra underscore could probably arise due to a bug in cross compilation.

I do not have time to look at the problem myself. But, I rebuilt freeglut with a native compiler and posted it in this link . Please let me know whether or not this solves the problem.

If you have an example source code that shows how the problem looks like, please share it here. I am new to this issue.

My thank-you note posted yesterday seems not to have made it through your filters. Briefly, your new 64-bit build works, as does your old 32-bit build. I posted code at my website that uses your 64-bit library, http://home.comcast.net/~kmbtib/Fortran_stuff/12.zip .Thanks again,James.

Actually, I have no filter and I got an email from Blogger stating that your comments were posted. However, when I checked my post, your two posts were not here. I think the problem came from escape characters in your posts.

Since I still have your original post. I'd like to share it here. It contains much more detail.

(begin James' message)

The problem was that if I compiled a test program with the 32-bit version of your freeglut build, it worked:

So I offer my thanks for your fix! I have uploaded an example that works with your new version at my web site: 12.zip (http://home.comcast.net/~kmbtib/Fortran_stuff/12.zip).It has not only the code but also a screenshot and an executable.