OpenCPN Version 5.7.1 Release Candidate 1 (RC1)

[LonnieTKing]

And, a copy of the logfile is available.

Lonnie

[nohal]

Lonnie...

No need to post this many times. Please check the response in your other thread first.

[Hakan]

LonnieTKing..
Let's start from basics.
You've installed OpenCPN. If you start the program what do you see?

There should be tool icons on the left. Not so?

I screen shot would be nice if possible.

[Gilletarom]

Originally Posted by LonnieTKing

Aloha Gilletarom and Hakan:

The situation is simply this: After initially installing 5.6.2, THERE IS NO WAY to install charts.
There is no way to, via the OpenCPN.org website, to download an older version (thinking there might be an issue with 5.6.2 vs anything earlier) and I stumbled on the 5.7.1 beta.
YES, I DID remove the 5.6.2 before installing the 5.7.1. With 5.7.1, there is no Chart Loader tab available when I run the program.
As I wrote in another post, there is NOTHING in any subfolder of my User's folder Library that holds any Plugin or any Chart.

No Chart, No OpenCPN.

No chartdownloader tab in "Options/Charts/" ? Have you installed the plugin and/or activated it in "Options/Plugins" after updating the "Master" catalog?

[Mattzilla]

Originally Posted by bdbcat

Mattzilla...
What system (Win/Mac, etc) are you running? OpenGL on/off?
Thanks
Dave

Windows 10, open gl enabled.

[bcn]

Originally Posted by Mattzilla

Windows 10, open gl enabled.

On our two W10 systems we see the black outlines as usual...

[Mattzilla]

Originally Posted by bcn

On our two W10 systems we see the black outlines as usual...

I just checked again just now and the icons have now changed since we cruised up the coast. Strange but will take it as a win! I did clear the Open GL cache before we left may have done it?

[Stebra]

Hi all,
I just compiled Beta_5.7.1_RC1B on a Mac with an M2 CPU.

When loading plug-in's there flavour is "Darwin-wx32:11.4".
The architecture is arm64
The architecture of the o-charts plug-in is x86_64
So the load fails see error below.

When using the link to the precompiled version I see there that OpenCPN is compiled in the x86_64 architecture, so then the plug-in's work.

What is the way forward from here? Do I need to compile for x86_64 or will there be plug-in's available in arm64?

10:15:58.507 ERROR dlunix.cpp:120 Failed to load shared library '/Users/steef/Library/Application Support/OpenCPN/Contents/PlugIns/libo-charts_pi.dylib': dlopen(/Users/steef/Library/Application Support/OpenCPN/Contents/PlugIns/libo-charts_pi.dylib, 0x0002): tried: '/Users/steef/Library/Application Support/OpenCPN/Contents/PlugIns/libo-charts_pi.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/steef/Library/Application Support/OpenCPN/Contents/PlugIns/libo-charts_pi.dylib' (no such file), '/Users/steef/Library/Application Support/OpenCPN/Contents/PlugIns/libo-charts_pi.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64'))

kind regards,
Steef

[nohal]

ARM64 binary of course needs ARM64 plugins. If you insist on running native build on Apple Silicon, you also need to build all the plugins yourself.
The need to prepare native ARM builds for all the third party plugins is one of the main reasons we are not going to provide the native ARM build for macOS in the upcoming 5.8 release and depend on the integrated x86 emulation, which works without any problems.

[Antipole]

Alec is aware of the need to build x86 plugins on an ARM Mac.
It requires work on ShipDriver but he is busy at present.

Meanwhile, I have to build on an X86 Mac. This splits my work across two systems, which is a hassle and I do not want to take my old X86 Mac to sea.
The only alternative is remote builds but that is tedious and inefficient when debugging.

[nohal]

Tony...
I suppose you can build x86 binaries on ARM macOS setting CMAKE_OSX_ARCHITECTURES to x86_64. It works just fine the other way around. The only problem is the added complexity as you also need to cross-compile the dependencies yourself.

[Stebra]

Originally Posted by nohal

ARM64 binary of course needs ARM64 plugins. If you insist on running native build on Apple Silicon, you also need to build all the plugins yourself.
The need to prepare native ARM builds for all the third party plugins is one of the main reasons we are not going to provide the native ARM build for macOS in the upcoming 5.8 release and depend on the integrated x86 emulation, which works without any problems.

Thanks for the reply. I do know I need to build plug-in's for arm64, but some are not open source like o-charts.
I only use such charts which is an issue at present.

Also the plug-in manager normally checks on the versions of plug-in's like wxWidget versions so that they match. I found it strange that the architecture is not an item in the compatibility check.
Both the arm64 build and the x86_64 build show up as "Darwin-wx32:11.4" in the compatibility setting.

kind regards,
Steef

[nohal]

o-charts plugin is open source. Only the oexserverd and the SG-Lock driver are not, but that is a separate process, so everything will work just fine.

[Stebra]

Originally Posted by nohal

o-charts plugin is open source. Only the oexserverd and the SG-Lock driver are not, but that is a separate process, so everything will work just fine.

Thanks for the info, I wasn't aware.
I got o-chatrs plug-in compiled for arm64, but only the tag v2.0.0.44.
v2.0.0.45 fails on trying to include flatpak which I assume is not possible on MAC.
I left it there since I'm by no means a cmake wizard.

It might be just prejudice but I have the distinct impression that it is a lot faster in zooming in and out then the x86_64 version which was already fast.

[nohal]

Originally Posted by Stebra

It might be just prejudice but I have the distinct impression that it is a lot faster in zooming in and out then the x86_64 version which was already fast.

I would expect the native ARM build to be somewhat faster than x86 running on top of Rosetta, but we simply don't have the manpower to make it happen now. Especially as we don't have the hardware and neither the native CI builders are available yet. But I'm pretty sure it will hapen for the next release after 5.8.