OpenCPN plugin download manager doesn't work properly with arm64 bit kernel and armhf user space

[mgrouch]

Plugin download manager doesn't work properly with arm64 bit kernel and armhf user space.
With arm64 bit kernel and armhf user space it shows no updates available.

It seems it detects architecture based on kernel, which is not correct.
If the user space architecture is armhf all 32-bit updates would be applicable.

Thanks

[leamas]

You are probably right, don't think this usecase has been considered as it should.

Could you please provide the opencpn.log file after starting opencpn with -l debug?

Also: could you test using the OPENCPN_COMPAT_TARGET environment variable to force OpenCPN to use the proper host ABI, overriding the automatic detection? If this is the only problem, using it should walk around the issue.

[mgrouch]

opencpn.log

Here is the log.
arm64 for wxWidgets is wrong. It's armhf userspace

[mgrouch]

OPENCPN_COMPAT_TARGET doesn't seem to help to change it

[leamas]

hm... if that log comment is correct you are actually using a 64-bit binary, right? How come it's even possible to load it in a 32-bit userspace? "Mystified"

[leamas]

hm... what doesfile $(which opencpn)say?

[mgrouch]

it says

file which opencpn
/usr/bin/opencpn: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=678dc05116225f9367412e2dbc08dff4ebed9276, stripped

[leamas]

This is sort of odd, but perhaps unrelated: wxWidgets identifies itself as 64-bit while it obviously is 32-bit. But in the big picture, it should not be blocking, so let's put this aside for now.

And: OPENCPN_COMPAT_TARGET should definitely help in the sense that plugin candidates are listed in the plugins window. The alternative is to use the new Options | Plugins | Settings dialog to force OpenCPN to use another ABI. It requires some fiddling witn opencpn.conf as described when invoking it the first time.

This should definitely present the armhf plugins for you, it does so even on my Fedora/flatpak/x86_64. Does it?

[mgrouch]

What should be the value of that variable. I put flatpak-armhf

…

Sent from my iPhone

On Apr 7, 2021, at 2:16 PM, leamas ***@***.***> wrote:  This is sort of odd, but perhaps unrelated: wxWidgets identifies itself as 64-bit while it obviously is 32-bit. But in the big picture, it should not be blocking, so let's put this aside for now. And: OPENCPN_COMPAT_TARGET should definitely help in the sense that plugin candidates are listed in the plugins window. The alternative is to use the new Options | Plugins | Settings dialog to force OpenCPN to use another ABI. It requires some fiddling witn opencpn.conf as described when invoking it the first time. This should definitely present the armhf plugins for you, it does so even on my Fedora/flatpak/x86_64. Does it? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[leamas]

It's easier if you try Options | Plugins | Settings. Here you can see which values there are plugins for, and how these values look.

IIRC, there are no plugins for flatpak-armhf. There is basically just flatpak/x86_64 actually used + one or two flatpak/aarch64 for test purposes.

[mgrouch]

There is no Options | Plugins | Settings in my OpenCPN

…

Sent from my iPhone

On Apr 7, 2021, at 2:49 PM, leamas ***@***.***> wrote: Options | Plugins | Settings

[leamas]

Right, you are running 5.2.4 as released. Can you build from current master?

[mgrouch]

I could. But I’m building a system for the users who wouldn’t be able to build from the source

…

Sent from my iPhone

On Apr 7, 2021, at 3:15 PM, leamas ***@***.***> wrote:  Right, you are running 5.2.4 as released. Can you build from current master? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[leamas]

Let's face it: as released, 5.2.4 doesn't work on your platform.

[mgrouch]

Works just fine. Just can’t update plugins without weird workaround

…

Sent from my iPhone

On Apr 7, 2021, at 3:24 PM, leamas ***@***.***> wrote:  Let's face it: as released, 5.2.4 doesn't work on your platform. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[leamas]

OK, I meant in this respect...

Probably not the root cause, but still curious about the obviously failed platform detection, as can be seen here

[bdbcat]

Closing, edge case for 5.2.4, resolved in 5.5.0 HEAD