News:

Accounts with zero posts and zero activity during the last months will be deleted periodically to fight SPAM!

Main Menu

Build C::B against wx3.02 with gcc 5.2 under Windows

Started by ollydbg, September 27, 2015, 04:02:20 AM

Previous topic - Next topic

ollydbg

Quote from: stahta01 on September 28, 2015, 10:08:42 PM
New warning that looks like a real problem to me.

MSys2 32 bit MinGW GCC 5.2 compiler.

Tim S.


src\plugins\contrib\wxSmith\wxwidgets\defitems\wxsfontpickerctrl.cpp|70|warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]|

Line 70 to 72 below

            if(!sFnt.Len() > 0){
                sFntName = wxT("wxNullFont");
            }

Good catch, so it should be "if(sFnt.Len() == 0)", right?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

stahta01

Quote from: ollydbg on September 29, 2015, 12:23:39 AM
Quote from: stahta01 on September 28, 2015, 10:08:42 PM
New warning that looks like a real problem to me.

MSys2 32 bit MinGW GCC 5.2 compiler.

Tim S.


src\plugins\contrib\wxSmith\wxwidgets\defitems\wxsfontpickerctrl.cpp|70|warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]|

Line 70 to 72 below

            if(!sFnt.Len() > 0){
                sFntName = wxT("wxNullFont");
            }

Good catch, so it should be "if(sFnt.Len() == 0)", right?

I had no idea; just thought the way it was looked very wrong.

Tim S.
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

ollydbg

First, I guess my Windows XP is broken, but I copy tim's built(which he build from win7) to another Windows XP computer, and I see the same crash there.

I build a wx3.0.2 release library which has debug information(has -g compiler option added)
Which shows some more detailed stack back trace, but still no idea where the crash come from:

Details are in a question I asked wx-user forum: help: wired crash issue which only happens in Windows XP system with release build of wx 3.0.2.

While, the wx3.0.2 debug library works quite well(no crash here).

It looks like the bug are inside the Destroy() function of the whole GUI, which handling the AUI window. I have some test, if I put only two plugin dlls along with C::B, and in their OnAttach() function, I remove the code snippet:

    CodeBlocksDockEvent evt(cbEVT_ADD_DOCK_WINDOW);
    ....
    Manager::Get()->ProcessEvent(evt);

Then, I don't see the crash.

Second issue is that OnRelease code, I see some code just do this:

        // remove tree from docking system
        CodeBlocksDockEvent evt(cbEVT_REMOVE_DOCK_WINDOW);
        evt.pWindow = m_pTree;
        Manager::Get()->ProcessEvent(evt);

        // finally destroy the tree
        m_pTree->Destroy();
        m_pTree = nullptr;

But this is not correct, because if the function parameter "appShutDown" is true, the "Manager::Get()->ProcessEvent(evt)" just dose nothing.

Third issue
is how to remove the images created before the wxTree?
When in OnAttach(), we have:

    m_pTree = new wxTreeCtrl();
    ...
    m_pImages = new wxImageList(16, 16);
    ....
    m_pTree->SetImageList(m_pImages);


But if the destroy of the wxTreeCtrl is done inside the Aui window system(as I said in second issue), what is the time to delete the m_pImages?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

Quote from: scarphin on September 28, 2015, 04:43:30 PM
Quote from: ollydbg on September 28, 2015, 03:47:15 PM
EDIT:
When using the BUILD=debug option to build wxWidgets 3.0.2, it actually use the "-O0" option for the G++ compiler, while BUILD=release uses the "-O2" option instead, thus I believe the "-O2" cause the crash issue.
I use '-o3' for my x32 and x64 builds all the time and I don't have such a crash issue. My version for mingw-builds is 4.9.2 though. I used your method to overcome the pch issue to be able to compile 64-bit cb. Maybe you should try '-o3'.
Currently, I would still suggest using -O0 option to build both wxWidgets 3.0.2 and C::B trunk, at least it don't crash on my windows XP.
Do you have a 32 bit C::B (include the wx 3.0.2 library)which you build with '-o3' option? If you don't have a Windows XP system, You can upload some where, and PM the link, I'd like to test it, thanks.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

One thing I noticed when we build the "codeblocks.exe" (the target we named "src"), I see the "BUILDING_PLUGIN" is defined, this is much similar like building other plugin dlls. This enables the __declspec(dllexport) option.

Remove this "BUILDING_PLUGIN" is OK for the src target, but which cause the PCH file used for codeblocks.exe and other plugin dlls can't be shared. So, that's the reason we keep it there. :)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

One thing I forgot to mention is that switch between wx3.0.2 debug or release library is quite simple, you just need to change the link library name.

src/CodeBlocks_wx30.cbp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/CodeBlocks_wx30.cbp b/src/CodeBlocks_wx30.cbp
index 61c6659..7b04c37 100644
--- a/src/CodeBlocks_wx30.cbp
+++ b/src/CodeBlocks_wx30.cbp
@@ -700,7 +700,7 @@
</Target>
<Environment>
<Variable name="WX_CFG" value="" />
- <Variable name="WX_SUFFIX" value="u" />
+ <Variable name="WX_SUFFIX" value="ud" />
<Variable name="WX_VERSION" value="30" />
</Environment>


No need to add the "__WXDEBUG__" for the debug version, since both debug and release version of wxWidgets library have "__WXDEBUG__" defined.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

Quote from: ollydbg on September 27, 2015, 09:18:08 AM
After finishing building CodeBlocks_wx30.cbp and running update30.bat, I just start C::B inside C::B.
The first thing I see is a dialog from wx, says
Quote
15:23:36: Resource files must have same version number.
15:23:38: Resource files must have same version number.
I think I have reported some where in this forum, but it is lost...
It is here: warning message about resource version number incorrect, and the two warning above was caused by local patch files which does not belong to C::B trunk.  :)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

MortenMacFly

Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

MortenMacFly

Quote from: ollydbg on October 04, 2015, 01:24:26 PM
It is here: warning message about resource version number incorrect, and the two warning above was caused by local patch files which does not belong to C::B trunk.  :)
I've answered in the other thread.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

scarphin

Quote from: ollydbg on October 04, 2015, 10:09:25 AM
Quote from: scarphin on September 28, 2015, 04:43:30 PM
I use '-o3' for my x32 and x64 builds all the time and I don't have such a crash issue. My version for mingw-builds is 4.9.2 though. I used your method to overcome the pch issue to be able to compile 64-bit cb. Maybe you should try '-o3'.
Currently, I would still suggest using -O0 option to build both wxWidgets 3.0.2 and C::B trunk, at least it don't crash on my windows XP.
Do you have a 32 bit C::B (include the wx 3.0.2 library)which you build with '-o3' option? If you don't have a Windows XP system, You can upload some where, and PM the link, I'd like to test it, thanks.
Hmm, I think my comment caused a confusion, my apologies. I'm not using cb with wx3.0, I'm still using it with wx2.8. I just wanted to emphasize that using '-o3' doesn't make my build crash or behave abnormal in some way. It's just as stable as a normal nightly if not more. I also built wx2.8 with default release option, I think it is '-o2' and I didn't change it. Sorry for the confusion again. I'm very busy currently to make any wx3.0 build but I think I have a ready to use wx3.0 build so I may try building cb when and if I can find some time. Do you require an xp or a win7 build? I'll pm you a link if I success (again if I can find some time, no promises ;)). Lastly be aware I'm using mingw-builds compiler not tdm if that matters.

stahta01

#40
Do you have issue with CB locking up when you run ProjectOptionsManipulator wx3.0 compiled with gcc 5.2 under windows?
I am testing a modified version of SVN rev 10515 and once I try to bring up the ProjectOptionsManipulator CB stops responding.

wxWidgets 3.02
Windows 7 64 bit
MSys2 MinGW64 GCC 5.2 64 bit

Edit: I am going to try upgrading to a newer SVN rev to see if that fixes the problem.

Tim S.



C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

ollydbg

#41
Quote from: stahta01 on October 05, 2015, 02:01:06 AM
Do you have issue with CB locking up when you run ProjectOptionsManipulator wx3.0 compiled with gcc 5.2 under windows?
I am testing a modified version of SVN rev 10515 and once I try to bring up the ProjectOptionsManipulator CB stops responding.

wxWidgets 3.02
Windows 7 64 bit
MSys2 MinGW64 GCC 5.2 64 bit

Edit: I am going to try upgrading to a newer SVN rev to see if that fixes the problem.

Tim S.
I just build this plugin, and I can enable or disable this plugin in C::B's plugin manager, no crash here. I'm also using rev10515, wxWidgts and C::B are all build with "-O0".

EDIT: I can use this plugin to search something in a C::B project, works fine here. :)

EDIT2 I get wired compiler warnings which point to a "}" in the cpp file:

-------------- Build: default in ProjectOptionsManipulator wx3.0.x (compiler: GNU GCC Compiler)---------------

[ 25.0%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -DBUILDING_PLUGIN -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DwxUSE_UNICODE -I..\..\..\include -I..\..\..\sdk\wxscintilla\include -ID:\wx3\include -ID:\wx3\lib\gcc_dll\mswud -c ProjectOptionsManipulator.cpp -o ..\..\..\.objs30\plugins\contrib\ProjectOptionsManipulator\ProjectOptionsManipulator.o
ProjectOptionsManipulator.cpp:1178:1: warning: 'virtual bool wxEvtHandler::TryValidator(wxEvent&)' is deprecated [-Wdeprecated-declarations]
}
^
In file included from D:\wx3\include/wx/string.h:24:0,
                 from ProjectOptionsManipulator.h:9,
                 from ProjectOptionsManipulator.cpp:10:
D:\wx3\include/wx/event.h:3683:22: note: declared here
         virtual bool TryValidator(wxEvent& WXUNUSED(event)), return false; )
                      ^
D:\wx3\include/wx/defs.h:641:43: note: in definition of macro 'wxDEPRECATED'
#define wxDEPRECATED(x) wxDEPRECATED_DECL x
                                           ^
D:\wx3\include/wx/event.h:3682:5: note: in expansion of macro 'wxDEPRECATED_BUT_USED_INTERNALLY_INLINE'
     wxDEPRECATED_BUT_USED_INTERNALLY_INLINE(
     ^
ProjectOptionsManipulator.cpp:1178:1: warning: 'virtual bool wxEvtHandler::TryParent(wxEvent&)' is deprecated [-Wdeprecated-declarations]
}
^
In file included from D:\wx3\include/wx/string.h:24:0,
                 from ProjectOptionsManipulator.h:9,
                 from ProjectOptionsManipulator.cpp:10:
D:\wx3\include/wx/event.h:3686:22: note: declared here
         virtual bool TryParent(wxEvent& event), return DoTryApp(event); )
                      ^
D:\wx3\include/wx/defs.h:641:43: note: in definition of macro 'wxDEPRECATED'
#define wxDEPRECATED(x) wxDEPRECATED_DECL x
                                           ^
D:\wx3\include/wx/event.h:3685:5: note: in expansion of macro 'wxDEPRECATED_BUT_USED_INTERNALLY_INLINE'
     wxDEPRECATED_BUT_USED_INTERNALLY_INLINE(
     ^
ProjectOptionsManipulator.cpp:1178:1: warning: 'virtual bool wxEvtHandler::TryValidator(wxEvent&)' is deprecated [-Wdeprecated-declarations]
...

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

Quote from: scarphin on October 04, 2015, 10:23:13 PM
...
Do you require an xp or a win7 build? I'll pm you a link if I success (again if I can find some time, no promises ;)). Lastly be aware I'm using mingw-builds compiler not tdm if that matters.
I mean if you build a 32 bit binary C::B, I can test it on my 32bit winXP. Thanks.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

#43
Hi, Tim, I just looked at the PCH relate topic, and I see that "WX_PRECOMP" is not needed in the codeblocks.cbp or codeblocks_w30.cbp, since we don't need a wx/wxprec.h in our C::B project, also we don't need to generate a single wxprec.h.gch. Since sdk.h already includes all the wx/xxx.h C::B needed, See our discussion here: patch to build C::B against wx 3.0 with PCH enabled

EDIT:
In the sdk_common.h, we have such code

#if defined(NOPCH)
    #undef CB_PRECOMP
#endif // NOPCH

#if ( defined(CB_PRECOMP) && !defined(WX_PRECOMP) )
    #define WX_PRECOMP
#endif // CB_PRECOMP

// basic wxWidgets headers : this one itself will check for precompiled headers
// and if so will include a list of wx headers, at the bottom we add some more headers
// in the case of precompilation (note : some headers are in both lists)
// so even if NO CB_PRECOMP we can still have WX_PRECOMP turned on in this "wxprec" header
#include <wx/wxprec.h>

#ifdef __BORLANDC__
#pragma hdrstop
#endif

#include "prep.h" // this is deliberately not inside the #ifdef block

#ifdef CB_PRECOMP

    // some common wxWidgets headers
    #include <wx/arrstr.h>
    #include <wx/button.h>
    #include <wx/checkbox.h>
    #include <wx/checklst.h>
    #include <wx/choice.h>
    #include <wx/colordlg.h>
    #include <wx/combobox.h>
    #include <wx/confbase.h>
    #include <wx/datetime.h>
    #include <wx/dialog.h>
    #include <wx/dir.h>
    #include <wx/dynarray.h>
    #include <wx/event.h>
    #include <wx/file.h>
    #include <wx/filename.h>
    #include <wx/font.h>
    #include <wx/frame.h>
    #include <wx/fs_zip.h>
    #include <wx/hashmap.h>
    #include <wx/image.h>
    #include <wx/imaglist.h>
    #include <wx/intl.h>
    #include <wx/list.h>
    #include <wx/listbox.h>
    #include <wx/listctrl.h>
    #include <wx/log.h>
    #include <wx/menu.h>
    #include <wx/menuitem.h>
    #include <wx/msgdlg.h>
    #include <wx/notebook.h>
    #include <wx/panel.h>
    #include <wx/print.h>
    #include <wx/process.h>
    #include <wx/radiobox.h>
    #include <wx/radiobut.h>
    #include <wx/regex.h>
    #include <wx/sizer.h>
    #include <wx/socket.h>
    #include <wx/spinctrl.h>
    #include <wx/splitter.h>
    #include <wx/stattext.h>
    #include <wx/string.h>
    #include <wx/textctrl.h>
    #include <wx/thread.h>
    #include <wx/timer.h>
    #include <wx/toolbar.h>
    #include <wx/treectrl.h>
    #include <wx/txtstrm.h>
    #include <wx/utils.h>
    #include <wx/wfstream.h>
    #include <wx/wxscintilla.h>
    #include <wx/xrc/xmlres.h>

    // basic headers
    #include "settings.h"
    #include "globals.h"
    #include "sdk_events.h"
    #include "cbexception.h"

    // absolute base classes
    #include "logger.h"
    #include "editorbase.h"
    #include "cbeditor.h"
    #include "compileoptionsbase.h"
    #include "compiletargetbase.h"
    #include "projectbuildtarget.h"
    #include "projectfile.h"
    #include "cbplugin.h"
    #include "cbproject.h"
    #include "cbtool.h"
    #include "cbworkspace.h"
    #include "compilerfactory.h"
    #include "compiler.h"
    #include "workspaceloader.h"
    #include "editorcolourset.h"
    #include "pipedprocess.h"
    #include "scrollingdialog.h"
    #include "cbauibook.h"


    // managers
    #include "manager.h"
    #include "configmanager.h"
    #include "editormanager.h"
    #include "logmanager.h"
    #include "projectmanager.h"
    #include "menuitemsmanager.h"
    #include "scriptingmanager.h"
    #include "toolsmanager.h"
    #include "templatemanager.h"
    #include "macrosmanager.h"
    #include "pluginmanager.h"
    #include "personalitymanager.h"
    #include "uservarmanager.h"
    #include "filemanager.h"

    // other base files
    #include "xtra_res.h"
    #include "safedelete.h"
    #include "infowindow.h"
    #include "licenses.h"

#endif // CB_PRECOMP



So, if wx/wxprec.h contains some extra header files we don't needed. Such as the ones not in below #ifdef

#ifdef CB_PRECOMP

    // some common wxWidgets headers
    #include <wx/arrstr.h>
    #include <wx/button.h>
    #include <wx/checkbox.h>
    #include <wx/checklst.h>
    ...


If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

stahta01

#44
Quote from: ollydbg on October 05, 2015, 07:44:05 AM
Hi, Tim, I just looked at the PCH relate topic, and I see that "WX_PRECOMP" is not needed in the codeblocks.cbp or codeblocks_w30.cbp, since we don't need a wx/wxprec.h in our C::B project, also we don't need to generate a single wxprec.h.gch. Since sdk.h already includes all the wx/xxx.h C::B needed, See our discussion here: patch to build C::B against wx 3.0 with PCH enabled

EDIT:
In the sdk_common.h, we have such code

#if defined(NOPCH)
    #undef CB_PRECOMP
#endif // NOPCH

#if ( defined(CB_PRECOMP) && !defined(WX_PRECOMP) )
    #define WX_PRECOMP
#endif // CB_PRECOMP

// basic wxWidgets headers : this one itself will check for precompiled headers
// and if so will include a list of wx headers, at the bottom we add some more headers
// in the case of precompilation (note : some headers are in both lists)
// so even if NO CB_PRECOMP we can still have WX_PRECOMP turned on in this "wxprec" header
#include <wx/wxprec.h>

#ifdef __BORLANDC__
#pragma hdrstop
#endif

#include "prep.h" // this is deliberately not inside the #ifdef block

#ifdef CB_PRECOMP

    // some common wxWidgets headers
    #include <wx/arrstr.h>
    #include <wx/button.h>
    #include <wx/checkbox.h>
    #include <wx/checklst.h>
    #include <wx/choice.h>
    #include <wx/colordlg.h>
    #include <wx/combobox.h>
    #include <wx/confbase.h>
    #include <wx/datetime.h>
    #include <wx/dialog.h>
    #include <wx/dir.h>
    #include <wx/dynarray.h>
    #include <wx/event.h>
    #include <wx/file.h>
    #include <wx/filename.h>
    #include <wx/font.h>
    #include <wx/frame.h>
    #include <wx/fs_zip.h>
    #include <wx/hashmap.h>
    #include <wx/image.h>
    #include <wx/imaglist.h>
    #include <wx/intl.h>
    #include <wx/list.h>
    #include <wx/listbox.h>
    #include <wx/listctrl.h>
    #include <wx/log.h>
    #include <wx/menu.h>
    #include <wx/menuitem.h>
    #include <wx/msgdlg.h>
    #include <wx/notebook.h>
    #include <wx/panel.h>
    #include <wx/print.h>
    #include <wx/process.h>
    #include <wx/radiobox.h>
    #include <wx/radiobut.h>
    #include <wx/regex.h>
    #include <wx/sizer.h>
    #include <wx/socket.h>
    #include <wx/spinctrl.h>
    #include <wx/splitter.h>
    #include <wx/stattext.h>
    #include <wx/string.h>
    #include <wx/textctrl.h>
    #include <wx/thread.h>
    #include <wx/timer.h>
    #include <wx/toolbar.h>
    #include <wx/treectrl.h>
    #include <wx/txtstrm.h>
    #include <wx/utils.h>
    #include <wx/wfstream.h>
    #include <wx/wxscintilla.h>
    #include <wx/xrc/xmlres.h>

    // basic headers
    #include "settings.h"
    #include "globals.h"
    #include "sdk_events.h"
    #include "cbexception.h"

    // absolute base classes
    #include "logger.h"
    #include "editorbase.h"
    #include "cbeditor.h"
    #include "compileoptionsbase.h"
    #include "compiletargetbase.h"
    #include "projectbuildtarget.h"
    #include "projectfile.h"
    #include "cbplugin.h"
    #include "cbproject.h"
    #include "cbtool.h"
    #include "cbworkspace.h"
    #include "compilerfactory.h"
    #include "compiler.h"
    #include "workspaceloader.h"
    #include "editorcolourset.h"
    #include "pipedprocess.h"
    #include "scrollingdialog.h"
    #include "cbauibook.h"


    // managers
    #include "manager.h"
    #include "configmanager.h"
    #include "editormanager.h"
    #include "logmanager.h"
    #include "projectmanager.h"
    #include "menuitemsmanager.h"
    #include "scriptingmanager.h"
    #include "toolsmanager.h"
    #include "templatemanager.h"
    #include "macrosmanager.h"
    #include "pluginmanager.h"
    #include "personalitymanager.h"
    #include "uservarmanager.h"
    #include "filemanager.h"

    // other base files
    #include "xtra_res.h"
    #include "safedelete.h"
    #include "infowindow.h"
    #include "licenses.h"

#endif // CB_PRECOMP



So, if wx/wxprec.h contains some extra header files we don't needed. Such as the ones not in below #ifdef

#ifdef CB_PRECOMP

    // some common wxWidgets headers
    #include <wx/arrstr.h>
    #include <wx/button.h>
    #include <wx/checkbox.h>
    #include <wx/checklst.h>
    ...


I agree that setting WX_PRECOMP in any cbp files is NOT needed or wanted. But, remember for Windows we still need both headers sdk.h and sdk_precomp.h (might have misspelled the second one).

Edit: I think you are asking if we must include the wx PCH header inside sdk_common.h header; the answer is no; but, it tends to result in a few weird errors at times when Compiling CB against 3.0.x branch and 3.1.x master branch.
Most of the errors go away if we include wx/defs.h before any wx header inside the sdk_common.h header.
The rest would likely need to be fixed on a case by case basis.


Note: I have decided that "sdk" is more accurate than <sdk.h> because the PCH file is always a local project file and never a system header using MinGW GCC and likely all GCC are the same. Not, sure about other compilers.

Tim S.
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]