Mike,
you can;t say that when there re comments in the current public API
headers like this:
* The main idea of this struct is that it will be defined by the backend rig
* driver, and will remain *readonly* for the application. Fields that need to
* be modifiable by the application are copied into the struct rig_state,
* which is a kind of private storage of the RIG instance.
my emphasis. The issue is not with the clients it lies firmly in the
court of the library developers.
73
Bill
G4WJS.
On 31/12/2020 14:32, Black Michael via wsjt-devel wrote:
I don't believe that solves the problem.
If one refers to data structures in code you can't rely on shared
libraries. You need to stick to the API.
Mike W9MDB
On Thursday, December 31, 2020, 08:30:04 AM CST, Christoph Berg
<[email protected]> wrote:
Re: Black Michael via wsjt-devel
> Seems we had a problem on Linux WSJT-X builds as they are using the
hamlib shared library instead of static build.I've already recommended
they switch to static.
> The problem crept up where one version of hamlib worked but another
was getting the wrong value for rig->caps->vfo_list since the caps
structure had changed.
Hamlib needs a SONAME bump each time any user-visible data structures
or functions change or disappear.
Christoph
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
