Avoid crashes related to non-GL mode on macOS

[nohal]

On macOS, any OpenGL call made without the GL subsystem properly initialized leads to crash.
Part of the problem is fixed in opencpn-libs, hence the update.

[rgleason]

Ok, so this means every plugin's opencpn-lib needs to be updated at some point.
At what point?
Must opencpn-lib be updated now if recompiled?

[jongough]

Have the opencpn-libs changes been committed and accepted on the OCPN mainline?

[nohal]

OpenCPN/opencpn-libs@1a6c1a7

[jongough]

It appears that this version of opencpn-libs has not been fully released to all platforms. OD had an issue raised that a raspberry pi failed to draw items when using the new version of OD. Reverting to the previous version worked OK. To help the users I have put back the 1.8.46.0 version whilst also leaving the 1.8.49.0 version which has this change incorporated.

It looks like there needs to be some 'version' checking in the plugin manager to ensure that a plugin is not installable if the version of opencpn-libs is older than the one the plugin is trying to use.

[nohal]

I do not understand what you mean. What is it "fully releasing opencn-libs"? It is a git project included as a submodule. What exactly happened and did not work?

[jongough]

I have had an issue raised on OD, #549, where the newer version of OD does not work, or draw, on a raspberry pi using OCPN 5.8.4, which is the latest version. As the previous version of OD works and the only changes were for macOS and the inclusion of opencpn-libs, it would appear that opencpn-libs included with OCPN may not be fully compatible with the version that OD 1.8.49.0 was built against.

[rgleason]

I have has some reports about a TP plugin no longer working on RPI

[jongough]

The solution I had were to backlevel ODraw and it all worked again. I can only assume that as ODraw was built against the updated version of opencpn-libs for the macOS change that this version of opencpn-libs had not made it into the current version of OCPN for the raspberry pi. I hope this is just a one off issue, if not then there will need to be a mechanism to determine if the version of opencpn-libs is compatible with the version being used by the plugin. This would have to be done by the pluginmanager and an extension of the xml used.