Problems with Cross-Compiling OpenCPN

[egon.5004]

CMake is asking for glu32open32 lib. I cannot find it. What am I missing?

cmake -DCMAKE_TOOLCHAIN_FILE=../buildwin/Toolchain-mingw32.cmake ..
-- *** Build Architecture is i386
-- *** Staging to build opencpn 4.1.915 ***
-- *** Package will include documentation ***
-- *** Package will include GSHHS basechart level: CRUDE ***
-- *** Package will include tide and current data ***
-- Found OpenGL...
--     Lib: glu32opengl32
--     Include: 
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
  Could NOT find wxWidgets (missing: wxWidgets_FOUND)
Call Stack (most recent call first):
  /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-2.8/Modules/FindwxWidgets.cmake:832 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:372 (FIND_PACKAGE)

[nohal]

As the error says you are missing wxWidgets, there is no problem with the glu library as far as I can tell.
It also looks like you are trying to build a very out of date source tree, is there any reason for that?

Pavel

[egon.5004]

Thank you for answering.
I am following the instructions for cross compiling given on the OpenCPN Site.
I have cloned the git repository and i Have cross compiled wxwidgets as suggested.

The only hint I could not follow is this:
Copy the wxWidgets libraries into a folder here called wxWidgets-mingw

I do not know what that really means nor where to find the "libraries". Could that be the reason?

+++, Egon

[egon.5004]

After a lot of frustration here is what I needed to do to solve it:

instead of
cmake -DCMAKE-TOOLCHAIN_FILE=../buildwin/Toolchain-mingw.cmake ..

as indicated by the instruction I hat to add a slash to the end of the line
cmake -DCMAKE-TOOLCHAIN_FILE=../buildwin/Toolchain-mingw.cmake ../

Problem solved

[rgleason]

egon
Do you think this should be changed in the manual, for others?
If so, please explain in more detail giving the page link and specific changes..
Thank you.

[seandepagnier]

I don't know why you need ../ What shell did you use?

Are you building on linux?

Does the resulting opencpn work well?

[Ptizef]

Hi
I see I am not the only one to have problem with the cross-compilation from Linux to Windows.
My system is Ubuntu 16.04LTS.
After lot of changes I was successful building OpenCPN and the installer. But if the installer worked fine, OpenCPN itself ran but crashed as soon as I tried to display cm93 and crashed also when displaying rasters, after some zooms and pans.
So I take the process at the very beginning trying to understand why it doesn't work as expected
Wine is installed and works fine. Mingw-w64 too (or at least seems to )
wxWidgets was installed and built . I used wxWidgets-3.0.2 .

The first problem came when I tried to build O. I got this errors:
/usr/bin/i686-w64-mingw32-ld : ne peut trouver -lcurl
/usr/bin/i686-w64-mingw32-ld : ne peut trouver -lwx_mswu_gl-3.0
and so for all the wxWidgets library...

-For the curl file I would suggest a change in Curl.cmake line 20:
- SET(CURL_LIBRARIES "curl.dll")
+ SET(CURL_LIBRARIES "${CMAKE_SOURCE_DIR}/buildwin/libcurl.lib")
Is this correct?

-For the wxWigets files :
As in the linklibs.rsp file the search is for the form "libwx_mswu_aui-3.0.a"
but exist in the form libwx_mswu_aui-3.0-i686-w64-mingw32.dll.a
so I have to change the file's names.
But Why and are these changes correct ?

Next I got is this link error:
/usr/local/i686-w64-mingw32/include/wx-3.0/wx/event.h:3505: référence indéfinie vers « wxEVT_DOWNLOAD_EVENT »
/usr/local/i686-w64-mingw32/include/wx-3.0/wx/event.h:3505: référence indéfinie vers « wxEVT_DOWNLOAD_EVENT »
CMakeFiles/chartdldr_pi.dir/objects.a(chartdldr_pi.cpp.obj): dans la fonction « ZN12wxEvtHandler7ConnectEiiiMS_FvR7wxEventEP8wxObj ectPS_ »:
/usr/local/i686-w64-mingw32/include/wx-3.0/wx/event.h:3478: référence indéfinie vers « wxEVT_DOWNLOAD_EVENT »
/usr/local/i686-w64-mingw32/include/wx-3.0/wx/event.h:3478: référence indéfinie vers « wxEVT_DOWNLOAD_EVENT »
collect2: error: ld returned 1 exit status

I have no solution at the moment so I deactivated this plugin to continue the process

As I use wxWidgets-3.0.2 instead of 2.8, So I changed in grib's Cmakelists.txt line 220 :
- "-L${wxWidgets_ROOT_DIR}/lib -lwxzlib-2.8")
+ "-L${wxWidgets_ROOT_DIR}/lib -lwxzlib-3.0-i686-w64-mingw32")
but I got this error
/usr/bin/i686-w64-mingw32-ld : ne peut trouver -lwxzlib-3.0.2-i686-w64-mingw32
collect2: error: ld returned 1 exit status

libwxzlib-3.0.2-i686-w64-mingw32 exists and has been built as all wxWidgets library, but the install process didn't copy it
to the right place. Why ? I have done it manually.Is it correct?

Then at last the built process goes to the end ( except chartdldr_pi )
But there is certainly something wrong as opencpn.exe is 110 Mb wide instead of around 7 Mb !

Jean Pierre

[seandepagnier]

I know cross built opencpn worked fine in wine with cm932 charts etc without crashing before.


As for the issues...


wx 3.0 used a new naming scheme for the libraries as you have found. I built using wx 2.8 on windows, and this also may explain various differences. It might be worthwhile to perform a bisect building with wx 2.8 starting from about a year ago (if you can cross build that version with wx2.8 and verify it runs ok without crashing)

Although it is old version, try this and see if it runs and is stable:
https://sourceforge.net/projects/ope..._experimental/

If so, then a bisect should reveal the issue, but you should first build the version that works with wx 2.8 using wx 3.0 to verify the problem is in opencpn.

Otherwise the bisect might have to go further back to when mingw support got integrated.

Alternatively you should be able to run the mingw gdb to find the crash to fix it.

As for the file size of opencpn.exe, did you try running it through strip? It probably has debugging symbols.

My final packages build using the nsis installer (you managed to work out) were smaller than the visual studio packages by a few MB.

[seandepagnier]

As for the chart downloader... I never built it with mingw, and the issue is still unresolved. I think the symbols collide from the core to the plugin maybe?

As for copying the libz, I think that it doesn't get installed by default so yes you need to copy it manually.

[Ptizef]

Hi Sean

Many thanks for your answer.
I'll try what you suggest and be back.
JP

[egon.5004]

@rgleason
I am referring to the instructions for cross-compiling, to the line reading:
$ cmake -DCMAKE_TOOLCHAIN_FILE=../buildwin/Toolchain-mingw32.cmake ..
The problem occurred under Linux Mint 17.2 as well as 17.3

I just opened the standard terminal (bash shell) and executed the commands as su.

I don't know whether that is a general issue because it does not really make sense. ".." and "../" should be synonymes - but computers are always right, no use arguing - and I guess the extra slash won't cause any problems on other systems. So, yes, why not add it to the instructions.

@boat alexandra
I compiled the code under Linux as well as under Windows 10 and I also did the cross compilation. All the features I was interested in are working well.

[Ptizef]

when I use
"cmake -DCMAKE_TOOLCHAIN_FILE=../buildwin/Toolchain-mingw32.cmake ../"
with the slash as suggested, the cmake process ends with this warning, saying the
toolchain was not used :
""
-- Writing spec file...
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_TOOLCHAIN_FILE
""
But it works perfectly without slash for me.
JP

[SamsonovAnton]

Originally Posted by nohal

It looks like you are trying to build a very out of date source tree.

Surprisingly enough, I also have include/version.h with similar content despite being up-to-date with master branch:

#define VERSION_MAJOR 4
#define VERSION_MINOR 1
#define VERSION_PATCH 925
#define VERSION_DATE "2015-09-25"

This may even lead to plugin build errors.

However, when I git log include/version.h, the most recent line reads:

commit baeff5804b3e2cd69f69c26b15e031e9be0ad878
Author: David Register <bdbcat@users.sourceforge.net>
Date:   Thu Dec 8 20:36:17 2011 -0500

    Remove, this is a build product.

What the hull?

[nohal]

Anton...
version.h is a build product, created by cmake from https://github.com/OpenCPN/OpenCPN/b...r/version.h.in during the configure phase of the build from the data in https://github.com/OpenCPN/OpenCPN/b.../VERSION.cmake

Long time ago, version.h used to be created in the include directory, for quite some time it is created in the build directory. If you have some forgotten version.h in the include directory, you should simply remove it.

Pavel

[SamsonovAnton]

Originally Posted by nohal

Long time ago, version.h used to be created in the include directory, for quite some time it is created in the build directory. If you have some forgotten version.h in the include directory, you should simply remove it.

I think I figured out the cause, but still have no idea how exactly did it happen that way.

• As far as I remember, it started only this autumn: version jumped back from 4.5.0 (or at least 4.3.x/4.4.x) to 4.1.925 — it was very noticeable as the regular confirmation dialog popped up at startup.
• I also recall doing a bisection on October, 17th, however not sure whether that was before or after the version change. But I am pretty confident I did not go back too far: the starting point was somewhere in March 2016.
• Now I see that include/version.h is also dated October, 17th in my source tree — that must not be just a coincidence. But how on earth was that file checked out or generated by build configuration script?
• gitk hints that the commit I finally landed at follows the “v4.1.925” tag which points at commit that made corresponding changes to VERSION.cmake without touching anything else.

So I am really puzzled by both the way it occurred and how not to repeat such mistake in the future.