Generating windows beta plugin fails

[LennartG-Sve]

I got a problem building Windows beta plugins for GPS Odometer and uploading to git from my ubuntu 20.04 system. Compiling locally using ubuntu 20.04 and TP v230 works just fine and the plugin executes without any errors on Linux. I don't have any Windows system so I rely on git -> beta -> AppVeyor.

However, the build process initiated thru AppVeyor, and referencing the beta upload I did four days ago, gave this error message. Both Windows versions (2017 and 2022) fails with the same message:

_C:\project\ocpn_project\build\Release\gpsodometer_pi.dll : fatal error LNK1120: 20 unresolved externals [C:\project\ocpn_project\build\gpsodometerpi.vcxproj] Command exited with code 1

[rgleason]

There is no appveyor listed in https://github.com/LennartG-Sve/GPS-Odometer_pi/runs/12567717947

Have you checked your appveyor account and made sure that this project is enabled and your account has the right permissions to work with github and cloudsmith? You might have to renew your credentials. I had to do that with several plugins.

[LennartG-Sve]

@rgleason , not sure what you mean, I do have an AppVeyor account and have used it numerous times, see the attached picture showing the main page from my last run and, yes I'm not logged in when doing this snapshot. Also see the lover right corner saying 'failed'. This failure is surely the reason you could not find any run, it never finished. Besides: How should I be able to get the compiler error message if I did not have a working account, it should have kicked me out and not allowed me to even get started. Now it went on for over 2 minutes.

[LennartG-Sve]

Guys, eventually on to something: Examining the complete compiler log file reveals that 'WX_VER' is not set. Checking 'appveyor.yml' from TP v230, that I used, reveals it as empty (set WX_VER= ). Which is the correct setting for VS2017 and VS2022 respectively?

[rgleason]

Ok, so you have looked at the log and the errors there and it is related to wx_ver=

Do you have this from the top of the log?

Build started
appveyor version
6.3.2.3063
git clone -q --depth=10 -n --branch=v1.9.56.0 https://github.com/rgleason/weatherfax_pi.git c:\project\ocpn_project
git checkout -qf v1.9.56.0
Running Install scripts
call "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars32.bat"
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.5.0
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x86'
set WX_VER=32
set WXWIN=C:\wxWidgets-3.2.1
set wxWidgets_ROOT_DIR=%WXWIN%
set wxWidgets_LIB_DIR=%WXWIN%\lib\vc_dll
set cmake_parms=-A Win32
SET PATH=%PATH%;%WXWIN%;%wxWidgets_LIB_DIR%;C:\Program Files\Poedit\Gettexttools\bin
choco install poedit
Chocolatey v1.3.0
Installing the following packages:
poedit
By installing, you accept licenses for the packages.
Progress: Downloading poedit 2.4.2... 100%

This is the appveyor log link for weatherfax perhaps you are given access to it? https://ci.appveyor.com/project/rgleason/weatherfax-pi/build/job/o279jqjgadspkdlt

Try using the update of FE2 files from this batch file, to make sure you have updated the template (but it should work, since you merged my PR. Humm, I have to think about this a little more.

[LennartG-Sve]

@rgleason , I checked the VS2017 first, it was the one lacking WX_VER. VS2022 does have a WX_VER setting. There is no difference from yours, apart from the git clone and git checkout lines, that should differ of course. My complete VS2022 build log is attached. VS2022_build.log.zip

[rgleason]

Lennart, doing a search on "error" I found this library problem unresolved external symbol. Just and off the wall comment what api is this using?

     Creating library C:/project/ocpn_project/build/Release/gpsodometer_pi.lib and object C:/project/ocpn_project/build/Release/gpsodometer_pi.exp
spe     Creating library C:/project/ocpn_project/build/Release/gpsodometer_pi.lib and object C:/project/ocpn_project/build/Release/gpsodometer_pi.exp
speedometer.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall PlugInChartBaseGLPlus2::~PlugInChartBaseGLPlus2(void)" (??1PlugInChartBaseGLPlus2@@UAE@XZ) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]
odometer_pi.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall PlugInChartBaseGLPlus2::~PlugInChartBaseGLPlus2(void)" (??1PlugInChartBaseGLPlus2@@UAE@XZ) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]
instrument.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall PlugInChartBaseGLPlus2::~PlugInChartBaseGLPlus2(void)" (??1PlugInChartBaseGLPlus2@@UAE@XZ) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]
button.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall PlugInChartBaseGLPlus2::~PlugInChartBaseGLPlus2(void)" (??1PlugInChartBaseGLPlus2@@UAE@XZ) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]
dial.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall PlugInChartBaseGLPlus2::~PlugInChartBaseGLPlus2(void)" (??1PlugInChartBaseGLPlus2@@UAE@XZ) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]
speedometer.obj : error LNK2001: unresolved external symbol "public: virtual class ListOfPI_S57Obj * __thiscall PlugInChartBaseGLPlus2::GetLightsObjRuleListVisibleAtLatLon(float,float,class PlugIn_ViewPort *)" (?GetLightsObjRuleListVisibleAtLatLon@PlugInChartBaseGLPlus2@@UAEPAVListOfPI_S57Obj@@MMPAVPlugIn_ViewPort@@@Z) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]
odometer_pi.obj : error LNK2001: unresolved external symbol "public: virtual class ListOfPI_S57Obj * __thiscall PlugInChartBaseGLPlus2::GetLightsObjRuleListVisibleAtLatLon(float,float,class PlugIn_ViewPort *)" (?GetLightsObjRuleListVisibleAtLatLon@PlugInChartBaseGLPlus2@@UAEPAVListOfPI_S57Obj@@MMPAVPlugIn_ViewPort@@@Z) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]
instrument.obj : error LNK2001: unresolved external symbol "public: virtual class ListOfPI_S57Obj * __thiscall PlugInChartBaseGLPlus2::GetLightsObjRuleListVisibleAtLatLon(float,float,class PlugIn_ViewPort *)" (?GetLightsObjRuleListVisibleAtLatLon@PlugInChartBaseGLPlus2@@UAEPAVListOfPI_S57Obj@@MMPAVPlugIn_ViewPort@@@Z) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]edometer.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall PlugInChartBaseGLPlus2::~PlugInChartBaseGLPlus2(void)" (??1PlugInChartBaseGLPlus2@@UAE@XZ) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]
odometer_pi.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall PlugInChartBaseGLPlus2::~PlugInChartBaseGLPlus2(void)" (??1PlugInChartBaseGLPlus2@@UAE@XZ) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]
instrument.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall PlugInChartBaseGLPlus2::~PlugInChartBaseGLPlus2(void)" (??1PlugInChartBaseGLPlus2@@UAE@XZ) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]
button.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall PlugInChartBaseGLPlus2::~PlugInChartBaseGLPlus2(void)" (??1PlugInChartBaseGLPlus2@@UAE@XZ) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]
dial.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall PlugInChartBaseGLPlus2::~PlugInChartBaseGLPlus2(void)" (??1PlugInChartBaseGLPlus2@@UAE@XZ) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]
speedometer.obj : error LNK2001: unresolved external symbol "public: virtual class ListOfPI_S57Obj * __thiscall PlugInChartBaseGLPlus2::GetLightsObjRuleListVisibleAtLatLon(float,float,class PlugIn_ViewPort *)" (?GetLightsObjRuleListVisibleAtLatLon@PlugInChartBaseGLPlus2@@UAEPAVListOfPI_S57Obj@@MMPAVPlugIn_ViewPort@@@Z) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]
odometer_pi.obj : error LNK2001: unresolved external symbol "public: virtual class ListOfPI_S57Obj * __thiscall PlugInChartBaseGLPlus2::GetLightsObjRuleListVisibleAtLatLon(float,float,class PlugIn_ViewPort *)" (?GetLightsObjRuleListVisibleAtLatLon@PlugInChartBaseGLPlus2@@UAEPAVListOfPI_S57Obj@@MMPAVPlugIn_ViewPort@@@Z) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]
instrument.obj : error LNK2001: unresolved external symbol "public: virtual class ListOfPI_S57Obj * __thiscall PlugInChartBaseGLPlus2::GetLightsObjRuleListVisibleAtLatLon(float,float,class PlugIn_ViewPort *)" (?GetLightsObjRuleListVisibleAtLatLon@PlugInChartBaseGLPlus2@@UAEPAVListOfPI_S57Obj@@MMPAVPlugIn_ViewPort@@@Z) [C:\project\ocpn_project\build\gpsodometer_pi.vcxproj]

[LennartG-Sve]

Rick, so those have not been found, odd indeed. Funny thing these are 'obj'-files indicating, to me, a compiler problem. It is not that the files are not found in the first place, They are indeed found elsewhere in the process.

My Windows knowledge is almost zero-nil-nothing so I have no idea. HELP!

[jongough]

For windows do you have the correct opencpn.lib file? You need to have a matching one from ocpn to the API version you are using. The FE2 version one is tied to its version of the API.

[LennartG-Sve]

Jon, thanks for the prompt reply and sorry for the delay in answering (out of my control). In the first test I had replaced the original API with a version 1.17 but now I switched back to the 1.16 from TP v230. The reason for this chance was that I have implemented socketCAN. The compile still fails but different this time, looks like it is due to the use of 1.16 instead of 1.17. getting e.g this line: _C:\project\ocpn_project\src\odometer_pi.cpp(243,5): error C2065: 'NMEA2000Id': undeclared identifier [C:\project\ocpn_project\build\gpsodometerpi.vcxproj]

Will look for a opencpn.lib file matching 1.17 or even go for 1.18 if I can find a matching pair. Complete log file is attached.

VS2022_build_116.log.zip

[jongough]

Currently only have a phone with patchy internet, so cannot look at files. The opencpn.lib file is needed to provide the classes/methods that are supplied by opencpn, so you need to use the API that has these. The lib file needs to be in your git repository for the appveyor builds to find it. I would suspect that your API header file is OK but you haven't updated to the corequisite lib file.

[LennartG-Sve]

Jon, it sure looks like that. I've looked around for a 'file pair' and found Alec's set of libraries. They are however, within the respective api's, sorted in a way that differs from TP. Also sizes differ. I will simply wait until TP gets updated with a later API. No worry, i've probably messed up things enough already with this ubuntu/debian stuff in the previous issue as well.

[rgleason]

Lennart, I could try gps-odometer on my remote repos by turning on Appveyor to see what happens if that will help.

[LennartG-Sve]

Rick, go ahead if you like. The 'problem is that you, using the 1.16 file pair, will get nmea2000 error messages and with the 1.17 file pair will get the errors you saw earlier. It should be possible to use Alec's libraries but the msvc library is separated in two for ws 30 and ws32 plugins respectively and also the API file sizes differ from what has been/is used in OpenCPN. Probably need to modify appveyor.yml as well.

But again, feel free to try but it will likely need be modified later.

[LennartG-Sve]

Rick, I tried using Alec's 1.17 ocpn-api directory, it did not work but failed even on Linux (strange). I will leave it at that. Better wait for the proper upgrade of TP. We also need the upgrade for the jammy builds using debian.

EDIT: Comparing the two ocpn_plugin.h that I have (once taken from OpenCPN) and the one in Alec's collection opencpn-libs-main/api-17/there are indeed major differences.

[LennartG-Sve]

Rick, I've updated to API 1.18 and it compiles correct locally, very close to the 1.17 I had. My concern is though that Alec's 1.18 uses msvc-wx32, guess it is VS2022 only. What happens then with users of older Windows systems and how old are they? Will e.g.Win 7 still be updated with the updated plugin?

Have not uploaded to git yet, holding back for your answer.

[rgleason]

Lennart, There are many moving parts here as you know., this is about OpenCPN 5.8 API 1.18 is supported by O5.8 which generally always uses wxWidgets 3.2.1 (in the case of the plugins and wxWidgets 3.2.2.1 in the case of opencpn 5.8 (due to improvements in DPI scaling). Windows 7 and greater will be supported, but not Win XP or NT

Both VS compilers work the same to build OpenCPN5.8

Note that in the metadata xml file msvc is the O50-O56.2 version and msvc-wx32 is the O58 version.

[LennartG-Sve]

Rick, then I got it right. The next release of GPS Odometer will require O 5.8 and, for Windows, supporting Windows 7 upwards. The number of platforms on Linux is still to be seen, I've excluded jammy. Macos will be supported, have seen it compile. Windows systems using mingw (VS2017) will be excluded no matter if they update to 5.8 or not as they do not have wx32 (not sure if they can update to 5.8). Tomorrow I will modify appveyor.yml to exclude the first (VS2017) matrix section and then upload to git plus run appveyor. Feel it may work.

EDIT: leamas api 1.18 only have msvc-wx32 so no support for mingw.

[rgleason]

That's right. You should keep the old gps-odometer xmls in the plugins master branch/catalog because you don't want to have to changeover to using API 1.17 which evidently works with O5.6.2

I believe API 1.18 has all the nmea2000 changes etc. and O5.6.2 does not support those features.

For existing plugins that are not using the new features in O58 the older API's can still be used and you are also able to compile for both O5.6.2 and O5.8.

Of course a change in widgets from 3.1.2 to 3.2.2 also throws a twist in there too and we may not be able to just build plugins for both versions! If anyone knows for sure please advise.

[LennartG-Sve]

This is apparently a bit above my knowledge level: 1/ All linux/macos builds (but jammy that is disabled) are ok. 2/ VS2017 started and failed in spite of my appveyor changes. 3/ VS2022 also failed but with an unresolved N2k symbol message.

Leaving this to the experts.

[rgleason]

Appears my knowledge is at the same level. Perhaps Jon will have some thoughts, but I don't see the failed msvc builds in your github

https://github.com/LennartG-Sve/GPS-Odometer_pi/commits/master

I wanted to see the error being generated. Did you disable msvc-wx32 builds? Is your appveyor project working?

[LennartG-Sve]

Rick, the build log is attached.

VS2022_build_118.log.zip

EDIT: Github contains the setup that was causing the error. msvc-wx32 builds are enabled.

[rgleason]

I tried building with wxWidgets 3.2.2 and api 1.16 and running it in the new downloaded official 5.8 and it seems to work.

I will try later with api 1.18.

Then I will pull from your repos and try it.

Best. Rick

[rgleason]

Tried building locallly with wxWidgets 3.2.2 and API 1.18 (ocpn_plugins.h) and the 5.8 opencpn.lib for relwithdebug from my most recent opencpn local, because that is what I do. It seems to work fine. No errors found. Have not tested signalk or nmea2K.

File attached below

gpsodometer_pi-0.6.6.8-msvc-x86_64-wx32-10.0.22621-MSVC.tar.gz

Will pull yours later and try it.

[LennartG-Sve]

Rick, the error I got is about an unresolved N2k synbol and N2k (socketCAN) was added in 0.7.0.0. Funny thing though it is working in Linux so the problem feels likely to be within the msvc-wx32/ocpn_plugin.h area or how it is implemented in the CMakeLists.txt.

[LennartG-Sve]

Rick, where have you got your opencpn.lib? Can't find it in O 5.8.0.

[rgleason]

Lennart, I don't find it either, which is a pain in the neck.

I used the opencpn.lib which was build from TDan's LocalBuildWin branch because it was available, but if you build OpenCPN in Windows, lets say using 'RelWithDebInfo" you will most likely find it under

C:\Users\fcgle\source\repos\OpenCPN\build\RelWithDebInfo

It is also found under Release and Debug. Use the appropriate one (I think).

[LennartG-Sve]

Rick, that would be fine, if I just had a Windows system. Which I don't. The one I've used is from Alec's plugin library.

[rgleason]

Where is that?

[LennartG-Sve]

https://github.com/leamas/opencpn-libs

[rgleason]

https://github.com/leamas/opencpn-libs/blob/main/api-18/msvc-wx32/opencpn.lib I probably should bookmark https://github.com/leamas/opencpn-libs thanks.

Your plugin looks very different than Jon's
https://github.com/jongough/testplugin_pi/tree/master/libs/ocpn-api https://github.com/LennartG-Sve/GPS-Odometer_pi/tree/master/libs/ocpn-api

What you have is logical, but does your CMakeLists.txt point properly? Furthermore, Jon may have made some assumptions about the folder msvc in the many cmake files.

[rgleason]

I've reconfigured a little and now what I am getting is this error. I need to check the opencpn.lib ocpn_plugins.h and make sure they are being found. Also make sure they are right. Will try tonight.

C:/Users/fcgle/source/GPS-Odometer_pi/build/RelWithDebInfo/gpsodometer_pi.exp
odometer_pi.obj : error LNK2019: unresolved external symbol "bool __cdecl ParseN2kPGN129029(class std::vector<unsigned char,class std::allocator<unsigned char> > &,unsigned char &,unsigned short &,double &,double &,double &,double &,enum tN2kGNSStype &,enum tN2kGNSSmethod &,unsigned char &,double &,double &,double &,unsigned char &,enum tN2kGNSStype &,unsigned short &,double &)" (?ParseN2kPGN129029@@YA_NAAV?$vector@EV?$allocator@E@std@@@std@@AAEAAGAAN333AAW4tN2kGNSStype@@AAW4tN2kGNSSmethod@@13331423@Z) referenced in function "private: void __thiscall odometer_pi::HandleN2K_129029(class ObservedEvt)" (?HandleN2K_129029@odometer_pi@@AAEXVObservedEvt@@@Z) [C:\Users\fcgle\source\GPS-Odometer_pi\build\gpsodometer_pi.vcxproj]
odometer_pi.obj : error LNK2019: unresolved external symbol "bool __cdecl ParseN2kPGN129026(class std::vector<unsigned char,class std::allocator<unsigned char> > &,unsigned char &,enum tN2kHeadingReference &,double &,double &)" (?ParseN2kPGN129026@@YA_NAAV?$vector@EV?$allocator@E@std@@@std@@AAEAAW4tN2kHeadingReference@@AAN3@Z) referenced in function "private: void __thiscall odometer_pi::HandleN2K_129026(class ObservedEvt)" (?HandleN2K_129026@odometer_pi@@AAEXVObservedEvt@@@Z) 

[LennartG-Sve]

Rick, 1/ the difference between ocpn-api's is that Alec's master libs are not API 1.18 while mine is. 2/ The error you get is very close to what I have, just a difference in reference information, probably due to some changes in CMakeLists.txt. The error is however basically the same.

It appears that all files are found or you would likely get a more extensive error. Also: As it works in Linux, I feel, this is likely something a bit more 'sophisticated'. Like a mismatch between opencpn.lib and ocpn-plugin.h?

[rgleason]

Well this is what debug is for (well actually it had to build first)! I will build a RelWithDebInfo version and copy the dll and pdb files under that RelWithDebInfo into the plugins directory in OpenCPN and run VS to see what happens.

But first I am going to try using Tdan's opencpn.lib <-- they are the same size and date.

[rgleason]

Got the same error. Are you using any N2K in your code? I could not find ParseN2kPGN129029

     Creating library C:/Users/fcgle/source/GPS-Odometer_pi/build/RelWithDebInfo/gpsodometer_pi.lib and object C:/Users/fcgle/source/GPS-Odometer_pi/build/RelWithDebInfo/gpsodometer_pi.exp
odometer_pi.obj : error LNK2019: unresolved external symbol "bool __cdecl ParseN2kPGN129029(class std::vector<unsigned char,class std::allocator<unsigned char> > &,unsigned char &,unsigned short &,double &,double &,double &,double &,enum tN2kGNSStype &,enum tN2kGNSSmethod &,unsigned char &,double &,double &,double &,unsigned char &,enum tN2kGNSStype &,unsigned short &,double &)" (?ParseN2kPGN129029@@YA_NAAV?$vector@EV?$allocator@E@std@@@std@@AAEAAGAAN333AAW4tN2kGNSStype@@AAW4tN2kGNSSmethod@@13331423@Z) referenced in function "private: void __thiscall odometer_pi::HandleN2K_129029(class ObservedEvt)" (?HandleN2K_129029@odometer_pi@@AAEXVObservedEvt@@@Z) [C:\Users\fcgle\source\GPS-Odometer_pi\build\gpsodometer_pi.vcxproj]
odometer_pi.obj : error LNK2019: unresolved external symbol "bool __cdecl ParseN2kPGN129026(class 

Is there a N2k library that you are using that CMakeLists.txt is missing? I would suggest reviewing your includes in CMakeLists.txt to make sure something is not missing. Didn't you have to add files or libs for signalK and n2k features?

OCPNHDRS has # ocpninclude/ocpn_plugin.hcomment out libs/ocpn-api/ocpn_plugin.h

include/wx folder is duplicated by
libs/wxJSON I think I would try removing it.

The folder include/N2KParser looks like what is needed. I think should be included in CMakeLists.txt for sure. So I'm going to try adding INCLUDE_DIRECTORIES(BEFORE ${PROJECT_SOURCE_DIR}/include/N2KParser)

[rgleason]

Nope that did not work.
I think you should find the source of N2KParser and copy it and try building. This would not normally involve Jon.

[LennartG-Sve]

Rick, my main splitting point here is that ti compiles and works on Linux but not on Windows. That, IMHO, should mean that the basic code is correct and that the problem is within the AppVeyor handling, somewhere.

1/ Are you using any N2K in your code? I could not find ParseN2kPGN129029, No, the 'ParseN2kPGN129029', have no idea where that comes from.

2/ Is there a N2k library that you are using that CMakeLists.txt is missing? I will follow your advise examining the paths defined in CMakeLists.txt. You tried something similar that didn't work, I will test further. But again: why just Windows?

3/ The duplicated wxJSON definitions was required (quick and dirty) to compile on Linux, there must be a path missing for 'libs/wxJSON'. Another reason to review the main CMakeLists.txt. TODO.

4/ The N2KParser was taken from O571 a few months ago, It equals the current version in O58.

Will give the above a shot and see what happens, Getting a bit frustrated.

[rgleason]

I think your point about it working in Linux is good. I think we need someone with more experience with the N2K Parser to look at this.

The "ParseN2kPNG129029" error is apparently from the N2kParser folder.

No sense in getting frustrated.

[LennartG-Sve]

Rick, updated this: 1/ In OCPNHDRS I've now removed 'ocpninclude/ocpn_plugin.h', it is a part of the 'ocpn-api' functionality and located there. It did not exist but why no 'missing' error message, it was not there?

2/ Removed the duplicate (there were actually more) including the whole LIBSSRC definition and corresponding src library. That also involved a few more corrections.

3/ Restored appveyor.yml to the original.

The local compile now runs on my ubuntu 20.04 and O 5.8. I also uploaded to git and compiled beta for build-focal-gtk3 without problems.

Then started an AppVeyor compile getting the same error as before for both VS2017 and VS2022.

[bdbcat]

Where is a most, most recent Appveyor build log, please?

[LennartG-Sve]

This is for VS2022: Appveyor-build.log.zip

[bdbcat]

First, I would just comment out all the N2K stuff in your source, and try to get a clean build

[LennartG-Sve]

Rick and eventually bdbcat, Removed the NMEA2000 stuff and compiled ok on Linux but: Now I have a 'TexFont.obj : error LNK2019: unresolved external symbol', note: TexFont, not TextFont. Both are used at various places in the program and Linux accepts it. 1/ Could this be related to the error you, Rick, see on high res screens? 2/ Rick please compile locally to verify the result. 3/ This is the same type of error ('error LNK2019: unresolved external symbol') that we had for NMEA2000. Something wrong/missing in 'libs/ocpn-api/CMakeLists.txt' or appveyor.yml? Attached the latest log file.

VS2022_build_noNMEA2000.log.zip

[LennartG-Sve]

Rick and eventually bdbcat, looking closer at the two previous error log files and compare reveals that the 'TexFont.obj : error LNK2019: unresolved external symbol' error' has been there all the time. The 'ParseN2kPGN129029' was just an extra line that happened to come ahead of the other messages. Still trying to look for the cause ...... nothing found yet. And why Windows and not Linux?

[rgleason]

'TexFont.obj : error LNK2019: unresolved external symbol', note: TexFont, not TextFont

Lennart
texfont.h is located in ocpninclude Texfont.cpp is located in ocpnsrc

Did those get changed from what you had originally?
Sometimes if you change them to what testplugin uses, it screws up the builds.

[LennartG-Sve]

Rick, I've compared my files/filenames to what is in testplugin v130 and they are alike. TexFont.h in ocpninclude and TexFont.cpp in ocpnsrc. None of them has been changed. The difference to what I've done earlier is that I then only updated a limited set of files between TP versions (like .circleci, api-16, buildosx, buildwin, ci, cmake, mingw, .travis.yml and appveyor.yml) but for 230 I decided to be more thorough. Now I have been . . . . , this is what I got.

[jongough]

The opencpn.lib file is downloaded in the appveyor.yml file as part of the before build processing. In V1.0.230.0 this is on line 79 for both windows builds as it is common.

Testplugin_pi is the run-able plugin for testing ODraw and is also used to develop FE2. If you are using v1.0.230.0 you need to have all the files that are mentioned in the CMakeLists.txt file and their supporting directory structures. All FE2 does is provide the build skeleton for circleci and appveyor. It does not include all the items that a particular plugin may require, but it should point out where to put these items. It looks like there may be an issue with the setup of FE2 for building with windows as you say the linux builds work OK. Do the macOS builds work?

The controller for windows build in FE2 is the appveyor.yml file which sets up the prerequisites for the windows build, including downloading the opencpn.lib file.

If you want to try out a local build you will need to have a windows environment available (I use a win10 VM running on qemu/kvm, but it should work on any win10 environment which you have sufficient (admin?) rights too). You will need VS2017 & VS2022 installed, then run each of the items in the particular version you want to build from at a standard command prompt within your project. Don't try to use a VS command prompt as it seems to be variable as to the results returned, not sure why, but.....

FE2 does not attempt to include all possibilities for all plugins. That, I am afraid, is down to the plugin developer as they know what is needed for their plugin.

Which branch from which git repository are you trying to build the plugin? If I can get a look at it I might be able to try it on my system?

[LennartG-Sve]

Jon, thank you for the reply. 1/ All linux variants in .circleci as well as macos compiles ok whenever I compiled the full set (but jammy). Lately I've disabled all but focal, this to save compiler time. 2/ I don't have a Windows system allowing me to compile Windows locally but compiling locally on ubuntu 20.04 works just fine. Rick compiled locally on Windows getting the same error as I'm getting when compiling thru AppVeyor, 3/ The code is at https://github.com/LennartG-Sve/GPS-Odometer_pi.

I've looked a bit further comparing the errors with the code and it points towards 'TexFont.h' and the 'public' section where 'void GetTextExtent' appears to be the culprit. Suspect that 'wxString $string' is not resolved somehow but this is far above my knowledge level. A wild and totally uneducated guess though.

[jongough]

I have had a quick look and tried a windows build. It would appear that you still have some testplugin_pi code being executed, in particular, tpdc.cpp. This uses TexFont. If you remove that (and any other unneeded parts of testplugin_pi code) you may get a build that works.

[jongough]

Just managed to get a windows build completed, cannot test for run at the moment. I had to comment out "ocpnsrc/TexFont.cpp" and "ocpninclude/TexFont.h" in the CMakeLists.txt file. Give that a go and see if it works in appveyor.

[LennartG-Sve]

Jon, that worked, thanks! It however failed in build-focal in what looked like a timeout or connection problem: 'Failed to fetch http://archive.ubuntu.com/ubuntu/pool......'. Not my problem and it compiled on locally on focal.

Are there other files I can remove? Thinking about all 'tp*' and 'testplugin.** plus maybe more from testplugin not required for FE2.

Next I'll remove the out-comments for NMEA2000 (socketCAN) and try again. If that works it should then be ready for O58 supporting Win7 and later, Linux and MacOS. Have not implemented Android.