warning about building upon wxgtk3.1.x for linux

[filochard]

Hi

I use to build rpms of OpenCPN

I did this for OpenCPN 5.6.2 and its plugins
Built upon wxgtk3.0 everything works fine

But I found that building upon wxgtk 3.1.5 induces some problems that may appear in the next versions of flatpak builds (with wxgtk 3.1.5)
One plugin needs a patch to be built (Climatology_pi : I provided this patch in github)


I tested the stuff by installing plugins one by one (this is possible with a classical install)
1) When Logbook_pi is installed OpenCPN works but after having activated this plugin the simple fact of clicking on its icon in the icons tray induces a segfault

2) Worse the simple fact of installing the rpm of s63 induces an immediate segfault when launching OpenCPN (installing this plugin should add a line in the plugins tab of OpenCPN settings but something seems to go wrong for this)


The problem of wxgtk 3.1.5 is that it is not retro-compatible with wxgtk3.0
some instructions that worked well for wxgtk need to be rewritten !!!
OpenCPN is not alone to be impacted...

[mgrouch]

Originally Posted by filochard

Hi

I use to build rpms of OpenCPN

I did this for OpenCPN 5.6.2 and its plugins
Built upon wxgtk3.0 everything works fine

But I found that building upon wxgtk 3.1.5 induces some problems that may appear in the next versions of flatpak builds (with wxgtk 3.1.5)
One plugin needs a patch to be built (Climatology_pi : I provided this patch in github)


I tested the stuff by installing plugins one by one (this is possible with a classical install)
1) When Logbook_pi is installed OpenCPN works but after having activated this plugin the simple fact of clicking on its icon in the icons tray induces a segfault

2) Worse the simple fact of installing the rpm of s63 induces an immediate segfault when launching OpenCPN (installing this plugin should add a line in the plugins tab of OpenCPN settings but something seems to go wrong for this)


The problem of wxgtk 3.1.5 is that it is not retro-compatible with wxgtk3.0
some instructions that worked well for wxgtk need to be rewritten !!!
OpenCPN is not alone to be impacted...

WxWidgets will soon release 3.2.0. They already updated main branch and using version 3.2.0 in it. Their roadmap says this July.

[filochard]

Using WxWidgets 3.2.0 to build OpenCPN and its plugins will bring new funny things for several linux softwares...


Switching from WxWidgets 3.0 to 3.1.5 brought already the problems to OpenCPN I'm warning about...
(I asked to other projects to modify their code when we discovered that rebuilding with WxWidgets 3.1.5 caused segfaults when they were OK with WxWidgets 3.0)

[mgrouch]

Originally Posted by filochard

Using WxWidgets 3.2.0 to build OpenCPN and its plugins will bring new funny things for several linux softwares...


Switching from WxWidgets 3.0 to 3.1.5 brought already the problems to OpenCPN I'm warning about...
(I asked to other projects to modify their code when we discovered that rebuilding with WxWidgets 3.1.5 caused segfaults when they were OK with WxWidgets 3.0)

3.1.x is not considered production ready. It shouldn’t be in any stable distribution anyway

[filochard]

Hi mgrough

Wxgtk3.1.x versions are used to detect which problems may appear before wxgtk3.2 is published and used for building programs

It's useful for this : for the wxwidgets devs and for the softwares devs

For my personal stable releases of softwares I remain on wxgtk3.0

that doesn't prevent to test what may happen with the future versions and to inform devs :

the patch for Climatology_pi will be useful for the final release of wxgtk3.2.0 : need to add
include <GL/glx.h> inside ClimatologyOverlayFactory.cpp
so that it can be built !

[bdbcat]

All...
On linux, we cannot reasonably move to wx32 before it is generally available in linux distro repos. We do not want to package wxWidgets with the app, and we (probably) do not want to build and maintain an OCPN-private multi-arch, multi version, repo for wx32 libraries.


On Windows and MacOS, we bundle wxWidgets with the OCPN installer binary. So, we can move to wx32 on the next OCPN major release, if we want. This will, of course, be painful. All plugins must be rebuilt, and tested, for starters.


My opinion: Let's not be too hasty to move to wx32. Let's understand what features were fixed/improved in wx32 that OCPN actually uses. If there are few, and minor, perhaps no immediate update is needed.


Dave

[filochard]

Hi Dave
I agree with your cautious approach

The tests that have been done by myself for OpenCPN and its plugins and by other packagers trying to build some other programs upon wxwidgets 3.1.5 or 3.1.6, and to use them after that , revealed lots of problems..

(We explicitely strictly require wxgtk 3.0 to build and use those programs for stable releases)

I wanted only to ring the bell knowing that wxwidgets 3.2.0 will appear soon, and may motivate to switch to it too quickly (thinking about flatpak for instance)

Let's hope that the 3.0 version may remain beside 3.2.0 in linux distributions

[mgrouch]

https://www.wxwidgets.org/news/2022/...ase-candidate/

wxWidgets 3.2.0 Release Candidate

[BlackSea]

finally, after 9(!) long years, the next stable release



https://wxwidgets.org/news/2022/07/w...final-release/