OpenCPN Build on Win32

[nohal]

Dave,
I'm using VC++ 2008 Express on a pretty freshly installed Win7 in a 32bit virtual machine, but the results with VC++ 2010 Express were more or less the same. Chuck's suggestion (achieved by completely commenting out the _USE_32BIT_TIME_T part from CMakeLists.txt) works as far as compilation and linking goes.
More tomorrow as it's a bit late here

Pavel

[bdbcat]

Pavel....

Here is the deal, I think.

Your locally built version of wxWidgets and opencpn must be consistent in the use of _USE_32BIT_TIME_T. Unfortunately, we have no good way to determine how the wxWidgets dlls were built in this respect. Hmmm....

Where do your wxWidgets dlls come from?

Does this make sense?

Dave

[Netsurfer]

Dave,

Originally Posted by bdbcat

Here is the deal, I think.

Your locally built version of wxWidgets and opencpn must be consistent in the use of _USE_32BIT_TIME_T. Unfortunately, we have no good way to determine how the wxWidgets dlls were built in this respect. Hmmm....

As you know I have very little knowledge of these things, but wouldn't it be possible to upload the wxWidgets DLLs (for C++2008 EE and C++2010 EE) somewhere (on OpenCPN.org, git or OpenCPN.de)?

Gunther

[nohal]

Originally Posted by bdbcat

Your locally built version of wxWidgets and opencpn must be consistent in the use of _USE_32BIT_TIME_T. Unfortunately, we have no good way to determine how the wxWidgets dlls were built in this respect. Hmmm....

Where do your wxWidgets dlls come from?

Hi Dave,
WX was built on the same machine from the source (namely Download wxWidgets from SourceForge.net) - Opened (and converted to 2008) the wx_dll.dsw and built the dlls as it suggests in the docs.
And as expected, _USE_32BIT_TIME_T is not defined in those projects...
I've also tried to download the prebuilt wxPack | Main / HomePage browse and the result was the same.

After adding _USE_32BIT_TIME_T to all the WX projects and recompiling the dlls, BINGO! I can build OpenCPN without problems with the unmodified git source.

Thanks a lot for all the help!

Pavel

[nohal]

Hi guys,
I have put together sort of a guide for building OpenCPN on Windows in the wiki. Review and comments appreciated...
Compiling the Source in Windows | Official OpenCPN Homepage

Pavel

[Netsurfer]

Pavel,

at last someone did it - thanks so much!

Originally Posted by nohal

I have put together sort of a guide for building OpenCPN on Windows in the wiki. Review and comments appreciated...

But as normal I am still having some difficulties.

Could it be that there is one needed application missing?
When running CMake-gui it complains about missing GTK libraries.
This is the complete log message after configuring:

*** Building opencpn 2.2.727 *** *** Building PlugIns ***
*** Building grib_pi ***
*** Building demo_pi ***
*** Building dashboard_pi ***
*** Building celestial_navigation_pi ***
Some or all of the gtk libraries were not found. (missing: GTK2_GTK_LIBRARY GTK2_GLIB_LIBRARY GTK2_GDK_LIBRARY)
S57 ENC support: enabled
Writing spec file...
Configuring done

Also tried it without all the GTK stuff.

When compiling I always end up with the following result:

========== Erstellen: 4 erfolgreich, Fehler bei 2, 4 aktuell, 4 übersprungen ==========

The GRIB plugin makes trouble:

Building Custom Rule F:/GIT/opencpn/plugins/grib_pi/src/CMakeLists.txt
CMake does not need to re-run because F:\Opencpn-Build\plugins\grib_pi\src\CMakeFiles\generate.stam p is up-to-date.
Kompilieren...
IsoLine.cpp
zuFile.cpp
GribRecord.cpp
GribReader.cpp
..\..\..\..\GIT\opencpn\plugins\grib_pi\src\GribRe ader.cpp(545) : error C2668: 'abs': Mehrdeutiger Aufruf einer überladenen Funktion
D:\Program Files\Microsoft Visual Studio 9.0\VC\include\math.h(539): kann 'long double abs(long double)' sein
D:\Program Files\Microsoft Visual Studio 9.0\VC\include\math.h(491): oder "float abs(float)"
D:\Program Files\Microsoft Visual Studio 9.0\VC\include\math.h(487): oder "double abs(double)"
D:\Program Files\Microsoft Visual Studio 9.0\VC\include\math.h(485): oder "long abs(long)"
D:\Program Files\Microsoft Visual Studio 9.0\VC\include\stdlib.h(380): oder "int abs(int)"
bei Anpassung der Argumentliste '(time_t)'
grib.cpp
grib_pi.cpp
Code wird generiert...

And this is the one for opencpn.dir:

Verknüpfen...
Bibliothek "F:\Opencpn-Build\Release\opencpn.lib" und Objekt "F:\Opencpn-Build\Release\opencpn.exp" werden erstellt.
navutil.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""__declspec(dllimport) public: long __thiscall wxDateTime::GetTicks(void)const " (__imp_?GetTicks@wxDateTime@@QBEJXZ)".
routeman.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""__declspec(dllimport) public: long __thiscall wxDateTime::GetTicks(void)const " (__imp_?GetTicks@wxDateTime@@QBEJXZ)".
tcmgr.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""__declspec(dllimport) public: long __thiscall wxDateTime::GetTicks(void)const " (__imp_?GetTicks@wxDateTime@@QBEJXZ)".
ais.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""__declspec(dllimport) public: long __thiscall wxDateTime::GetTicks(void)const " (__imp_?GetTicks@wxDateTime@@QBEJXZ)".
chart1.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""__declspec(dllimport) public: long __thiscall wxDateTime::GetTicks(void)const " (__imp_?GetTicks@wxDateTime@@QBEJXZ)" in Funktion ""private: void __thiscall MyFrame::PostProcessNNEA(bool,class wxString &)" (?PostProcessNNEA@MyFrame@@AAEX_NAAVwxString@@@Z)" .
chartdb.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""__declspec(dllimport) public: long __thiscall wxDateTime::GetTicks(void)const " (__imp_?GetTicks@wxDateTime@@QBEJXZ)".
chartdbs.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""__declspec(dllimport) public: long __thiscall wxDateTime::GetTicks(void)const " (__imp_?GetTicks@wxDateTime@@QBEJXZ)".
chcanv.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""__declspec(dllimport) public: long __thiscall wxDateTime::GetTicks(void)const " (__imp_?GetTicks@wxDateTime@@QBEJXZ)".
chart1.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""protected: virtual void __thiscall wxLog:oLog(unsigned long,char const *,long)" (?DoLog@wxLog@@MAEXKPBDJ@Z)".
chart1.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""protected: virtual void __thiscall wxLogStderr:oLogString(char const *,long)" (?DoLogString@wxLogStderr@@MAEXPBDJ@Z)".
ais.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""__declspec(dllimport) public: class wxDateTime & __thiscall wxDateTime::Set(long)" (__imp_?Set@wxDateTime@@QAEAAV1@J@Z)" in Funktion ""public: class wxString __thiscall AIS_Target_Data::BuildQueryResult(void)" (?BuildQueryResult@AIS_Target_Data@@QAE?AVwxString @@XZ)".
F:\Opencpn-Build\Release\opencpn.exe : fatal error LNK1120: 4 nicht aufgelöste externe Verweise.

This is a very inconvenient process and a very frustating one, too.

I wonder if everybody has to compile everything by himself? Wouldn't it be possible to offer all the needed stuff for download except the GIT source? So only the last compilation with VC++2008 will be left.

But I'll never give up. So any help is very much appreciated!

Thanks,

Gunther

[nohal]

Gunther,
don't worry, we will get yo there

The GTK stuff should not be a problem at all AFAIK.

The duplicate math function definitions are something I can remember I've seen some time ago when starting to experiment with the cmake build (at that time I used the solution file floating around here, which didn't have this problem, but now everything looks OK to me)

The linker problems are caused by _USE_32BIT_TIME_T stuff discussed with Dave and Chuck a couple of messages ago. Are you sure you rebuilt WX after patching the projects? To check whether you have patched it, open the wx_dll.sln, open the properties of some project and have a look at Configuration Properties - C/C++ - Preprocessor. The first line (Preprocessor Definitions) should start with _USE_32BIT_TIME_T...
Then make sure you have fully rebuilt the solution - Right click on the solution and choose Rebuild solution (do this for both the Release DLL and Debug DLL configurations)
If you are sure, then you are in the opposite situation than I was and don't need to patch WX at all... that would make me feel really strange

Pavel

[Netsurfer]

Pavel,

thanks for your help!

Originally Posted by nohal

The GTK stuff should not be a problem at all AFAIK.

OK, so I forget about it ...

The duplicate math function definitions are something I can remember I've seen some time ago when starting to experiment with the cmake build (at that time I used the solution file floating around here, which didn't have this problem, but now everything looks OK to me)

The linker problems are caused by _USE_32BIT_TIME_T stuff discussed with Dave and Chuck a couple of messages ago. Are you sure you rebuilt WX after patching the projects? To check whether you have patched it, open the wx_dll.sln, open the properties of some project and have a look at Configuration Properties - C/C++ - Preprocessor. The first line (Preprocessor Definitions) should start with _USE_32BIT_TIME_T...
Then make sure you have fully rebuilt the solution - Right click on the solution and choose Rebuild solution (do this for both the Release DLL and Debug DLL configurations)
If you are sure, then you are in the opposite situation than I was and don't need to patch WX at all... that would make me feel really strange

I am quite sure that I have patched it. But to be on the safe side I started from scratch and did it all again.

And let me tell you - I succeeded!

========== Alles neu erstellen: 9 erfolgreich, Fehler bei 0, 2 übersprungen ==========

But then there is still one trap left. When try to use the newly build exe file OCPN did not start until I also replaced the 5 wx... .dll files .

I do not exactly know what went wrong yesterday. But I guess it was the re-build process in VC++2008 after patching the wx_dll project. As I use a German version I do not know the English name for the menu entries but the difference is using the Hot Keys 'F7' and 'Ctrl + Alt + F7'.

Pavel, once again many thanks for your help!

Gunther

PS: Maybe you could add a paragraph describing how to build the complete installer package with NSIS?

[nohal]

Originally Posted by Netsurfer

And let me tell you - I succeeded!

Congratulations!

But then there is still one trap left. When try to use the newly build exe file OCPN did not start until I also replaced the 5 wx... .dll files .

Yes, it should be mentioned, I will add it when I get a minute or just edit the wiki yourself if you like.

I do not exactly know what went wrong yesterday. But I guess it was the re-build process in VC++2008 after patching the wx_dll project. As I use a German version I do not know the English name for the menu entries but the difference is using the Hot Keys 'F7' and 'Ctrl + Alt + F7'.

F7 - Build, Ctrl + Alt + F7 = Rebuild
If someone could explain me why they don't use the same shortcuts in Express and normal Visual Studio, I would be very grateful

PS: Maybe you could add a paragraph describing how to build the complete installer package with NSIS?

This one will be pretty short Just build the PACKAGE project and the exe installer will appear in your build directory...
Small warning - the WX dlls don't get updated with your version when installing over a previous version right now.
I will have a look at the installer creation a bit when time permits as it looks like another thing Dave doesn't appreciate that much but has to be handled

Pavel

[Netsurfer]

Pavel,

once again thanks for the tip!

Originally Posted by nohal

This one will be pretty short Just build the PACKAGE project and the exe installer will appear in your build directory...
Small warning - the WX dlls don't get updated with your version when installing over a previous version right now.
I will have a look at the installer creation a bit when time permits as it looks like another thing Dave doesn't appreciate that much but has to be handled

Worked (at once) like a charm ...!

But as far as I could see, the 5 wx... .DLL files are included in the package but not the self-compiled (local) ones. So OCPN won't start until you locally exchanged the 5 DLL files.

The setup file is completely different from the "original" (Dave's) one.
Starts with another icon and different screens for the options.
Or has Dave generally changed these things?

And one request:
The build number is included on the start screen of the installer. Please add it to the file name, e.g. "opencpn_22_727_setup.exe" instead of "opencpn_22_setup.exe" - thanks!

Gunther

[nohal]

Originally Posted by Netsurfer

The setup file is completely different from the "original" (Dave's) one.
Starts with another icon and different screens for the options.
Or has Dave generally changed these things?

Yes, a lot has changed - until now the installer was built using InnoSetup (locally by Dave, script never in the code repository), not NSIS.
Add the problems you find to Flyspray - maybe someone will be faster than me in learning NSIS and fixing them...

Pavel

[bdbcat]

Gunther and Pavel....

Good job on plowing through this build process. Now we know where the potential potholes are

Comments:
1. I'm going to look at the 32bit_time_t define issue again. It may be that the VS2005 that I am using treats this differently when the wxWidgets dlls are built by me locally. I would rather use the tool defaults here to avoid the sed step.
There is nothing in ocpn that cares about the size of time_t....

2. The NSIS installer definitely has a new look and feel. I plan for this to become the Windows installer on the next Beta, and subsequent releases. Perhaps you missed my post on the 2.2 Beta test thread?

http://www.cruisersforum.com/forums/...est-43470.html

3. The NSIS installer currently gets the wxWidgets dlls from the git repository clone. These are the ones that we built by me with VS2005. If we fix the time_t issue, there should be no need to have the installer use locally built wxWidgets dlls. Of course, for debugging, one would need locally built (debug) wxWidgets dlls. So the wxWidgets build step is valid for local debugging.

Gunther, you have said that ocpn won't start using the git clone wxWidgets dlls.
I do not understand this. Is this a problem with the msvcrt.dll? The dlls in the repo link to MSVCR80.dll Maybe VS2008 uses a different MSVCR version? More info, please.

The old Inno installer copied the required MSVCR80 dlls to the OpenCPN directory, so they we available to the application at run-time. The NSIS installer does no do this currently, but depends on whatever is currently on the target system. I think I need to cause the installer to execute the MSVC redistributable application targeted to the MSVC version (2005) that I have used for the embedded wxWidgets dlls.

This whole dll issue arises from the PlugIn architecture. We used to be statically linked to wxWidgets.

I love Windows.....

Anyway, thanks for the reports. We make progress...
Dave

[bdbcat]

Pavel...

Good day.

I will focus on these installer issues today. We are close. You are right. This is not my favorite part of the project.....

Dave

[nohal]

Originally Posted by bdbcat

1. I'm going to look at the 32bit_time_t define issue again. It may be that the VS2005 that I am using treats this differently when the wxWidgets dlls are built by me locally. I would rather use the tool defaults here to avoid the sed step.
There is nothing in ocpn that cares about the size of time_t....

If it's not needed for OpenCPN, then we can just remove the following from CmakeLists.txt:

#  Fix up time_t definition
# Checks for 32-bit version. And always use 32-bit time_t for compatibility
IF(WIN32 AND NOT UNIX)
  ADD_DEFINITIONS(-D_USE_32BIT_TIME_T)
ENDIF(WIN32 AND NOT UNIX)

and it's done... No WX patching will be needed anymore. The compilation worked ok when I commented it out and the program looked like not suffering at all, but I didn't do any serious testing with that build.

3. The NSIS installer currently gets the wxWidgets dlls from the git repository clone. These are the ones that we built by me with VS2005. If we fix the time_t issue, there should be no need to have the installer use locally built wxWidgets dlls. Of course, for debugging, one would need locally built (debug) wxWidgets dlls. So the wxWidgets build step is valid for local debugging.

Gunther, you have said that ocpn won't start using the git clone wxWidgets dlls.
I do not understand this. Is this a problem with the msvcrt.dll? The dlls in the repo link to MSVCR80.dll Maybe VS2008 uses a different MSVCR version? More info, please.

This whole dll issue arises from the PlugIn architecture. We used to be statically linked to wxWidgets.

Ahhh, pretty obvious then - the app needs the DLLs against which it was built. I would prefer to include those, so you don't have to care about the binaries in git. Hard to say with MSVC runtime - I don't have any machine available right now where it's not already installed about a million times, so it can't fail for me. I can try to stress it a little bit on a clean virtual machine after returning from a regatta on Sunday.

I love Windows.....

Me too...

Pavel

[Netsurfer]

Dave,

I followed Pavels instructions at Compiling the Source in Windows | Official OpenCPN Homepage.

Originally Posted by bdbcat

Gunther, you have said that ocpn won't start using the git clone wxWidgets dlls.
I do not understand this. Is this a problem with the msvcrt.dll? The dlls in the repo link to MSVCR80.dll Maybe VS2008 uses a different MSVCR version? More info, please.

I gladly will do, but what shall I say ...?
I don't know where the problem derives from as the (Windows) error message says nothing concrete (at least to me). And sometimes there is not any.

But OCPN won't start until I have manually copied the 5 DLL files from ..\wxWidgets-2.8.11\lib\vc_dll to the OCPN program dir.

If you can tell me how to figure out any further details/ information I am pleased to do so.

Gunther