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) ===|
What is your wx version? 2.9 probably?It's 2.8.12, And I can sure scrollingdialog.cpp been compiled.
If it is 2.8 check if you compile the scrollingdialog.cpp correctly.
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.
@loadenOK, I try search now.
someone has used a msvc compiler to build the codeblocks, he just released it on sourceforge. Sorry I can't find the link now.
I try to change CodeBlocks.lib(dynamic lib) to static lib and add /ignore:4006 /ignore:4221 to linker option.We can't build the SDK to static lib, because there have many plugins need the SDK.
The LNK1189 error comes out : The limit of 65535 objects or members in a library has been exceeded.
I try to change CodeBlocks.lib(dynamic lib) to static lib and add /ignore:4006 /ignore:4221 to linker option.We can't build the SDK to static lib, because there have many plugins need the SDK.
The LNK1189 error comes out : The limit of 65535 objects or members in a library has been exceeded.
Now I find a reason, that we need make it import.
like:
class DLLIMPORT wxDialogHelper
{
It's here:@loadenOK, I try search now.
someone has used a msvc compiler to build the codeblocks, he just released it on sourceforge. Sorry I can't find the link now.
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)|
It's here:Thanks!!
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.I don't think so, Only need a little guard code (like #ifdef _MSC_VER), and seems very clearly.
@loadenBecause MinGW GCC export all symbols defaultly.
it seems you add a lot of DLLIMPORT before the class declaration. But why they are not needed when build with MinGW GCC?
@loadenSure, I am re-make the patch now.
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)
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 :)
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.
Most of them are Multi-line String fixed.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. No
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
Hey, loaden, unpack the 23K 7zip file, the patch is still 131K, Oh my God. :DThe most important is that it's without any side effects when compile CB based on GCC compiler.
But, I review the patch, it does change only a little code. :D
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.
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).
Change from:BTW: This will break translations IMHO, as the second part (now _T("")) will not appear in the translation tables. You should always use _("").
_("aaa"
"bbb")
TO:
_("aaa"
_T("bbb"))
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 :D, 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).
I have used both, and off course CB is better ;-)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 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.
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. :(
Bad news, And I can't fix this issue. :(Well, you'll need to do something like:
_("text....\n"
"more text...")
_("text....\nmore text...")
wxString str = _("text....\n")
+ _("more text...");
Ceniza:
You need Visual Assists in VS 2010, so they failed to make the CC work again?
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.
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
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. :)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.
_("text....\n"
"more text...")
dump the whole patched source somewhere in the web. :)then??? It will make it way harder to handle.
I know this, but it can't support multi-line, or lead broke the whole string.Bad news, And I can't fix this issue. :(Well, you'll need to do something like:
Old:CodeNew:_("text....\n"
"more text...")Code...or:_("text....\nmore text...")
CodewxString str = _("text....\n")
+ _("more text...");
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 todump the whole patched source somewhere in the web. :)then??? It will make it way harder to handle.
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=1And I catch the crash using Visual Studio Debugger.
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
> CodeBlocks.exe!sq_getprintfunc(SQVM * v) Line 1255 + 0x3 bytes C++It's seems the crash occured in Squirrel.
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()