Building Code::Blocks on Win 64

[Biplab]

A new build has been uploaded to my server. You can download it from-

http://codeblocks.biplab.in/win-64/CB_20120213_r7798_x86-64.7z

Patch (to trunk)-

http://codeblocks.biplab.in/win-64/CB_20120213_r7798_x86-64_r1_patch.7z

Important notes:
1) Contrib plugins are not included.
2) Disable CC plugin if the build is unstable.

From my next build, I'll start to include couple of Contrib plugins.

[MortenMacFly]

http://codeblocks.biplab.in/win-64/CB_20120213_r7798_x86-64_r1_patch.7z

I still have a few differences in my patches. In addition, CC works just fine for me meanwhile on C::B 64 bit. Maybe we should really start to commit to SVN trunk (as we had discussed already) to merge our task forces.. ;-)

[oBFusCATed]

I don't know why you're not doing this committing stuff, already. If it doesn't break 32bit or linux build it is all ok.
Also more eyes will be inspecting your progress

[MortenMacFly]

I don't know why you're not doing this committing stuff, already.

Ok... I can do it, too. You'll see the next couple of days...

[Biplab]

http://codeblocks.biplab.in/win-64/CB_20120213_r7798_x86-64_r1_patch.7z

I still have a few differences in my patches. In addition, CC works just fine for me meanwhile on C::B 64 bit. Maybe we should really start to commit to SVN trunk (as we had discussed already) to merge our task forces.. ;-)

I told you earlier to send your patches so that I can understand the difference.

I don't know why you're not doing this committing stuff, already. If it doesn't break 32bit or linux build it is all ok.
Also more eyes will be inspecting your progress

1) I found CC is unstable.
2) Some portions are missing. E.g., Crash Handler.
3) It uses wx-2.9.x which is not a stable release. Also my build uses wxWidgets' wxPropGrid library; instead of the one included in C::B trunk.

Thus I prefer to commit it after it gets stable and wx is bumped to wx-3.

[oBFusCATed]

All wx2.9 builds use the wx2.9 supplied wxpropgrid, as far as I know (I've tried only to build on linux).

If 64bit changes doesn't affect the 32bit+linux, there is not point in maintaining separate patches:)

[Biplab]

All wx2.9 builds use the wx2.9 supplied wxpropgrid, as far as I know (I've tried only to build on linux).

If 64bit changes doesn't affect the 32bit+linux, there is not point in maintaining separate patches:)

Most of my changes are wrapped in _WIN64 macro. So it should not affect Linux / 32 bit build.

[daniloz]

A new build has been uploaded to my server. You can download it from-

http://codeblocks.biplab.in/win-64/CB_20120213_r7798_x86-64.7z

Thanks for the release... I'm looking forward to see C::B running natively in 64-bit... :-)

However (there's always a however ;-) ), when I start C::B from your release, I got the following error:

Code

---------------------------
wxWidgets Debug Alert
---------------------------
C:\wxWidgets\include/wx/strvararg.h(453): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type
Do you want to stop the program?
You can also choose [Cancel] to suppress further warnings.
---------------------------

My system: Win 7 64-bit

[Jenna]

This should be fixed in actual trunk and will surely make it in Biplab's win64-build.
It also occurs on linux 64-bit with wx2.9 if debug-messages are on.

There are some more format issues, that will be fixed in trunk as far as they are found.

[Biplab]

This should be fixed in actual trunk and will surely make it in Biplab's win64-build.
It also occurs on linux 64-bit with wx2.9 if debug-messages are on.

There are some more format issues, that will be fixed in trunk as far as they are found.

Thanks Jens for the fix.

Thanks for the release... I'm looking forward to see C::B running natively in 64-bit... :-)

However (there's always a however ;-) ), when I start C::B from your release, I got the following error:

Code

---------------------------
wxWidgets Debug Alert
---------------------------
C:\wxWidgets\include/wx/strvararg.h(453): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type
Do you want to stop the program?
You can also choose [Cancel] to suppress further warnings.
---------------------------

My system: Win 7 64-bit

Debug messages are On (by default) in wx-2.9 series. Thus you encountered that message. I can suppress that by rebuilding wx-2.9; but I think it's a good idea to keep them on so that we can fix them.

[stahta01]

Biplab: Your patch on a the file incrementalselectlistdlg.cpp.

Code

Index: src/sdk/incrementalselectlistdlg.cpp
===================================================================
--- src/sdk/incrementalselectlistdlg.cpp	(revision 7798)
+++ src/sdk/incrementalselectlistdlg.cpp	(working copy)
@@ -119,7 +119,11 @@
     if (selection == wxNOT_FOUND)
         return wxNOT_FOUND;
 
+    #if defined(_WIN64)
+    return reinterpret_cast<long long>(m_List->GetClientData(selection));
+    #else
     return reinterpret_cast<long>(m_List->GetClientData(selection));
+    #endif
 }
 
 void IncrementalSelectListDlg::FillList()

The patch I tried on Windows 32; I am NOT a well experienced C++ Programmer, so it might not be valid.

Code

Index: src/sdk/incrementalselectlistdlg.cpp
===================================================================
--- src/sdk/incrementalselectlistdlg.cpp	(revision 7823)
+++ src/sdk/incrementalselectlistdlg.cpp	(working copy)
@@ -119,7 +119,7 @@
     if (selection == wxNOT_FOUND)
         return wxNOT_FOUND;
 
-    return reinterpret_cast<long>(m_List->GetClientData(selection));
+    return reinterpret_cast<cbIntPtr>(m_List->GetClientData(selection));
 }
 
 void IncrementalSelectListDlg::FillList()

I have attached a small sub-set of Biplab's patch were cbIntPtr is used.
Note: I changed wxIntPtr to cbIntPtr; and maybe some more small changes.

Tim S.

[Biplab]

Tim,

I fully agree with you.

The patch I tried on Windows 32; I am NOT a well experienced C++ Programmer, so it might not be valid.

Code

Index: src/sdk/incrementalselectlistdlg.cpp
===================================================================
--- src/sdk/incrementalselectlistdlg.cpp	(revision 7823)
+++ src/sdk/incrementalselectlistdlg.cpp	(working copy)
@@ -119,7 +119,7 @@
     if (selection == wxNOT_FOUND)
         return wxNOT_FOUND;
 
-    return reinterpret_cast<long>(m_List->GetClientData(selection));
+    return reinterpret_cast<cbIntPtr>(m_List->GetClientData(selection));
 }
 
 void IncrementalSelectListDlg::FillList()

I have attached a small sub-set of Biplab's patch were cbIntPtr is used.
Note: I changed wxIntPtr to cbIntPtr; and maybe some more small changes.

Tim S.

I'll add your patch to my next build. Thanks for pointing this.

Regards,

Biplab

[MortenMacFly]

I'll add your patch to my next build. Thanks for pointing this.

That's how I did it, too btw...

[MortenMacFly]

I'll add your patch to my next build. Thanks for pointing this.

That's how I did it, too btw...

Nope, full-stop that's not fully how I did it. Since wx2.9.1 you can/should use this signature for he callback in newfromtemplatedlg.cpp safely:
int wxCALLBACK SortTemplates(wxIntPtr item1, wxIntPtr item2, wxIntPtr /*sortData*/)
...since wxIntPtr is what's expected and what's working. There is no need to use an own version.

Oh dear... probably I should really start to clean things out and commit...

BTW: I believe cbIntPtr was only relevant for wx2.9.0. Staring with wx2.9.1 and above we should use wxIntPtr IMHO.

[Biplab]

I'll add your patch to my next build. Thanks for pointing this.

That's how I did it, too btw...

Nope, full-stop that's not fully how I did it. Since wx2.9.1 you can/should use this signature for he callback in newfromtemplatedlg.cpp safely:
int wxCALLBACK SortTemplates(wxIntPtr item1, wxIntPtr item2, wxIntPtr /*sortData*/)
...since wxIntPtr is what's expected and what's working. There is no need to use an own version.

Oh dear... probably I should really start to clean things out and commit...

BTW: I believe cbIntPtr was only relevant for wx2.9.0. Staring with wx2.9.1 and above we should use wxIntPtr IMHO.

When I started working on it, cbIntPtr was necessary. And if you want to maintain compatibility with wx-2.8.x, you should keep cbIntPtr in the code. It'll be translated to wxIntPtr wherever applicable.

wx-2.9.x is development version and that api may change again.