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