Building Opencpn using mingw (gcc) on Windows

[seandepagnier]

First of all, why do this?

1. developers without access to windows can now build, test and distribute binaries for windows.
2. In various places the source code is poor c++ and compiling with gcc finds these cases (in the windows specific code) which improves code quality and portability.
3. gcc is free software. You may fix problems you find in it. Visual Studio is not free, and has many bugs which have wasted the time of people testing my plugins, and therefore also my time.
4. As a gcc contributor, I am a bit biased, however gcc is capable of generating more efficient code, reporting more understandable warning and error messages, and has a superior debugger (gdb)
5. OpenCPN is free software, as are all of the dependencies, therefore it only makes sense that we would like to also use a free compiler if at all possible.

If you are using linux, you may skip ahead to the cross compiling section below as it is much simpler and quicker.

To start off, getting this working was a fairly painful process. A single change in any build file requires several hours to see the results (because invocations are very slow via wine and the build system uses a lot of these) so it took me a few days to achieve this. However, once opencpn.exe is running in wine, the performance is the same as if it were running natively in linux.

First install wine so we can run windows binaries (only if you are not using windows)

$ sudo apt-get install wine

Next, download msys/mingw installer from mingw.org and install gcc and g++ as well as gettext.

Run msys (wine cmd; cd c:/mingw/msys/1.0; msys) and you should have a window with a shell.

fix /usr thing, (hack in include directories for now)
$ ln -s / /usr

Now download and extract wxwidgets (I used version 2.8.12)

edit src/msw/treectrl.cpp to have following change:

+++ treectrl.cpp 2014-02-28 11:27:59.367810324 +0800
@@ -43,6 +43,10 @@
#include "wx/msw/dragimag.h"
?#include "wx/msw/uxtheme.h"

+#ifdef __MINGW32__
+#define TV_DISPINFO NMTVDISPINFO
+#endif
+
// macros to hide the cast ugliness
// --------------------------------


Now, from the msys shell build wxwidgets:
$ cd wxWidgets*
$ mkdir build-mingw32
$ cd build-mingw32
$ ../configure --with-opengl --enable-unicode
$ make
$ make install

Note: If make fails with make errors (not compilation error) run make again and it may succeed.
Note: you may also attempt with --enable-graphics_ctx but I have not had the chance yet

Next, must compile cmake from source, and install it.
(the cmake binary compiled with VS may work under microsoft's windows, but crashes under wine)
I don't have detailed instructions but it is straightforward.

To avoid many issues specific to compiling OpenCPN using mingw, you must use the branch from my fork of opencpn for various changes required to compile using mingw

From a shell (with git installed), or with a git program:
$ git clone -b mingw https://github.com/seandepagnier/OpenCPN.git

From msys shell:

$ cd OpenCPN
$ mkdir build-mingw32
$ cd build-mingw32
$ cmake -G "MSYS Makefiles" ..
$ make
$ make install

note: it may be possible to use mingw32-make instead of make in msys, but I have not tried.

Now opencpn.exe is installed in program files, but cannot run until you copy the wxwidgets dll files into the same directory (we can later make this automatic as it is already for visual studio)

I have successfully built dashboard_pi as proof that plugins are working, but renders some of the instruments poorly. I believe wxwidgets must be configured --with-graphics_ctx to fix this. I didn't try yet because of possible license issues with gdiplus.h which is not included with mingw. Please advise.

The grib plugin does not build because there is no zlib.. maybe someone can help me out here. On windows, does it need to use the zlib in wxwidgets? Does this mean when building wxwidgets I must configure --with-zlib to solve this?

An important caveat: If you change the cmake files, you must rm -rf the build directory, as not doing this causes cmake to generate a different makefile which then fails to link. I think this is probably a bug in cmake.

You can reduce the file sizes of the exe as well as the dll files dramatically by using the strip command. The result is the files are the same size as the visual studio versions.

Unfortunately the visual studio dll files are also needed for the ocpn_gltest1.exe program which I cannot find the source (to rebuild with mingw instead) or else opengl is disabled.


------------------------------------------------
Cross compiling OpenCPN for windows under linux.
------------------------------------------------

This is much more convenient and the build is much faster. The resulting binary can be tested in wine.

Install mingw cross compiler, and wine for testing:
$ apt-get install mingw32 wine

cross compile wxwidgets:

$ ../configure --prefix=/usr/local/i586-mingw32 --host=i586-mingw32msvc --with-opengl --enable-unicode
$ make
$ sudo make install

note: you may attempt --with-graphics_ctx as well

In /usr/share/cmake-2.8/Modules/FindwxWidgets.cmake

There is a bug in the cmake module FindwxWidgets.cmake that prevents any library using wxWidgets to cross compile for Windows from Linux. Please note that this bug is different from issue 0006187. Lines 192 to 198 are concerned by the present bug:

IF(WIN32 AND NOT CYGWIN AND NOT MSYS)
SET(wxWidgets_FIND_STYLE "win32")
ELSE(WIN32 AND NOT CYGWIN AND NOT MSYS)
IF(UNIX OR MSYS)
SET(wxWidgets_FIND_STYLE "unix")
ENDIF(UNIX OR MSYS)
ENDIF(WIN32 AND NOT CYGWIN AND NOT MSYS)

The problem is that, when cross compiling from Linux for Windows, the
test "WIN32 AND NOT CYGWIN AND NOT MSYS" is true but find style should
be "unix", because the Windows-based wxWidget library is installed in a
unix environment.

Therefore, the following line replacement corrects this bug:

IF(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING)
SET(wxWidgets_FIND_STYLE "win32")
ELSE(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING)
IF(UNIX OR MSYS OR CMAKE_CROSSCOMPILING)
SET(wxWidgets_FIND_STYLE "unix")
ENDIF(UNIX OR MSYS OR CMAKE_CROSSCOMPILING)
ENDIF(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING)


After making this change, cross compile opencpn for windows.

$ git clone -b mingw https://github.com/seandepagnier/OpenCPN.git
$ cd OpenCPN

$ mkdir build-mingw32-cross
$ cd build-mingw32-cross
$ cmake -DCMAKE_TOOLCHAIN_FILE=../Toolchain-mingw32.cmake ..
$ make

Currently make install, and make package are dysfunctionalgl

[seandepagnier]

I uploaded the installer I built:
opencpnplugins - Browse /opencpn_mingw_experimental at SourceForge.net

It is a few MB smaller than the vc compiled installer, so (grib plugin should be a lot less than this difference) so I'm wondering if it works or if I missed something. Please try.

[rgleason]

I hope some users will test Seans mingw system now, because I have run out of time and can't do it for awhile (40th wedding anniv). I am being separated from my computer for a trip. This system will enable compiling all plugins separately and efficiently, plus it gets us away from MSVC++ vicissitudes and anomalies, so please give it a try, for all of us Windows users.

I will test it out later. I won't need to run it under Wine because I have Win7 and I already have wxwidgets installed, so you'll just need to install mingw and sean's mingw version for opencpn. I do not know if you path name must be wxwidgets (mine is PATH .... C:\wxWidgets-2.8.12\lib\vc_dll;...)

Please post your results here. Thanks.

[rgleason]

Any news? Discussion?
I wish Sean's plugins would compile under both msvc+ and mingw for awhile but that may not be possible. Last time I tried to compile them using msvc+ they did not work, but I believe Sean has them compiling under mingw. To use plugins compiled under mingw you need to use the opencpn version compiled under mingw too.

Can Sean or others comment or help with dev strategy here. We are trying to find a more reliable win compiler that is not so picky that works more like the Linux compiler does. We have a divergence here until this is figured out. I believe Sean really likes the ability to compile win version under mingw and wine which he has also set up to compile plugins separately. Before I left I was running into some difficulty setting that system up for msvc÷ and the plugins would nor compile under msvc+.

Hope that explains the situation. I am still on andriod cell..

Sent from my SCH-I545 using Cruisers Sailing Forum mobile app

[seandepagnier]

The files posted on sourceforge are installers for binaries I compiled myself. To try the mingw version, all you need to do is run the installer for the main program, and optionally for the plugins I built there.

Since there is no official mingw wxwidgets release, you must compile from source. Details for how to do everything are on the first post.

[rgleason]

NOTE: Sean has made newer descriptions under the Developer Manuals "Compiling Windows"

Compiling Windows MinGW | Official OpenCPN Homepage

Cross compiling for windows under linux | Official OpenCPN Homepage

Compiling using Mingw and Gcc improves the code for compiling with MSVCC++ plus it is opensource like Opencpn. It requires less manual copying of files, once setup and has better errror messages.

[rgleason]

I have this Git: Git Release Notes (Git-1.7.11-preview20120710). Git runs fine, what would be the advantage/requirement of installing MsysGit https://github.com/msysgit/msysgit/wiki ? And what would I do with my current projects when I uninstall current git? --Or do I simply install over the top? I am confused about this.

[rgleason]

In my .githubattributes file I found this:

# Standard to msysgit
*.doc diff=astextplain
*.DOC diff=astextplain
*.docx diff=astextplain
...and etc

So I probably allready have it installed. I do have GIT Bash and GIT Gui but hardly ever use it.

[rgleason]

Did this
Compile wxWidgets from Msys shell
Start up the msys shell (run msys.bat located by default in C:\mingw\msys\1.0\msys.bat
cd /c/${WXDIR} mkdir build-mingw cd build-mingw ../configure --with-opengl --enable-unicode

The end of the string of lines says...
"configure: error: no acceptable C compiler found in $PATH
See "config.log" for more details."

=====
So in C:\wxWidgets-2.8.12\build-mingw the config file shows
in part...

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown

PATH: .
PATH: /usr/local/bin
PATH: /mingw/bin
PATH: /bin
PATH: /c/Windows/system32
PATH: /c/Windows
PATH: /c/Windows/System32/Wbem
PATH: /c/Windows/System32/WindowsPowerShell/v1.0/
PATH: /c/Program Files (x86)/Git/cmd
PATH: /c/Program Files (x86)/CMake 2.8/bin
PATH: /c/Program Files (x86)/Codebox/BitMeterOS
PATH: /c/Program Files/Intel/WiFi/bin/
PATH: /c/Program Files/Common Files/Intel/WirelessCommon/
PATH: /c/Program Files (x86)/NSIS/Unicode
PATH: /c/Program Files (x86)/Poedit/bin
PATH: /c/Program Files (x86)/Git/bin
PATH: /c/wxWidgets-2.8.12/lib/vc_dll
PATH: /c/Program Files/Intel/WiFi/bin/
PATH: /c/Program Files/Common Files/Intel/WirelessCommon/

So what c compiler and should I add to the Environment Path?

[rgleason]

OK OPENCPN-mingw - I have been able to compile and run it. Works great. I need some help figuring out why NSIS CPACK does not work due to some missing compression.. lzma.

Grib_pi also requires lz and I installed one file as directed and grib_pi seems to work fine, but not NSIS

Can anyone help with suggestions. See below.

Starting from
of Sean's latest description in the Mingw Compile documentation
Compiling Windows MinGW | Official OpenCPN Homepage
My comments and experience are in red.
---
Compile wxWidgets from Msys shell
Had to add "c:/mingw/bin;" to the Environment PATH
Did not have to reboot Win7 computer.

The phrasing for commands is a little different than shown.
In directory C:\MinGW\msys\1.0 starting Msys.bat
Example: $ cd c:/mingw takes me to /c/mingw So,

$ cd ${WXWIN} takes me to /c/wxwidgets-2.8.12 Found WXWIN in Environment.
$ mkdir build-mingw
$ cd build-mingw
$ ../configure --with-opengl --enable-unicode
-This should run for a long time. If it ends with "Compiler not found" you must set the PATH above.

It ends with:
"Configured wxwidgets 2.8.12 for 'i686-pc-mingw32"
Which GUI toolkit should wxwidgets use? msw
Compile into single library? no
Compiled in debug mode? no
Linked as a shared library? yes
Compiled in Unicode mode? yes
What level of wxwidgets enabled 2.4 no 2.6 yes
Which librarys should wxwidgets use?

jpeg builtin
png builtin
regex builtin
tiff builtin
zlib builtin
odbc no
expat builtin
libmspack no
sdl no

--
make install
- This will take some time. A really long time. Fantastically long time.
Near end "if test ! -d /usr/local/include/wx-2.8/ 'dirname $f ; \
fi; \
/bin/install -c m 644 ../include/$f /usr/local/include/wx-2.8/$f; \
Other lines show "No such file or directory"
Finally ends with "The installation of wxWidgets is finished..."
---
Compile Debug Pass
--enable-debug
to configure to enable debugging support and to compile without optimizations.
---
Building zlib - zlib is needed to build the grib plugin:
Download zlib-1.2.8.tar.gz from
zlib Home Site
tar xavf zlib-1.2.8.tar.gz
(Downloaded to my C:\Users\Rick\Downloads and extracted zlib-1.2.8 to the Downloads directory..)
cd c:/Users/Rick/Downloads/zlib-1.2.8 instead of " cd zlib-1.2.8"
make -f win32/Makefile.gcc
-about 20 lines appear ending with "strip minigzip_d.exe"
cp libz.a /usr/local/lib
I am having trouble with where exactly this is supposed to be located!
there is no "usr/local/lib" and I do not know where ""zlib-1.2.8" directory is supposed to be located?

Copied libz.a from C:\Users\Rick\Downloads\zlib-1.2.8 to C:\MinGW\lib\gcc\mingw32\4.8.1
I have only done this the downloaded files are still here c:/Users/Rick/Downloads/zlib-1.2.8

---
Getting opencpn source
git clone git://github.com/seandepagnier/OpenCPN.git -b mingw
- already did this will just do
git pull

---
The wxWidgets mingw libraries are not in the git repository. Copy wxWidgets libraries into OpenCPN/wxWidgets-mingw:
mkdir wxWidgets-mingw
cp -r /c/wxWidgets-2.8.12/build-mingw/lib/*dll wxWidgets-mingw

If you are going to be distributing a package, please remove the wxWidgets libraries that we do not use.
Done -left the Msvc wxwidgets there because Sean had asked me to compile with msvc to see about errors.
Note that the correct directory is C:\Data-Dart\Up-Soft\Navigation\opencpn-mingw\wxWidgets-mingw

---
Building the OpenCPN source
Create a directory named build under the topmost source directory
Configuring alternative 1: From the command line (recommended):

Here I deleted the "build" directory and all its contents because it was created by the
MSVC++ compiler. Them I mkdir "build" again.

cd into the build directory, used

$ cd /c/Data-Dart/Up-Soft/Navigation/opencpn-mingw
$ cd build

issue By default OpenCPN is installed into C:\Program Files\OpenCPN Unfortunately the make program is not allowed to copy files there. To build and install to an alternate location:

cmake -G "MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=. ..

it detects and checks compiler, finds opengl, wxwidgets, usr/local/lib, stages, build type release, tinyxml lib not found, stage to build plugins, --writing spec file, congfiguring done, generating done, build files have been written to c:/Data-Dart/Up-Soft/Navigation/opencpn-mingw/build

make

now listing lots of building lots of stuff, lots of lines.
goes to 100% and complains about grib_pi because zlib is missing, cannot find -lz.

make install
Builds stuff and tries to link shared library libgrib_pi.dll misses -lz
2 errors.

./opencpn


OPENCPN 3.3.1911 opens and WORKS GREAT!


----
If building a package and will use the installer program to copy to Program Files:

cmake -G "MSYS Makefiles" ..
Stages, Configures and Generates

make
Builds targets

make package
Builds targets for the package
Does Cpack
CPack Error: Problem compressing the Directory
CPack Error: when generating package: Opencpn
Make: *** [Package] Error 1
Please check C:\Data-Dart\Up-Soft\Navigation\opencpn-mingw\build\_CPack_Packages\win32\NSIS
NSISoutput.log

Changing directory to: "C:\Data-Dart\Up-Soft\Navigation\opencpn-mingw\build\_CPack_Packages\win32\NSIS"
Processing script file: "C:/Data-Dart/Up-Soft/Navigation/opencpn-mingw/build/_CPack_Packages/win32/NSIS/project.nsi"
SetCompressor: /FINAL lzma
Invalid command: Unicode
Error in script "C:/Data-Dart/Up-Soft/Navigation/opencpn-mingw/build/_CPack_Packages/win32/NSIS/project.nsi" on line 36 -- aborting creation process

Project.nsi

;# Set compression
SetCompressor /FINAL lzma
;# Set unicode
Unicode true

WHY Doesn't this code have LZMA? How do I get it and where do I install it?
I am STUCK here.

./opencpn_*

[seandepagnier]

are you using nsis 3.00b?

[rgleason]

Sean, Thanks
No NSIS 2.46.3
Should I upgrade to 3.00b? --Later where do I find it.
The website only goes up to 2.46.5 May 10, 2014
http://www.scratchpaper.com/
Do you know if MSVCC++ will still compile CPACK?

[rgleason]

This should work in NSIS 2.46.3 because that supports LZMA.

ERROR MESSAGES:
SetCompressor: /FINAL lzma ----> Invalid command: Unicode
Error in script "C:/Data-Dart/Up-Soft/Navigation/opencpn-mingw/build/_CPack_Packages/win32/NSIS/project.nsi" on line 36 -- aborting creation process

Project.nsi;
# Set compression SetCompressor /FINAL lzma
;# Set unicode Unicode true

====
I think I did not do something right in installing zlib for grib? -or is that different? Just downloaded zlib-1.2.8.tar.gz to download directory, unpacked it there, ran "make -f win32/Makefile.gcc" and copied libz.a from C:\..\Downloads\zlib-1.2.8 to C:\MinGW\lib\gcc\mingw32\4.8.1
leaving c:/../Downloads/zlib-1.2.8 here. (I did not have a
"/usr/local/lib". Where is that located normally and what is it for? -Looks like Linux.)
====

Under C:\Program Files (x86)\NSIS\Unicode\Stubs
I have files bzip2, bzip2_solid, lzma, lzma_solid, zlib, zlib_solid. So I guess zlib is a different compression. Wonder why it is "invalid".
I believe I followed Opencpn.org instructions for installation and compiled with MSVC++.
===

So maybe I have to Uninstall 2.46.3 and then Install 3.0b?
--only choice.

[rgleason]

Ok,
1. Installed NSIS 3.0b (exe version) alongside NSIS 2.46.3 in a new directory labeled NSIS.3.0.b
2. at C:\MinGW\msys\1.0 clicked on msys.bat
3. cd /c/data-dart/../opencpn-mingw/build
4. cmake -G "MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=. ..
5. make
6. make install
7. ./opencpn (and it runs)
8. Compile Installer
9. cmake -G "MSYS Makefiles" ..
10. make
11. make package
12. output now says:

Run Cpack packaging tool....
CPack: Create package using NSIS
CPack: Install Projects
CPack: - Run preinstall target for: opencpn
CPack: -Installl project: opencpn
CPack: Create package
CPack Error: Problem running NSIS command: "c:/Program Files(x86)/NSIS /Unicode/makeensis.exe" "C:/data-dar/...opencpn-mingw/build/_CPack_Packages/win32/NSIS/project.nsi"
Please check C:/..opencpn-mingw/..NSIS/NSISoutput.log for errors.
CPack Error: Problem Compressing the directory.
CPack Error: Error when generating package: Opencpn
make: *** [Package] error 1

So the log file shows:
Running: MakeNSIS v2.46.3-Unicode - Copyright 1995-2009 Contributors
Processing script file: "C:/Data-Dart/Up-Soft/Navigation/opencpn-mingw/build/_CPack_Packages/win32/NSIS/project.nsi"
SetCompressor: /FINAL lzma

Invalid command: Unicode

Error in script "C:/Data-Dart/Up-Soft/Navigation/opencpn-mingw/build/_CPack_Packages/win32/NSIS/project.nsi" on line 36 -- aborting creation process

---Again!

Project.nsi
NSIS Installer script for OpenCPN (Windows)
NSIS version 2.46
Written by Gunther Pilz (Netsurfer) netsurfer@opencpn.de
==================
# Set unicode
Unicode true <--- Line 36
DOES NOT LIKE UNICODE TRUE now..

[rgleason]

So it is still using NSIS 2.46.3. I guess I have to uninstall both 2.46.3 and 3.0b then install NSIS 3.0b in the NSIS directory.

Note the NSIS installer is intalling into
C:\Program Files (x86)\NSIS3.00.b
and
C:\Program Files (x86)\NSIS2.46.3

--This has spaces in the directory. Is that going to cause problems? It is ok with MSVC but maybe not with mingw from my brief reading...

Please advise...Sean. Where is your NSIS directory?