Hi Mike,
I am not sure I see the significant difference between "readonly" and
"never modified" in respect to this conversation. Anything that relies
on offsets within an aggregate type like a C struct that is visible to a
library client is part of the pubic API. As such those offsets cannot
change without that change being a breaking change to the API. You can
have such data structures in a public API, although it is not
recommended, so long as breaking changes are suitable protected by some
sort of versioning like an incrementing numbering in an SONAME shared
object header.
There is quite a long list of struct field references in the WSJT-X
Hamlib client code, I would welcome eliminating them by replacing with
suitable API function calls as we would prefer to ship with a
dynamically linked Hamlib if it is safe to to so.
73
Bill
G4WJS.
On 31/12/2020 15:55, Black Michael via wsjt-devel wrote:
"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]> <mailto:[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
