wxwidget 64 bit version

[anandamu16]

Hey,

I want to use wxwidget in codeblocks but I want the 64 bit version of wxwidget, How will I get it?
Do I need to compile wxwidget library explicitly with 64 bit compiler or there is a separate wxwidget library for 64 bit.?

I am looking for wxwidget 3.0.2_64 library build

[ONEEYEMAN]

Hi,
What is you OS/toolkit?

Thank you.

[Manolo]

DLL Windows binaries:
https://github.com/wxWidgets/wxWidgets/ ... tag/v3.0.2

[joemaniaci]

I tried using TDM64-GCC to build wxwidgets and was unsuccessful, the current version of mingw-w64 is currently broken on source forge.

Before I struggle anymore with it though, do I have to compile wxWidgets, and for me openCV as well, in 64-bit to create a 64-bit application? Or can I just use my 32-bit opencv/wxWidget binaries and use g++ -m64 to create a 64-bit executable? I only need(or think I need) a 64-bit executable so that windows 7 will allocate a larger chunk of virtual memory to my program. I'm surpassing 1.5 GB and seeing bad_alloc errors on wxWidgets as well as openCV.

I saw and downloaded the .dll files but using the x86_64-w64-mingw32-g++ from TDM-GCC-64 apparently has a bug that has popped up from time to time.

[ONEEYEMAN]

Hi,
You can download MSVC Express Edition (latest one) and compile the library.

Thank you.

[joemaniaci]

I tried that already to use for openCV since MingGW + (openCV + IPP) is a no go at the moment. I just had even more issues.

[ONEEYEMAN]

Hi,
Are those issues with openCV or wx?

We can help with the latter but for the former you need to talk to openCV people.

Thank you.

[PB]

I tried using TDM64-GCC to build wxwidgets and was unsuccessful, the current version of mingw-w64 is currently broken on source forge.

FWIW, I just tried to build wxWidgets 3.1 library and the minimal sample in 64-bit mode with TDM-GCC-64 and had no issues.
I had:
* TDM-GCC-64 freshly downloaded from its web page (via SourceForge)
* wxWidgets master about two weeks old
* Windows 7 64-bit.

I have built the library in both debug and release configuration for static and dynamic (default multilib) builds with the batch file with simplest possible build commands

Code: Select all

cd %WXWIN%\build\MSW

PATH=%PATH%;C:\TDM-GCC-64\bin

mingw32-make -f makefile.gcc BUILD=debug CXXFLAGS="-std=gnu++11" setup_h
mingw32-make -j2 -f makefile.gcc BUILD=debug CXXFLAGS="-std=gnu++11"

mingw32-make -f makefile.gcc BUILD=release CXXFLAGS="-std=gnu++11" setup_h
mingw32-make -j2 -f makefile.gcc BUILD=release CXXFLAGS="-std=gnu++11"

mingw32-make -f makefile.gcc BUILD=debug SHARED=1 CXXFLAGS="-std=gnu++11" setup_h
mingw32-make -j2 -f makefile.gcc BUILD=debug SHARED=1 CXXFLAGS="-std=gnu++11"

mingw32-make -f makefile.gcc BUILD=release SHARED=1 CXXFLAGS="-std=gnu++11" setup_h
mingw32-make -j2 -f makefile.gcc BUILD=release SHARED=1 CXXFLAGS="-std=gnu++11"

I then used the same commands (obviously without the setup_h target) for building the minimal sample.

I think I can conclude that wxWidgets can be easily and successfully built for 64-bit with TDM-GCC.

Or can I just use my 32-bit opencv/wxWidget binaries and use g++ -m64 to create a 64-bit executable?

I'm quite sure you cannot do that. Just for starters, how would the code compiled as 32-bit (i.e. with 32-bit pointers) accessed memory locations outside the 32-bit memory space?

[joemaniaci]

I'm quite sure you cannot do that. Just for starters, how would the code compiled as 32-bit (i.e. with 32-bit pointers) accessed memory locations outside the 32-bit memory space?

Well you're just working in a virtual memory space anyway. Your code is just requesting memory from the OS, not in a particular place. But alas, it's been so long since my OS and systems courses.

Here is the issue I had when trying to compile it with TDM
https://groups.google.com/forum/#!topic ... SDyJ6jbRP4

[joemaniaci]

Hi,
Are those issues with openCV or wx?

Can't remember now, but perhaps I will try the free VS and try again.

[PB]

I'm quite sure you cannot do that. Just for starters, how would the code compiled as 32-bit (i.e. with 32-bit pointers) accessed memory locations outside the 32-bit memory space?

Well you're just working in a virtual memory space anyway. Your code is just requesting memory from the OS, not in a particular place. But alas, it's been so long since my OS and systems courses.

Sorry, that's just so wrong and even has nothing to with OS and systems, just plain basic math - you can't fit 64-bit address into 32-pointer in flat memory space.

Here is the issue I had when trying to compile it with TDM
https://groups.google.com/forum/#!topic ... SDyJ6jbRP4

You must have linked the wrong thread, that one is about some warnings when compiling on Linux.


Anyway, the point is, wxWidgets do build in 64-bit mode out of the box, whether it is with TDM-GCC or Visual C++, I have done both (using VS Express for Desktop 2015 for VC++). If they do not, post the usual: i.e., exact build toolchain information, wxWidgets version, commands used to build it, and the relevant part of the build log with error(s).

[joemaniaci]

Sorry, that's just so wrong and even has nothing to with OS and systems, just plain basic math - you can't fit 64-bit address into 32-pointer in flat memory space.

Obviously 64-bits is not fitting into 32-bits, I just can't remember if compilation creates different assembly code, or if the assembly for int* x = 0 will be the same for either a 32-/64-bit binary and sizes are determined at runtime.

No I linked the correct thread, those are the exact same issues I had using TDD. Weird errors that didn't exist located at the last closing } in each file.

I'm not saying it's impossible, I'm just saying it wasn't working for me. I'm just using windows 7 64, wxwidgets 3.0.2, and I've been downloading the latest MinGW, MinGW-w64, TDM-GCC-64. If anything I will try MSVS again because I've seen a lot of openCV people have less headaches that way.

[PB]

Obviously 64-bits is not fitting into 32-bits, I just can't remember if compilation creates different assembly code, or if the assembly for int* x = 0 will be the same for either a 32-/64-bit binary and sizes are determined at runtime.

Whether you remember or not, we are talking C++ here so it is very clear there is no size of type determination at runtime, everything happens at compile time. There's no 32<->64 bit "autothunking" in C++.

No I linked the correct thread, those are the exact same issues I had using TDD. Weird errors that didn't exist located at the last closing } in each file.

All the linked thread is about is compiler WARNINGS, I went through all the post there and did not see any ERRORS mentioned.

[joemaniaci]

Well Eclipse CDT failed to compile my code because it was looking for objects/methods etc on the last line that had a closing curly bracket in my source files.

[ONEEYEMAN]

Hi,
So you have issue compiling library or your code in 64-bit?

Thank you.