Author Topic: A few comments about Building 64 bit version of Codeblocks Mingw64 on Windows.  (Read 1516 times)

Offline Robert Eastwood

  • Multiple posting newcomer
  • *
  • Posts: 13
I have not found alot of comments on building 64 bit versions of Codeblocks, although since I have a working version in 64bit I wanted to comment on a few things I found along the way to be helpful to others building a 64bit version.

Some of this may be obvious to some people, but there are many different levels of experience and knowledge among users so don't be offended if I comment on something obvious to many of you more experienced programmers, or those that easily built a 64bit build.  I also don't claim to be correct in my comments or methodology only that it did work to build 64bit CB.

This also is not meant to be a comprehensive instruction, nor even guaranteed to be helpful, but it may provide some information to someone building a 64bit version with MinGW64

First make sure that your Mingw64 folder is at top of environmental path when building the Widgets. 
On windows you can adjust your paths by typing "edit the system environment variables" that opens a system property where you can click environment variables button
Then make sure the first item on path is your Mingw64\bin folder  (being above system paths can make sure you don't get a windows version of a system file instead of the needed MinGW64 version that may have the same name when compiling from command line,path order may not be important but it is how I set up my build.)

I set the config.gcc options below when building wx widgets.  The file is located in the same directory as makefile.gcc

Code: [Select]
# Standard flags for CC
CFLAGS ?= -std=c11

# Standard flags for C++
CXXFLAGS ?= -std=c++1z

# Standard preprocessor flags (common for CC and CXX)
CPPFLAGS ?= -m64

I use 3.1.2 version of WX and build it with Mingw64 and it builds fine.
Make sure you use your custom dll and your built libraries when then building CB.  I put all those files into a C:\MostRecentLIbBuilds\release or C:\MostRecentLIbBuilds\debug then point all my projects to that folder using CB global variables.  My projects always copy its output file to those directories when built

If you have problems or want to make sure that it is a 64 bit build(you can check the .a lib files built to see they are 64 bit by extracting one of them to a folder then using objdump -f somefilenameyouextracted.o.  the output will say i386 or if it is 32 bit, and 64 if 64bit.  objdump is a utility shipped with minGW64.
You also can look at the two wx widget dll files to see ithat they are 64 bit by a utility you can build.  called Dependencies located at
If you want to see the library is really 64 bit, extract a .o file from a libxxx.a library and look at it.  libxxx.a files really are 'ar type zip files' so you can extract them using any zip utility.  (note if you have to recompress an .a file, (you shouldn't have to unless there is some conflict with object libraries), you can't use 7z or winrar to zip the file, you have to use the ar.exe utility, so it is the ar format, there is one in the MinGW.exe bin folder, and is part of your toolchain for CB also)

I use CD in a dos prompt window to navigate to the folder that contains the makefile.gcc for wx widgets (if a different drive make sure you switch to that drive first)
Note it is the msw folder for building for Microsoft windows, even if using Mingw64 to build the project. (make sure your on the right drive if it is not C:drive)

Code: [Select]
cd C:\wx312\build\msw
I use this for my command line.  with the changes to 'config.gcc' all the options I need are then built with WX.  Note the CFG will be the folder name where you then get the lib files to use when building WX projects in CB including when building Codeblocks.

Code: [Select]
mingw32-make.exe -f  makefile.gcc  BUILD=release UNICODE=1 SHARED=1 MONOLITHIC=1 CFG="M_U_std17_64_R"
Some notes on using wx build.
     If you get a setup.h file not found, you have to find the right one to add to your search path for compiling.  The correct one is inside the folder that is built when you build wx, then you have to add that folder to the include paths of items that you are building that will use wx, it tells wx about your platform and is generated when wx is built.
     If you get a line that says, only include this when using MSVC it is because you are pointing to the wrong setup.h file.  setup.h is in your CFG folder and added during build of WX
     when building with WX (other projects after you build CB) you also have to have your program set some defines such as

Unicode is optional, and there are a few other things, however the nice people that put together the source package already have all those defines set inside the project *.cbp files Defines option that you will use to build CB.  But when you use WX in some other project you will be building with your 64bit Codeblocks you will need to know about those defines.

Now building CB 64bit version

When building 64 bit CB with 32 bit CB I use the following folder structure.
I have a Codeblocks folder, inside of that is IDE, that is where Codeblocks 32 resides.  That is where I build from.
I then have Codeblocks source in a folder codeblocks-17.12, they are different folders.
It is in the codeblocks-17.12 src that you get the source files (and workspace file) to build your program.

To make sure Codeblocks 32bit doesn't try to use the wrong dlls while it is running and building the 64bit version, I copy the dlls that the downloaded version of Codeblocks was built with (GNU 32 bit compiler dlls)into the 32 bit Codeblocks directory IDE.  That way Codeblocks 32bit will be assured to use the right dlls. (this may not be needed but wanted to avoid dll conflicts)  Codeblocks 32 bit(in the IDE folder) will use 32 bit dlls, but while building my projects the source in those projects will point what is being built to use the 64bit dlls and 64 bit libraries.  (that pointing comes from the build options search directories for libraries and compiling, and this may be more then needed)

Presuming you are using wx3.1.2 the recent download of codeblocks-17.12 source download has a workspace file CodeBlocks_wx31.workspace.  Open That in CB
You will have to set some global variables in CB when you open it, codeblocks will want a variable that points to wx31 for example, and one that points to CB itself.  Those varables exist so that while your building, each individual project can easily find its include files.  The CB variable needs to point to the source you are building with, not the compiler you are using. 

You will be asked to set a variable cb_release_type set that to "-O2"  that will tell compiler to optimize code when building your 64 bit CB, (you could set other options there if you wanted to build debug version)

Opening that workspace and looking at properties or build options of CodeBlocks_wx31 project you can see the projects codeblocks will build with 'all' selected when you hit build button.   core sdk, src, included pluggins and contributor plugins will build if you build workspace.  You may have to make some adjustments to paths to make sure you find all source files and library files.
(The txml lib that is not found is built and in base directory in codeblocks source, you may have to add that path in a few places)
(if you get incompatible libraries you are mixing 32 bit and 64bit libraries)
(if you get can't find one of the wx libs you probably don't have your search path libraries pointing to where your built wx libraries are)

I am not going to go through all the paths because for the most part, if you set the global variables and 'custom variables' to the right CFG for widgets inside the project directory,

and set the right options,

and get the include paths, both for libraries and for compiling correct ( this picture only has an example of include for compiling but shows how the global variables are used.)

these work, but may not all be needed, don't remember to be honest if all of them are needed.
each project will also have its own include needs, you may need to adjust them, hence why global CB variables are so convenient.

It builds, if you get can't find some h files finding missing includes is usually easy to figure out by finding where the file is on your computer.

The  sdk and src build the dll and exe, the rest build plugins or build tool support.  They build the project to a folder, on my computer they build to src\Devel31 folder in the source codeblocks-17-12 folder.   That folder is where you will find your finished build.  If it works you should be able to hit Rebuild workspace and get everything built.

But first a few things that came up during my build you may also run into.

I could not get AutoRevision and Coderunner to build.  I don't need them, and will figure that out later, so I went into the 'virtual targets area of workspace properties' and removed those two from the 'all' configuration.   I don't get those two items built, so I also have to remove in the prebuild options (of the codeblocks 31 cbp build options) where AutoRevision is called to set the version number of a new build.  (If I ever need to release some version of codeblocks I would have to manually set version numbers)
My presumption is because to build AutoRevision 64bit, you need AutoRevision 64bit, and until you build a CB 64bit version you can't build autoversion build tool 64bit(I could be wrong, someone may explain why I could not build it, but my solution was to exclude it from build.)  I probably will figure out building it with my 64bit version but excluding it, as long as you also exclude the prebuild instruction that calls it works fine. 

There are many command line post build commands that create the zip files in devel31\share\codeblocks they contain the manifest for each plugin and often resources.  They are needed and could have changed so after a build codeblocks post build command for projects add the files from the source build directories to the zip in the devel31 directory.  You will see those instructions in the postbuild commands for every project.  I had to change them, some used update31.bat files, some had xcopy and zip commands.  You can see what they intend to do and may have to change them to work with your particular command line zip utility.

The problem:  My windows did not have a command line zip tool, I had to change all of them to use 7z.exe and 7z.exe has different switch options.
So I built a bat file that every project uses, and changed all the post build commands.  I presume some of you are smart enough to find a command line tool that works with command 'zip' on a windows system, I did not figure it out so I changed them all to use 7z.exe (that is already on my environmental path)

A note on using 7z.exe  Codeblock crashes when telling it to open a file that starts with a number, including telling it to use 7z.exe in a post build option so you have to rename 7z.exe to something that does not start with a number.  Literally in your 7z folder (that is on path in environmental variables so CB can find it) you have to inside of windows explorer make a copy with a different name and use that in your post build commands copying into zip files.  I use NN7z.exe the exact same file as 7z.exe only with a usable name.

so instead of zip -j9 resource\*.png
I use NN7z.exe a -y  resource\*.png

getting all the files to zip so all the pluggins had the form of zip files they expected took the longest time to get right, but it is not complicated and technically is not part of the building. I use search and replace through the various CBP files to change the values for each plugin and call the same bat file sending in 'options' such as $(PROJECT_DIR) to that bat file, but won't cover all that in this post.  You may have to find a method to make sure those zip files for plugins have the needed files when you change the source for a plugin xrc or add a png you will need to copy the into the zip.  You can use the original versions in IDE directory to see what they are suppose to look like, or find some other workable strategy.

After changing all the projects to use my NewNamed7z.exe and add in all the manifest, *.png and *.xrc files needed,
and after excluding AutoVersion from being built
I was able to build 64bit CB, I then close CB renamed the IDE folder to IDE_OLDINSTALLED, created a new IDE and copied all the files from Devel31 that I built into that directory.  I automate that with a bat when I rebuild CB now.

And it works.

One more note.
I do suggest turning off the Occurrence Highlighter option, on my computer it is too slow to be functional, although that is not a 64 bit issue, if you have sluggish selection actions when double clicking turning that plugin off will help.  You can disable it in plugins manager in CB, besides that issue things work build and runs fine.

And thanks to the people that put together those workspace and CB project files, they really helped see what was needed to build the project.

Offline Robert Eastwood

  • Multiple posting newcomer
  • *
  • Posts: 13
Note Once I built a 64bit version of Codeblocks I was able to then build the Coderunner and Autoversion parts of Code::Blocks wx3.1x project, although I don't use Autoversion it does build as a 64 bit version while using the 64bit codeblocks

Offline Miguel Gimenez

  • Lives here!
  • ****
  • Posts: 572
If you use wx3.1.2 for building C::B you will get crashes with code completion. Use current wx head or patch wx3.1.2.

Offline Robert Eastwood

  • Multiple posting newcomer
  • *
  • Posts: 13
If you use wx3.1.2 for building C::B you will get crashes with code completion. Use current wx head or patch wx3.1.2.

Yea I noticed that, but I had it turned off while I tried to figure that out, thanks for tip, will go look for patch now.
I also have occurrence highlighting off, on my machine it takes to many cycles and makes some out of sync mouse message processed to create weird selections.