![\"\"](\"https:\/\/wp.oktay.com\/wp-content\/uploads\/2026\/10\/CB_Screenshot_SVN14057.jpg\")
<\/a><\/figure>\n\n\n\n1. The Problem: User Project Templates Create Directories Instead of Files<\/h2>\n\n\n\n
When creating a new project from a user-defined template, Code::Blocks did not copy the template files correctly.<\/p>\n\n\n\n
For example, instead of creating:<\/p>\n\n\n\n
MyProject\/\n\u251c\u2500\u2500 main.cpp\n\u2514\u2500\u2500 MyProject.cbp<\/code><\/pre>\n\n\n\nit created directories named after the files:<\/p>\n\n\n\n
MyProject\/\n\u251c\u2500\u2500 main.cpp\/\n\u2514\u2500\u2500 MyProject.cbp\/<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/wp.oktay.com\/wp-content\/uploads\/2026\/10\/cb_not_fixed_Screenshot-2026-10-24-130733.jpg\")
<\/a><\/figure>\n\n\n\n![\"\"](\"https:\/\/wp.oktay.com\/wp-content\/uploads\/2026\/10\/CB_Screenshot-err-2026-10-20-010126.jpg\")
<\/a><\/figure>\n\n\n\nRebuilding Code::Blocks alone did not fix the problem. The cause was in the SDK source code responsible for creating projects from user templates.<\/p>\n\n\n\n
The relevant source file is:<\/p>\n\n\n\n
src\/sdk\/templatemanager.cpp<\/code><\/pre>\n\n\n\nThe function to inspect is:<\/p>\n\n\n\n
TemplateManager::NewProjectFromUserTemplate()<\/code><\/pre>\n\n\n\nWe will return to this bug after setting up the build environment.<\/p>\n\n\n\n
2. Download the Required Software<\/h2>\n\n\n\n2.1 GCC 16.2.0 and MinGW-w64<\/h3>\n\n\n\n
Download GCC from the WinLibs project:<\/p>\n\n\n\n
https:\/\/github.com\/niXman\/mingw-builds-binaries\/releases\/download\/16.2.0-rt_v14-rev1\/x86_64-16.2.0-release-posix-seh-ucrt-rt_v14-rev1.7z<\/a><\/p>\n\n\n\nFor the configuration used here, select the 64-bit GCC 16.2.0 toolchain with:<\/p>\n\n\n\n
\n- UCRT runtime<\/li>\n\n\n\n
- POSIX threads<\/li>\n\n\n\n
- SEH exception handling<\/li>\n<\/ul>\n\n\n\n
The corresponding WinLibs archive was extracted to:<\/p>\n\n\n\n
D:\\mingw\\gcc16<\/code><\/pre>\n\n\n\nThe compiler executables are in:<\/p>\n\n\n\n
D:\\mingw\\gcc16\\bin<\/code><\/pre>\n\n\n\nYou do not need a conventional Windows installer. Extract the archive into the desired directory.<\/p>\n\n\n\n
2.2 wxWidgets 3.3.4<\/h3>\n\n\n\n
Official download page:<\/p>\n\n\n\n\nhttps:\/\/wxwidgets.org\/downloads\n<\/div><\/figure>\n\n\n\nFor a source build, download the Windows source archive for wxWidgets 3.3.4. The official release information is also available here:<\/p>\n\n\n\n
https:\/\/github.com\/wxWidgets\/wxWidgets\/releases\/tag\/v3.3.4<\/a><\/p>\n\n\n\nwxMSW-3.3.4_gcc1620_x64_Dev.7z<\/a><\/p>\n\n\n\nImportant:<\/strong> Do not use GitHub’s automatically generated “Source code” archive for a source build if the wxWidgets release instructions specify the dedicated Windows source archive. The dedicated archive includes the necessary sources and submodules.<\/p>\n\n\n\nExtract wxWidgets so that the resulting source directory is:<\/p>\n\n\n\n
D:\\wx\\3.3.4<\/code><\/pre>\n\n\n\n2.3 Code::Blocks SVN source code<\/h3>\n\n\n\n
The Code::Blocks SVN repository is available here:<\/p>\n\n\n\n
http:\/\/svn.code.sf.net\/p\/codeblocks\/code\/trunk\/<\/a><\/p>\n\n\n\nThe source directory used in this guide is:<\/p>\n\n\n\n
C:\\CodeBlocks\\14057\\src<\/code><\/pre>\n\n\n\nThis guide refers to SVN revision 14057. If you use a different revision, the source code and build instructions may differ.<\/p>\n\n\n\n
3. Verify the Compiler Installation<\/h2>\n\n\n\n
Open a Windows Command Prompt.<\/p>\n\n\n\n
Temporarily add the compiler directory to PATH<\/code>:<\/p>\n\n\n\nset PATH=D:\\mingw\\gcc16\\bin;%PATH%<\/code><\/pre>\n\n\n\nCheck the installed versions:<\/p>\n\n\n\n
g++ --version\ngcc --version\nmingw32-make --version<\/code><\/pre>\n\n\n\nThe compiler should report GCC 16.2.0.<\/p>\n\n\n\n
If Windows reports that a command cannot be found, check the extracted directory structure. The executables must exist in:<\/p>\n\n\n\n
D:\\mingw\\gcc16\\bin<\/code><\/pre>\n\n\n\nMake sure that Code::Blocks uses this same compiler installation.<\/p>\n\n\n\n
4. Build wxWidgets 3.3.4<\/h2>\n\n\n\n4.1 Open the correct directory<\/h3>\n\n\n\n
The GCC makefile is named:<\/p>\n\n\n\n
makefile.gcc<\/code><\/pre>\n\n\n\nIn a Command Prompt, navigate to the directory containing it. In a typical wxWidgets source tree, this is:<\/p>\n\n\n\n
cd \/d D:\\wx\\3.3.4\\build\\msw<\/code><\/pre>\n\n\n\nCheck that makefile.gcc<\/code> exists before proceeding. If the source archive uses a different directory layout, adjust the path accordingly.<\/p>\n\n\n\n4.2 Use the correct make command<\/h3>\n\n\n\n
The command that worked in this environment was:<\/p>\n\n\n\n
mingw32-make -f makefile.gcc -j8 SHELL=cmd.exe SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1<\/code><\/pre>\n\n\n\nThe options are:<\/p>\n\n\n\nOption<\/th> Meaning<\/th><\/tr> -f makefile.gcc<\/code><\/td>Use the GCC\/MinGW makefile.<\/td><\/tr> -j8<\/code><\/td>Allow up to eight parallel build jobs.<\/td><\/tr> SHELL=cmd.exe<\/code><\/td>Explicitly use the Windows command interpreter.<\/td><\/tr> SHARED=1<\/code><\/td>Build shared libraries.<\/td><\/tr> MONOLITHIC=1<\/code><\/td>Build the monolithic wxWidgets library.<\/td><\/tr> BUILD=release<\/code><\/td>Build the release configuration.<\/td><\/tr> UNICODE=1<\/code><\/td>Enable Unicode support.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n4.3 Why SHELL=cmd.exe<\/code> matters<\/h3>\n\n\n\nThe build encountered shell-related problems when GNU Make executed commands.<\/p>\n\n\n\n
Explicitly specifying:<\/p>\n\n\n\n
SHELL=cmd.exe<\/code><\/pre>\n\n\n\nresolved the problem in this environment.<\/p>\n\n\n\n
This is an important detail to remember when reproducing the build on Windows. If make commands fail unexpectedly, check which shell GNU Make is using before investigating unrelated compiler errors.<\/p>\n\n\n\n
4.4 Fix the Windows SDK declaration issue<\/h3>\n\n\n\n
During compilation, an error occurred involving:<\/p>\n\n\n\n
SHCreateItemFromParsingName<\/code><\/pre>\n\n\n\nThe declaration was gated by the _WIN32_IE<\/code> version setting in the Windows SDK headers.<\/p>\n\n\n\nThe configured value was too low:<\/p>\n\n\n\n
_WIN32_IE=0x0603<\/code><\/pre>\n\n\n\nThe setting used to resolve this particular error was:<\/p>\n\n\n\n
_WIN32_IE=0x0700<\/code><\/pre>\n\n\n\nAfter changing the setting, the build proceeded.<\/p>\n\n\n\n
Do not change this macro blindly in every project.<\/strong> Check the relevant Windows SDK header and the actual compiler definitions first. This adjustment was specific to the declaration encountered during this build.<\/p>\n\n\n\n5. Configure Code::Blocks<\/h2>\n\n\n\n5.1 Check the compiler<\/h3>\n\n\n\n
In Code::Blocks, open:<\/p>\n\n\n\n
Settings \u2192 Compiler \u2192 Toolchain executables<\/strong><\/p>\n\n\n\nCheck that the selected compiler points to:<\/p>\n\n\n\n
D:\\mingw\\gcc16\\bin<\/code><\/pre>\n\n\n\nThe compiler, linker and other toolchain executables should belong to the same installation.<\/p>\n\n\n\n
5.2 Check the wxWidgets global variables<\/h3>\n\n\n\n
Open:<\/p>\n\n\n\n
Settings \u2192 Global variables<\/strong><\/p>\n\n\n\nThe existing configuration used a global variable named:<\/p>\n\n\n\n
wx33_64<\/code><\/pre>\n\n\n\nCheck its base directory and all related paths.<\/p>\n\n\n\n
The chosen wxWidgets source\/build directory is:<\/p>\n\n\n\n
D:\\wx\\3.3.4<\/code><\/pre>\n\n\n\nAvoid mixing paths from different installations, for example:<\/p>\n\n\n\n
D:\\wx\\3.3.4\nD:\\wx\\3.3.4-gcc16<\/code><\/pre>\n\n\n\nThe compiler include paths, library paths and wxWidgets configuration must all refer to the intended build.<\/p>\n\n\n\n
5.3 Fix the missing wxWidgets library<\/h3>\n\n\n\n
The following linker error occurred:<\/p>\n\n\n\n
ld.exe: cannot find -lwxmsw33u: No such file or directory\ncollect2.exe: error: ld returned 1 exit status<\/code><\/pre>\n\n\n\nThe required import library was located in:<\/p>\n\n\n\n
D:\\wx\\3.3.4\\lib\\gcc_dll<\/code><\/pre>\n\n\n\nThe linker had been given a different library directory.<\/p>\n\n\n\n
Correct the settings under the project’s:<\/p>\n\n\n\n
Build options \u2192 Search directories \u2192 Linker<\/strong><\/p>\n\n\n\nMake sure the active target can find:<\/p>\n\n\n\n
D:\\wx\\3.3.4\\lib\\gcc_dll<\/code><\/pre>\n\n\n\nThe exact directory depends on the library layout produced by your build.<\/p>\n\n\n\n
Remember that a DLL-based build requires the import library during linking. The presence of a DLL alone is not sufficient.<\/p>\n\n\n\n
After correcting the paths, clean and rebuild the affected target.<\/p>\n\n\n\n
6. Fix the User Template Bug<\/h2>\n\n\n\n6.1 Open the source file<\/h3>\n\n\n\n
Open:<\/p>\n\n\n\n
C:\\CodeBlocks\\14057\\src\\sdk\\templatemanager.cpp<\/code><\/pre>\n\n\n\nLocate:<\/p>\n\n\n\n
TemplateManager::NewProjectFromUserTemplate()<\/code><\/pre>\n\n\n\nInspect the code that creates the destination directories and copies the template files.<\/p>\n\n\n\n
6.2 Understand the cause<\/h3>\n\n\n\n
The relevant code used a destination path containing the complete file name.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
C:\\Projects\\MyProject\\main.cpp<\/code><\/pre>\n\n\n\nThe problematic logic was equivalent to:<\/p>\n\n\n\n
if (!CreateDirRecursively(dst))\n Manager::Get()->GetLogManager()->DebugLog(\n _T(\"Failed creating directory for \") + dst);\n\nif (wxCopyFile(src, dst, true))\n{\n \/\/ Continue processing the copied file.\n}<\/code><\/pre>\n\n\n\nThe problem is that dst<\/code> represents the file destination, not just the directory.<\/p>\n\n\n\nPassing this complete path to a directory-creation function can create a directory named main.cpp<\/code>.<\/p>\n\n\n\n6.3 Correct the code<\/h3>\n\n\n\n
Replace the problematic block with:<\/p>\n\n\n\n
wxFileName dstName(dst);\n\nif (!CreateDirRecursively(dstName.GetPath()))\n{\n Manager::Get()->GetLogManager()->DebugLog(\n _T(\"Failed creating directory for \") + dstName.GetPath());\n}\n\nif (wxCopyFile(src, dst, true))\n{\n \/\/ Continue processing the copied file.\n}<\/code><\/pre>\n\n\n\nThe key change is:<\/p>\n\n\n\n
dstName.GetPath()<\/code><\/pre>\n\n\n\nThis extracts the parent directory from the destination file path.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Destination file:\nC:\\Projects\\MyProject\\main.cpp\n\nParent directory:\nC:\\Projects\\MyProject<\/code><\/pre>\n\n\n\nThe directory-creation function now creates only the parent directory, and wxCopyFile()<\/code> copies the actual file.<\/p>\n\n\n\nCheck the surrounding function before applying the change. Also inspect other CreateDirRecursively()<\/code> calls in the same function, but modify only those that incorrectly receive complete file paths.<\/p>\n\n\n\n6.4 Rebuild and test<\/h3>\n\n\n\n
After editing the source:<\/p>\n\n\n\n
\n- Rebuild the Code::Blocks SDK.<\/li>\n\n\n\n
- Rebuild the relevant application components.<\/li>\n\n\n\n
- Start the newly built Code::Blocks executable.<\/li>\n\n\n\n
- Create a new project from the affected user-defined template.<\/li>\n\n\n\n
- Check the resulting project directory.<\/li>\n<\/ol>\n\n\n\n
The expected result is that main.cpp<\/code> and the other template files are created as files rather than directories.<\/p>\n\n\n\n7. Save the Fix as an SVN Patch<\/h2>\n\n\n\n
Before submitting the change, inspect the working copy.<\/p>\n\n\n\n
Open a Command Prompt:<\/p>\n\n\n\n
cd \/d C:\\CodeBlocks\\14057\\src\nsvn status<\/code><\/pre>\n\n\n\nCheck that the intended source file appears as modified:<\/p>\n\n\n\n
M sdk\/templatemanager.cpp<\/code><\/pre>\n\n\n\nCreate a patch on the desktop:<\/p>\n\n\n\n
svn diff sdk\\templatemanager.cpp > \"%USERPROFILE%\\Desktop\\templatemanager.patch\"<\/code><\/pre>\n\n\n\nReview the patch before submitting it.<\/p>\n\n\n\n
If you have repository write access, update your working copy, resolve any conflicts and test the change again before committing.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
svn update\nsvn diff sdk\\templatemanager.cpp\nsvn commit sdk\\templatemanager.cpp -m \"Fix user template file copying\"<\/code><\/pre>\n\n\n\nIf you do not have write access, submit the patch through the project’s accepted contribution process instead.<\/p>\n\n\n\n
<\/p>\n\n\n\n
8. Quick Reference: Commands and Paths<\/h2>\n\n\n\nCompiler<\/h3>\n\n\n\nD:\\mingw\\gcc16\\bin<\/code><\/pre>\n\n\n\nwxWidgets<\/h3>\n\n\n\nD:\\wx\\3.3.4<\/code><\/pre>\n\n\n\nCode::Blocks source<\/h3>\n\n\n\nC:\\CodeBlocks\\14057\\src<\/code><\/pre>\n\n\n\nVerify GCC<\/h3>\n\n\n\ng++ --version\ngcc --version\nmingw32-make --version<\/code><\/pre>\n\n\n\nBuild wxWidgets<\/h3>\n\n\n\n
Run from the directory containing makefile.gcc<\/code>:<\/p>\n\n\n\nmingw32-make -f makefile.gcc -j8 SHELL=cmd.exe SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1<\/code><\/pre>\n\n\n\nFind the template implementation<\/h3>\n\n\n\nsrc\/sdk\/templatemanager.cpp<\/code><\/pre>\n\n\n\nCheck SVN changes<\/h3>\n\n\n\ncd \/d C:\\CodeBlocks\\14057\\src\nsvn status<\/code><\/pre>\n\n\n\nCreate the patch<\/h3>\n\n\n\nsvn diff sdk\\templatemanager.cpp > \"%USERPROFILE%\\Desktop\\templatemanager.patch\"<\/code><\/pre>\n\n\n\n
\n\n\n\nFinal Notes<\/h2>\n\n\n\n
The most important lesson from this exercise is that a successful build and a correct application are two different things.<\/p>\n\n\n\n
The GCC and wxWidgets setup required careful configuration, especially the explicit Windows shell and consistent library paths. But the original template failure was a source-code logic bug: a complete file path was being used where only a directory path should have been supplied.<\/p>\n\n\n\n
Correcting that path allowed Code::Blocks to create the directory structure and copy the template files correctly.<\/p>\n\n\n\n
Keep this guide together with the patch file. If the same problem occurs again, you can reproduce the build, locate the relevant source function and apply the fix without repeating the entire investigation.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
This guide documents the steps I used to build Code::Blocks SVN revision 14057 on Windows and fix a bug that caused user-defined project templates to create directories instead of files. The goal is to have a working development environment that can be reproduced later without having to rediscover all the configuration details. 1. The Problem:… Continue reading How to Build Code::Blocks SVN 14057 with GCC 16.2.0 and wxWidgets 3.3.4 \u2014 and Fix User Project Templates<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-731","post","type-post","status-publish","format-standard","hentry","category-bash","entry"],"_links":{"self":[{"href":"https:\/\/wp.oktay.com\/index.php?rest_route=\/wp\/v2\/posts\/731","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wp.oktay.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wp.oktay.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wp.oktay.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wp.oktay.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=731"}],"version-history":[{"count":6,"href":"https:\/\/wp.oktay.com\/index.php?rest_route=\/wp\/v2\/posts\/731\/revisions"}],"predecessor-version":[{"id":749,"href":"https:\/\/wp.oktay.com\/index.php?rest_route=\/wp\/v2\/posts\/731\/revisions\/749"}],"wp:attachment":[{"href":"https:\/\/wp.oktay.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=731"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wp.oktay.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=731"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wp.oktay.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=731"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}