Building 64 bit

[rsandoz]

Is there any documention on building 64 bit?

After following readme.windows for MinGW/CodeBlocks, I built and run xLights.cbp and xSchedule.cbp (32-bit) MinGW_Debug and MinGW_Release successfully (had to ignore wxvc and wx64).

So, to build 64 bit, I am guessing I need to build "64bit MinGW_Debug" and "64bit  MinGW_Release"
but first to build those, do I need to build $(#wx64)?  I see this referenced only in "64bit MinGW_Debug".
Do I need to make a separate directory for wxWidgets for 64-bit? (E:\wxWidgets64-3.1.0\) in addition to (E:\wxWidgets-3.1.0\)

And then compile.  Can I compile by just adding TARGET_CPU=X64 to the command line specified for wxWidgets in readme.windows for "Instructions for MinGW"

Change:
mingw32-make -f makefile.gcc --debug MONOLITHIC=1 SHARED=1 UNICODE=1 CXXFLAGS="-std=gnu++14" BUILD=debug -j 10

to:
mingw32-make -f makefile.gcc --debug TARGET_CPU=X64 MONOLITHIC=1 SHARED=1 UNICODE=1 CXXFLAGS="-std=gnu++14" BUILD=debug -j 10

I built wxWidget like this successfully

But then I tried building the Mingw 64 bit versions on xlights.  Both debug and release are greyed out in the IDE.  I tried changing the Toolchain executables (gcc.exe => i686-w64-mingw32-c++.exe, etc), but still no go.

When I try to do "Build" from the menu (BUild->Build), I get:
"xLights 4.0 - 64bit MinGW_Debug": The compiler's setup is invalid, so Code::Blocks cannot find/run the compiler.
Probably the toolchain path within the compiler options is not setup correctly?! (Do you have a compiler installed?)
Goto "Settings->Compiler...->Global compiler settings->unknown->Toolchain executables" and fix the compiler's setup.
Skipping...
Nothing to be done (all items are up-to-date).

I tried copying the default configuration and named it "gnu_gcc_64bit_compiler", then set the toolchain executables there (i686-w64-mingw32-c++.exe, i686-w64-mingw32-g++.exe ...)

-------------- Build: 64bit MinGW_Debug in xLights 4.0 (compiler: gnu_gcc_64bit_compiler)---------------

i686-w64-mingw32-g++.exe -fno-strict-aliasing -Wno-unused-local-typedefs -DwxUSE_UNICODE -pedantic -m64 -g -pipe -mthreads -std=gnu++14 -fno-keep-inline-dllexport -Wno-attributes -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -D__WXDEBUG__ -D_USE_MATH_DEFINES -m64 -I(invalid)\lib\gcc_dll\mswud -Iinclude -Isequencer -I..\xLights -Ieffects -Ieffects\ -Imodels -Ieffects\assist -Imodels\ -Iffmpeg-dev\include -I..\include -Isupport -IE:\wxWidgets-3.1.0\include -IE:\wxWidgets-3.1.0\contrib\include -c E:\xLights-master\xLights\AudioManager.cpp -o .objs_64d\AudioManager.o
E:\xLights-master\xLights\AudioManager.cpp:1:0: sorry, unimplemented: 64-bit mode not compiled in
 #include "AudioManager.h"
 ^
Assembler messages:
Fatal error: no compiled in support for x86_64
Process terminated with status 1 (0 minute(s), 0 second(s))
2 error(s), 0 warning(s) (0 minute(s), 0 second(s))

[Gilrock]

I used a fresh copy of wxWidgets to build the 64bit version because it was just easier.  The compiler configuration you create for 64bit needs to match the name we used in the debug and release configs.  You should have seen the name it was looking for when you tried to compile or just check the settings to see which compiler config the release is set for.  I'm not at home so can't help much more than that.

[rsandoz]

I actually got my fresh copy of wxWidgets to build successfully putting it in a separate directory e:\wcWidgets64\ and adding the TARGET_CPU=X64 option.

I looked at the xLights.cbp project in notepad++ and used the naming in there:
gnu_gcc_64bit_compiler

I went into codeblocks under settings // compiler and with selected compiler set to "GNU GCC Compiler", pressed the Copy button and copied to the name "gnu_gcc_64bit_compiler".  This ungreyed the options "64bit MinGW_Debug" and "64bit  MinGW_Release".  I tried compiling these and got this error:


-------------- Build: 64bit MinGW_Debug in xLights 4.0 (compiler: gnu_gcc_64bit_compiler)---------------

g++.exe -fno-strict-aliasing -Wno-unused-local-typedefs -DwxUSE_UNICODE -pedantic -m64 -g -pipe -mthreads -std=gnu++14 -fno-keep-inline-dllexport -Wno-attributes -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -D__WXDEBUG__ -D_USE_MATH_DEFINES -m64 -I(invalid)\lib\gcc_dll\mswud -Iinclude -Isequencer -I..\xLights -Ieffects -Ieffects\ -Imodels -Ieffects\assist -Imodels\ -Iffmpeg-dev\include -I..\include -Isupport -IE:\wxWidgets-3.1.0\include -IE:\wxWidgets-3.1.0\contrib\include -c E:\xLights-master\xLights\AudioManager.cpp -o .objs_64d\AudioManager.o
E:\xLights-master\xLights\AudioManager.cpp:1:0: sorry, unimplemented: 64-bit mode not compiled in
 #include "AudioManager.h"
 ^
Assembler messages:
Fatal error: no compiled in support for x86_64
Process terminated with status 1 (0 minute(s), 0 second(s))
2 error(s), 0 warning(s) (0 minute(s), 0 second(s))
 
I tried changing the toolchain executables:
c compiler: c++.exe => i686-w64-mingw32-c++.exe
c++ compiler: g++.exe => i686-w64-mingw32-g++.exe
linker for dynmaic libs:  g++.exe => i686-w64-mingw32-g++.exe
linker for static libs:  ar.exe => i686-w64-mingw32-gcc-ar.exe

checked -m64 option on the compiler flags tab

and still the same error

[Gilrock]

Well darn you.  I did a clean on AudioManager.o and then did a build file and now I got the same error.

[Gilrock]

So have you tried building everything?  I just did clean and hit build for a full build and it works.  Not sure why I get the error when I try to compile just that one file.

[rsandoz]

Tried clean and no go.  Tried multiple combinations of options offered under the Build menu (Rebuild, Clean Workspace, Rebuild Workspace) for both 64bit mingw release and debug.

All lead to this error.

Tried the next file in the directory, BatchRenderDialog.cpp.  Same error:

-------------- Build file: 64bit  MinGW_Release in xLights 4.0 (compiler: gnu_gcc_64bit_compiler)---------------

i686-w64-mingw32-g++.exe -fno-strict-aliasing -Wno-unused-local-typedefs -DwxUSE_UNICODE -O2 -pedantic -m64 -pipe -mthreads -std=gnu++14 -fno-keep-inline-dllexport -Wno-attributes -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DNDEBUG -D_USE_MATH_DEFINES -m64 -IE:\wxWidgets-3.1.0\lib\gcc_dll\mswu -Iinclude -Isequencer -I..\xLights -Ieffects -Ieffects\ -Imodels -Ieffects\assist -Iffmpeg-dev\include -I..\include -Imodels\ -Isupport -IE:\wxWidgets-3.1.0\include -IE:\wxWidgets-3.1.0\contrib\include -c E:\xLights-master\xLights\BatchRenderDialog.cpp -o .objs_64\BatchRenderDialog.o
E:\xLights-master\xLights\BatchRenderDialog.cpp:1:0: sorry, unimplemented: 64-bit mode not compiled in
 #include "BatchRenderDialog.h"
 ^
Assembler messages:
Fatal error: no compiled in support for x86_64
Process terminated with status 1 (0 minute(s), 0 second(s))
2 error(s), 0 warning(s) (0 minute(s), 0 second(s))

[rsandoz]

I even tried cleaning/building with global environment variables set such that both wx and wx64 pointed to my "E:\wxWidgets64-3.1.0" directory
(noticed in xLights.cbp that "64bit  MinGW_Release" points to wx)

[Gilrock]

So all the settings you need are mainly in the .cbp file except the ones that are set under the Settings menu in Codeblocks.  I took some screenshots of mine for you to compare.  Of course you may have different directories where you've installed wxWidgets.  I only copied the pages that I thought were different than the defaults.  The compiler options had no boxes checked because we try to keep those settings in the project.

[keithsw1111]

This is why I had the libraries for wxwidgets release put in the repo. It’s so much easier to get the visual studio 64 bit build going but we could never work out why that ran so slowly on Gil’s machine.

[Gilrock]

Actually last time I used Visual Studio it seems to have gotten faster.  I haven't debugged in awhile but last time I had to debug it seemed to be completely broken for me in CodeBlocks so I had to start using Visual Studio whenever I need to debug.  Codeblocks started either not breaking on breakpoints or it would only hit a breakpoint once and then would never break again.  Not sure what changed but its a pain now.

[rsandoz]

Thank you.  Thank you.  Thank you.  I was using the wrong compiler.  I was thinking that by running the setup file "mingw-w64-install.exe" that this was install a compiler that handled both 32bit and 64bit just by passing the parm -m32 or -m64.  I just downloaded another instance of mingw equal to the one specified in your path:
E:\mingw-w64\x86_64-5.3.0-posix-seh-rt_v4-rev0\mingw64

and am starting over (at least with the 64 bit parts)

[rsandoz]

Also, is this correct?
When I open xLights.cbp in a text editor to see the XML layout of the project.

The configuration"64bit  MinGW_Release" (two spaces between 64bit and MinGW btw) has references to $(#wx) instead of $(#wx64) whereas "64bit MinGW_Debug" is referencing $(#wx64) as expected.

[rsandoz]

I also created a pull request to add 64 bit instructions to readme.windows.

I copied the text block "Instructions for MinGW" to "Instructions for MinGW 64-bit", updating paths and such with the necessary info I learned from this posting.

[Gilrock]

Yes the targets that start with 64bit in the name are correct.  That #wx probably is the wrong one but since it's just a search path it shouldn't matter because it's just finding header files which are the same in both versions.

[rsandoz]

AFter doing the 64-bit mingw install then after re-starting xLights.cpb, I was getting a popup:
cc1plus.exe - Application Error "The application was unable to start correctly (0xc000007b).  Click OK to close the application."

This seemed related to the g++.exe in the Toolchain executables (clear the field and popup went away)

I looked over my user and system environment variable, paying attention to "path".  Mingw was not part of it.

I can assume after I installed mingw, it didn't update my system or user path (should it have?).

That being said, I updated codeblocks.
1) settings > environment
2) scroll the left icon pane down to Environment variables and select it
3) Click the Add button. 
4) Fill in Key: path
5) Fill in Value: %path%;C:\Program Files\mingw-w64\x86_64-5.3.0-posix-seh-rt_v4-rev0\mingw64\bin