Build CodeBlocks using Microsoft Visual C++

[Loaden]

Hi, All, I am try building CB using MSVC, But have some linker error, and can not solved it.
I am need your help.
Many thanks!

scriptingsettingsdlg.obj||error LNK2001: unresolved external symbol "public: virtual bool __thiscall wxDialogHelper::DoLayoutAdaptation(void)" (?DoLayoutAdaptation@wxDialogHelper@@UAE_NXZ)|
switcherdlg.obj||error LNK2001: unresolved external symbol "public: virtual bool __thiscall wxDialogHelper::DoLayoutAdaptation(void)" (?DoLayoutAdaptation@wxDialogHelper@@UAE_NXZ)|
dlgaboutplugin.obj||error LNK2001: unresolved external symbol "public: virtual bool __thiscall wxDialogHelper::DoLayoutAdaptation(void)" (?DoLayoutAdaptation@wxDialogHelper@@UAE_NXZ)|
environmentsettingsdlg.obj||error LNK2001: unresolved external symbol "public: virtual bool __thiscall wxDialogHelper::DoLayoutAdaptation(void)" (?DoLayoutAdaptation@wxDialogHelper@@UAE_NXZ)|
main.obj||error LNK2019: unresolved external symbol "public: virtual bool __thiscall wxDialogHelper::DoLayoutAdaptation(void)" (?DoLayoutAdaptation@wxDialogHelper@@UAE_NXZ) referenced in function "bool __cdecl SqPlus::Match(struct SqPlus::TypeWrapper<bool>,struct SQVM *,int)" (?Match@SqPlus@@YA_NU?$TypeWrapper@_N@1@PAUSQVM@@H@Z)|
printdlg.obj||error LNK2001: unresolved external symbol "public: virtual bool __thiscall wxDialogHelper::DoLayoutAdaptation(void)" (?DoLayoutAdaptation@wxDialogHelper@@UAE_NXZ)|
app.obj||error LNK2001: unresolved external symbol "public: virtual bool __thiscall wxDialogHelper::DoLayoutAdaptation(void)" (?DoLayoutAdaptation@wxDialogHelper@@UAE_NXZ)|
........
........
||More errors follow but not being shown.|
||Edit the max errors limit in compiler options...|
||=== Build finished: 50 errors, 0 warnings (0 minutes, 54 seconds) ===|

[oBFusCATed]

What is your wx version? 2.9 probably?
If it is 2.8 check if you compile the scrollingdialog.cpp correctly.

[Loaden]

What is your wx version? 2.9 probably?
If it is 2.8 check if you compile the scrollingdialog.cpp correctly.

It's 2.8.12, And I can sure scrollingdialog.cpp been compiled.

[xunxun]

Yes, scrollingdialog.cpp is really compiled, but in my surprise, CodeBlocks.lib doesn't contain any wxDialogHelper's symbol.

[ollydbg]

@loaden
someone has used a msvc compiler to build the codeblocks, he just released it on sourceforge. Sorry I can't find the link now.

[Loaden]

Yes, scrollingdialog.cpp is really compiled, but in my surprise, CodeBlocks.lib doesn't contain any wxDialogHelper's symbol.

I am think so, but I can't find the reason.
In V2, I am using /OPT:NOREF and /OPT:NOICF, But not work too.

[Loaden]

@loaden
someone has used a msvc compiler to build the codeblocks, he just released it on sourceforge. Sorry I can't find the link now.

OK, I try search now.

[xunxun]

I try to change CodeBlocks.lib(dynamic lib) to static lib and add /ignore:4006 /ignore:4221 to linker option.
The LNK1189 error comes out : The limit of 65535 objects or members in a library has been exceeded.

[Loaden]

I try to change CodeBlocks.lib(dynamic lib) to static lib and add /ignore:4006 /ignore:4221 to linker option.
The LNK1189 error comes out : The limit of 65535 objects or members in a library has been exceeded.

We can't build the SDK to static lib, because there have many plugins need the SDK.
Now I find a reason, that we need make it import.
like:
class DLLIMPORT wxDialogHelper
{

[xunxun]

I try to change CodeBlocks.lib(dynamic lib) to static lib and add /ignore:4006 /ignore:4221 to linker option.
The LNK1189 error comes out : The limit of 65535 objects or members in a library has been exceeded.

We can't build the SDK to static lib, because there have many plugins need the SDK.
Now I find a reason, that we need make it import.
like:
class DLLIMPORT wxDialogHelper
{

That's right. I have found it just now.

[MortenMacFly]

@loaden
someone has used a msvc compiler to build the codeblocks, he just released it on sourceforge. Sorry I can't find the link now.

OK, I try search now.

It's here:
http://forums.codeblocks.org/index.php/topic,13454.msg90615.html#msg90615
(http://cb4vc.sourceforge.net/)

But I see no reason why we should try to make C::B compile with VC. C::B was designed to support the GCC compiler and only the GCC compiler. Support for VC will force us to use a lot of #defines which will make the code look very ugly and this is clearly not what we want. In the fact we've removed a lot portions in the code concerning VC (like pragmas and alike) because it really made the code hard to read. So whatever you come out with, please do not commit.

[Loaden]

Success for Release Build, But still occured some error when use Debug build.

advancedcompileroptionsdlg.obj||error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl wxOnAssert(wchar_t const *,int,char const *,wchar_t const *,wchar_t const *)" (__imp_?wxOnAssert@@YAXPB_WHPBD00@Z) referenced in function "void * __cdecl wxCheckCast(void *)" (?wxCheckCast@@YAPAXPAX@Z)|
compilererrors.obj||error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl wxOnAssert(wchar_t const *,int,char const *,wchar_t const *,wchar_t const *)" (__imp_?wxOnAssert@@YAXPB_WHPBD00@Z)|
compilergcc.obj||error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl wxOnAssert(wchar_t const *,int,char const *,wchar_t const *,wchar_t const *)" (__imp_?wxOnAssert@@YAXPB_WHPBD00@Z)|
compileroptionsdlg.obj||error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl wxOnAssert(wchar_t const *,int,char const *,wchar_t const *,wchar_t const *)" (__imp_?wxOnAssert@@YAXPB_WHPBD00@Z)|

[Loaden]

It's here:
http://forums.codeblocks.org/index.php/topic,13454.msg90615.html#msg90615
(http://cb4vc.sourceforge.net/)

Thanks!!

But I see no reason why we should try to make C::B compile with VC. C::B was designed to support the GCC compiler and only the GCC compiler. Support for VC will force us to use a lot of #defines which will make the code look very ugly and this is clearly not what we want. In the fact we've removed a lot portions in the code concerning VC (like pragmas and alike) because it really made the code hard to read. So whatever you come out with, please do not commit.

I don't think so, Only need a little guard code (like #ifdef _MSC_VER), and seems very clearly.

Some reasons:
1. Use MSVC's Debug Tools for find some crash
2. Get VC compiler warnings to correct the code
3. VC is better and faster than GCC in Windows OS

Morten, could you view the patch? If you fell the VC Support Code is so *ugly*.

[Loaden]

BTW, The V6 patch only support mini core CB code now.
In currently, there not include Debugger, OpenFileList....

When using GDB, some crash is difficult to capture.
I think this project (for MSVC) should be usefull.

[ollydbg]

@loaden
it seems you add a lot of DLLIMPORT before the class declaration. But why they are not needed when build with MinGW GCC?

You patches v6 contains a lot of duplicated piece code. (which means: you don't change anything on the code, maybe, there are some space, tabs added/moved)

From my point of view, if the change code is quite minimal, then I think adding for the VC build could be added.

[xunxun]

@loaden
it seems you add a lot of DLLIMPORT before the class declaration. But why they are not needed when build with MinGW GCC?

Because MinGW GCC export  all symbols defaultly.

[Loaden]

@loaden
You patches v6 contains a lot of duplicated piece code. (which means: you don't change anything on the code, maybe, there are some space, tabs added/moved)

Sure, I am re-make the patch now.

[attachment deleted by admin]

[oBFusCATed]

Simple question: have you tried to compile C::B with gcc on windows and linux with your patch applied, I think you will have problems
Also why is that "" to _T("") needed all over the place?

I don't think so, Only need a little guard code (like #ifdef _MSC_VER), and seems very clearly.

Hm, your patch is 120+ KB, so the changes aren't minimal

Also:
1. Have you tried to use something different from vc 2010?
2. Don't compile add C++ features to C files (VC always compiles .c files as C++ and you should tell it to compile it as C with some compiler flag) (I'm talking about the files in depslib)
3. Don't call that start with _ they are MS only most of the time
4. When there is a missing function, you should reimplement it, not add #ifdef #else #endif guards

[Loaden]

Simple question: have you tried to compile C::B with gcc on windows and linux with your patch applied, I think you will have problems

I am *only* test it using GCC 4.4.4 on Windows 7 SP1 / XPSP3, and it's works well.

I don't think so, Only need a little guard code (like #ifdef _MSC_VER), and seems very clearly.

Hm, your patch is 120+ KB, so the changes aren't minimal

Most of them are Multi-line String fixed.
e.g.
Change from:
_("aaa"
   "bbb")
TO:
_("aaa"
   _T("bbb"))

Also:
1. Have you tried to use something different from vc 2010?
2. Don't compile add C++ features to C files (VC always compiles .c files as C++ and you should tell it to compile it as C with some compiler flag) (I'm talking about the files in depslib)
3. Don't call that start with _ they are MS only most of the time
4. When there is a missing function, you should reimplement it, not add #ifdef #else #endif guards

1. No
2. I am using /TP flags, Why not? What is the reason?
3. Revert the changes in V8 patch
4. Only two case:
   (1)
   #ifndef _MSC_VER // TODO (Loaden#5#) error C2017: illegal escape sequence
        Quoted.Replace(wxString(_T("‘")), _T("\""), true);
        Quoted.Replace(_T("’"), _T("\""), true);
   #endif
   (2)
   #ifndef _MSC_VER // TODO (Loaden#1#) MSVC can't support gettimeofday
   #include <sys/time.h>
   #endif

Many thanks for feedback!!

[ollydbg]

Hey, loaden, unpack the 23K 7zip file, the patch is still 131K, Oh my God.

But, I review the patch, it does change only a little code.

[Loaden]

BTW: V8 patch can be compiled in two modes, Debug or Release, But it can't work, when startup, CB will crash.
Here is the V8 project.

[Loaden]

Hey, loaden, unpack the 23K 7zip file, the patch is still 131K, Oh my God.

But, I review the patch, it does change only a little code.

The most important is that it's without any side effects when compile CB based on GCC compiler.
Able to compile at least have taken the first step!
But currently the CB of compiled with MSVC does not work.
Welcome to test and improve!

As I know, QtCreator use the VC compiler to release the binary.
 

[MortenMacFly]

I personally believe targeting MSVC compilation is a waste of time, really, as this not requested and needed at all. And I doubt that there will be a speed improvement. Looking at the patch I see it brings back the clutter we had just removed. And having this patch applied I can no longer compile C::B using MinGW/GCC... so what's the purpose? :shock:

More important, however, is to improve the support for the MSVC compiler inside C::B. MSVC10 is still not 100% supported (I am working on that).

Also (if you are looking for some work to do ;-)) CC freezes C::B completely if you do a massive search-and-replace in many files across a large (C::B) workspace with multiple projects. This is truly annoying.

[Loaden]

My Linux OS can not startup now.
Could someone help test V8 patch on Unix?
Thanks!

[Loaden]

Also (if you are looking for some work to do ;-)) CC freezes C::B completely if you do a massive search-and-replace in many files across a large (C::B) workspace with multiple projects. This is truly annoying.

That's is a reason to support MSVC.
Because I need MSVC's Debug Tools (or WinDbg), and I need create a dump file use dbghelp.dll.
In CC, there has a crash, But use GDB, I can't catch it!

[oBFusCATed]

Why do you think cdb/windbg is better in this?
Why don't you install linux and then use valgrind to see if you're not doing something wrong with the memory?

[MortenMacFly]

Why do you think cdb/windbg is better in this?

I think what Loaden means is not the debugger, but the debugger integrated in the IDE. So the target is o be able to use the MSVC IDE to debug C::B. This (in fact) might be more comfortable than C::B (although I ma very happy with C::B).

@Loaden: Did you try to connect/debug C::B using gdb from another C::B instance? This way you can debug thread issues for example...

[Jenna]

I can not apply the patch on linux. Too many errors (possible a line-ending problem).

[MortenMacFly]

Change from:
_("aaa"
   "bbb")
TO:
_("aaa"
_T("bbb"))

BTW: This will break translations IMHO, as the second part (now _T("")) will not appear in the translation tables. You should always use _("").

[ollydbg]

Also (if you are looking for some work to do ;-)) CC freezes C::B completely if you do a massive search-and-replace in many files across a large (C::B) workspace with multiple projects. This is truly annoying.

Oh, catching bugs was quite interesting and challenge for me  , but I can't find some annoying bug in CC. (though some parsing errors due to the fact that CC's parser was not a full compiler parser).
Did you use the debugged version of c::b (maybe, run under gdb) to catch some information?

[killerbot]

I have used both, and off course CB is better ;-)
But the debugging experience in Visual Studio is way better, honest is honest [better watches windows, more stable, structures in a watch or mouse over can expand, [the frontend, aka CB part] ... , and way better then GDB (the backend part)]. This is the one of the very little things on my list I would love to see on the same level in CB.

[ollydbg]

I have used both, and off course CB is better ;-)
But the debugging experience in Visual Studio is way better, honest is honest [better watches windows, more stable, structures in a watch or mouse over can expand, [the frontend, aka CB part] ... , and way better then GDB (the backend part)]. This is the one of the very little things on my list I would love to see on the same level in CB.

Visual studio's supply two versions of CRT libraries(release, debug). when debugging, the debugging CRT library give the debugger more information.(e.g. the debug CRT library can set the stack to 0xCC when entering a function, so VC debugger can easily catch some uninitialized variable, it can save some stack pointer address value, so it can check the value when the function returned).

but for gdb, it has no idea about this. I do not know whether MinGW CRT library has both release/debug CRT. So, sometimes, gdb try to resolve uninitialized memory(contains random value instead 0xcc), which mostly cause a gdb crash. So, I mostly hope a more stable debugging CRT library under MinGW to support gdb.

PS: GDB's python script can make debugging under GDB much better. MSVC as I know does not has this kind of script support.

[Loaden]

BTW: This will break translations IMHO, as the second part (now _T("")) will not appear in the translation tables. You should always use _("").

Bad news, And I can't fix this issue.

[Ceniza]

I have access to Visual Studio 2010 Professional and Intel C++ Studio XE, which means more tools that could be used to improve C::B if you manage to make it build with it.

I, on the other hand, think that Visual Studio 2010 SP1 + Visual Assist X + Intel C++ Studio XE is much better than C::B, at least from a Windows-only point of view. Price is quite a difference, but the company is paying for it.

[MortenMacFly]

Bad news, And I can't fix this issue.

Well, you'll need to do something like:
Old:

Code

_("text....\n"
   "more text...")

New:

Code

_("text....\nmore text...")

...or:

Code

wxString str = _("text....\n")
                 + _("more text...");

[oBFusCATed]

Ceniza:
You need Visual Assists in VS 2010, so they failed to make the CC work again?

It is normal for VS to be better, because it is 10+ developers working part time vs 10-20-100 working full time.
The remarkable thing is how close (and even better for some things) C::B is to VC in many aspects.

(I've not tried 2010, yet)

[Biplab]

My few cents!

First of all I'd like to say Thanks to Loaden for this effort.

I do agree VS debugger is better in some cases. I am also facing a similar issue with my 64 bit porting. GDB can't give me any meaningful reply on why C::B is crashing. So I think once C::B source can be compiled with VC, I may get some clue. Personally I am also working on patching C::B source to be compatible with VC (I have compiled upto SDK). But after Loaden's patch it will be easier for me.

I differ on some opinions expressed on using ifdefs. Personally my opinion is - as long as it doesn't affect officially supported compiler, ifdef's should be ok. They add bloat to the source; not to the binary. And with the code-folding feature in any modern IDE/Editor, it is not an issue anymore that source code will become unreadable.

Loaden & others - Keep up the good work! Cheers!

[oBFusCATed]

Biplab: debugging on 64bit is harder than 32bit in general and it is because of the way the processors work.
Have you tried to use -fno-omit-frame-pointer (inspect the manual for the correct option) (it is default on 64bit archs)?

[Ceniza]

Ceniza:
You need Visual Assists in VS 2010, so they failed to make the CC work again?

The integrated IntelliSense seems to be good (barely tried it), but Visual Assist X is just great. I had already got it before switching to VS 2010, and life is just not the same once you get used to it. The renewal is quite cheap also, and, once again, I am not the one paying for it.

I still do not get why you say 64 bits is harder to debug. You get more, and wider, registers, and the calling convention defaults to fastcall. Other than that it is pretty much the same as with 32 bits. Am I missing anything?

[oBFusCATed]

I was using VAssist and then stopped... now I'm using "find in files" or "thread search" ... and  I don't feel I've lost something in the functionality.

The backtraces have less info in them (there is a doc at work describing the problems) ...
Also http://www.rotateright.com/faq.html#UserInterface_2

[MortenMacFly]

They add bloat to the source; not to the binary. And with the code-folding feature in any modern IDE/Editor, it is not an issue anymore that source code will become unreadable.

I clearly disagree here. We are working 100% with the code, so cluttered code is bad. And we cannot selectively code-fold, just "all-or-nothing" as you know. In addition Thomas did a lot hard work to remove nasty #defines in the past which we should honor as this was our decision.

Furthermore we have SVN for exactly such trials. Such experiments should be done in a branch as it is not our overall-goal to support compilation with VC. IMHO for C::B being a cross-platform IDE it just causes more hassle than benefits. Look at the wxWidgets sources itself what hacks are in there just to support other compilers. It's OK if you need it or if it's a design decision, but both is not the case for us.

Edit: To make it clear: I don't want to stop the work, just do it in the right place. As e.g. Jens with the console branch.

[Biplab]

The backtraces have less info in them (there is a doc at work describing the problems) ...
Also http://www.rotateright.com/faq.html#UserInterface_2

Is this applicable on 64 bit Windows?

Edit: To make it clear: I don't want to stop the work, just do it in the right place. As e.g. Jens with the console branch.

If the direction is not to include such patches to trunk then it is not necessary to create a branch and then abandon it later. I'd rather keep my local copy in sync and dump the whole patched source somewhere in the web.

[MortenMacFly]

If the direction is not to include such patches to trunk then it is not necessary to create a branch and then abandon it later. I'd rather keep my local copy in sync and dump the whole patched source somewhere in the web.

I didn't mean to abandon. Its easy to keep the branch in sync with trunk. We did this so often in the past and have two active branches that do so just fine. It's an experiment in the end, needed for a special purpose from time-to-time. The main stream development has to be in MinGW/GCC.

So, whenever you need the branch make it in sync with trunk and use it. These are 3 mouse clicks in my SVN software. And once stabilised you wouldn't even cause conflicts as there won't be much changes. And if we come to design guidelines (e.g. never do something like:

Code

_("text....\n"
   "more text...")

)
...which we apply in trunk the differences will be minimised.

Why do you believe it would be better to

dump the whole patched source somewhere in the web.

then??? It will make it way harder to handle.

[Loaden]

Bad news, And I can't fix this issue.

Well, you'll need to do something like:
Old:

Code

_("text....\n"
   "more text...")

New:

Code

_("text....\nmore text...")

...or:

Code

wxString str = _("text....\n")
                 + _("more text...");

I know this, but it can't support multi-line, or lead broke the whole string.
Can someone have a better way?

[Loaden]

Hello everybody, now there is a very perplexing question: Why build CB use VC compiler will cause startup crash?
If the code is robust enough to write, then use a different compiler should be able to run.
But now I start again busy, so I can not continue.

[oBFusCATed]

Because you've not build it correctly, most probably
Or someone has done something non portable.

BTW: I'm for enabling multiple compilers, because this makes the code more robust and more portable (even with the mad vc++)

[Biplab]

If the direction is not to include such patches to trunk then it is not necessary to create a branch and then abandon it later. I'd rather keep my local copy in sync and dump the whole patched source somewhere in the web.

I didn't mean to abandon. Its easy to keep the branch in sync with trunk. We did this so often in the past and have two active branches that do so just fine. It's an experiment in the end, needed for a special purpose from time-to-time. The main stream development has to be in MinGW/GCC.

So, whenever you need the branch make it in sync with trunk and use it. These are 3 mouse clicks in my SVN software. And once stabilised you wouldn't even cause conflicts as there won't be much changes. And if we come to design guidelines (e.g. never do something like:

Code

_("text....\n"
   "more text...")

)
...which we apply in trunk the differences will be minimised.

If we have too many branches I believe we will end up in merge conflict while keeping them in sync. And we also need somebody to maintain it. Using #ifdef is much easier than than doing a merge every now & then and most importantly it will not touch officially supported code. Anyway it's a personal preference.

Why do you believe it would be better to

dump the whole patched source somewhere in the web.

then??? It will make it way harder to handle.

Interested ones can retrieve it easily. If we don't care about VC compatibility then officially there is no need to manage it. 

[killerbot]

I also favor to be able to run the code with different compilers. But I think we should intend to write as much portable code as possible. The platform dependencies and non portable parts for us should be in the wxwidgets parts.

One place that already comes to mind where to nasty ifdefs will be needed is the declspec shit in order to export/import shared libraries.

That is basically ifdef else ... to define in the end one macro, and then we put that macro in front of the classes/functions we want to export.
That mumbo jumbo ifdef else could be put in a dedicated header in order not to repeat this all the time in every class who wants to export stuff.
I guess this already kind of occurs in sdk.h (should check).

Hmmmmmm, just realized we should already have this since MinGW is also doing this stuff, dunno if gcc uses the same syntax on windows and linux ?

Could maybe someone list other potential changes (so not just giving a patch), a nice list. That way we can nicely investigate/debate on the gain we get or the price we have to pay.

But I assume in 99% of the code we shouldn't do anything, code should be as portable as possible (as said wxwidgets is the one doing the dirty portability work for us).

[Loaden]

EDIT: fix build error
V12: Change to ANSI build (Compatible with xgettext)

nmake -f makefile.vc CPPFLAGS=/Os LDFLAGS="/MANIFEST:NO /OPT:REF /OPT:ICF" BUILD=debug SHARED=1 UNICODE=0 DEBUG_INFO=0 DEBUG_FLAG=1 MONOLITHIC=1 OFFICIAL_BUILD=1
nmake -f makefile.vc CPPFLAGS=/Os LDFLAGS="/MANIFEST:NO /OPT:REF /OPT:ICF" BUILD=release SHARED=1 UNICODE=0 DEBUG_INFO=0 DEBUG_FLAG=0 MONOLITHIC=1 OFFICIAL_BUILD=1

And I catch the crash using Visual Studio Debugger.

>   CodeBlocks.exe!sq_getprintfunc(SQVM * v)  Line 1255 + 0x3 bytes   C++
    CodeBlocks.exe!ScriptConsole::ScriptConsole(wxWindow * parent, int id)  Line 116 + 0xb bytes   C++
    CodeBlocks.exe!MainFrame::CreateIDE()  Line 701 + 0x37 bytes   C++
    CodeBlocks.exe!MainFrame::MainFrame(wxWindow * parent)  Line 553   C++
    CodeBlocks.exe!CodeBlocksApp::InitFrame()  Line 405 + 0x27 bytes   C++
    CodeBlocks.exe!CodeBlocksApp::OnInit()  Line 639 + 0xb bytes   C++
    wxmsw28d.dll!65e81ea7()    
    [Frames below may be incorrect and/or missing, no symbols loaded for wxmsw28d.dll]   
    wxmsw28d.dll!65ec6bcb()    
    MSVCR100D.dll!_getptd_noexit()  Line 500   C
    0018fb54()   

It's seems the crash occured in Squirrel.
Any comment are welcome!