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
"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
On 31/12/2020 14:42, Christoph Berg wrote:
Re: Bill Somerville
that's a really bad solution to this issue given the frequency of Hamlib
releases.
Well the obvious fix here is to actually create hamlib releases:)
Christoph
Hi Christoph,
not disagreeing with you there but fixing a broken
Mike and Christoph,
note that I pointed out this poor API design feature long ago but it
seems little has been done to rectify the problem:
https://sourceforge.net/p/hamlib/mailman/message/36503857/
73
Bill
G4WJS.
On 31/12/2020 14:39, Bill Somerville wrote:
Mike,
you can;t say that when
Re: Bill Somerville
> It would be far better to remove any declarations like structs
> from the public API so that nothing depends on offsets of fields being
> constant between releases. Your suggestion would make many minor releases
> breaking API changes when that's not really necessary. And yes
Re: Bill Somerville
> that's a really bad solution to this issue given the frequency of Hamlib
> releases.
Well the obvious fix here is to actually create hamlib releases :)
Christoph
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
Re: Black Michael
> 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.
If you are referring to source-level API compatibility that is true (I
was referring to ABI changes), but if you are
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
On 31/12/2020 14:29, Christoph Berg 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
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
wrote:
Re: Black Michael via wsjt-devel
> Seems we had a
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
On 31/12/2020 14:12, Black Michael via wsjt-devel wrote:
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
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
13 matches
Mail list logo
