"readonly" and "never modified" are two different things.
At least in my history if you rely on data structures you don't use shared
libraries....
Hamlib's fault for not providing the needed API which I will fix.
Mike W9MDB
On Thursday, December 31, 2020, 08:43:34 AM CST, Bill Somerville
<[email protected]> wrote:
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
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
