Bill, I just looked at github, and the latest commit was 23 minutes ago... I appreciate your stance w/r/t conflicts, however, uninstalling wsjtx 2.1 resolved issues I was having with SKCClogger and FLDIGI. it may be "rubbish", but using dpkg to remove the .deb published on the Princeton website resulted in the other two softwares behaving as expected, which leads me to the conclusion that your assertion that wsjtx was the cause of the issue being rubbish is, itself, rubbish. Luckily, the installation of the deb for 2.2.1 did not cause the return of the issues I was having. Carry on. 73 de AI8W, Chris
On Sat, Jun 6, 2020, 15:11 Bill Somerville <[email protected]> wrote: > On 06/06/2020 19:55, Topher Petty wrote: > > Out of curiosity, why not list hamlib as a prerequisite and have > > people install it separately, so that those of us that already use it > > and keep it updated don't have duplicated libraries on our systems > > that can potentially cause version conflicts? > > Hamlib has installers for windows and Mac on the git site, iirc.. > > I just tracked down difficulties I was having with SKCClogger and > > FLDIGI to the differing versions of hamlib installed on my system, and > > un-installing wsjtx fixed those other two bits of software... > > Going to bump up to 2.2.1 to test... Crossing my fingers I don't get > > to play "lib track bingo" again. > > > > 73 de AI8W, Chris > > Hi Chris, > > the last release of Hamlib was several Years ago. Although the project > has active development it is rather overdue for a new release. We have > worked with a snapshot of Hamlib, which we would prefer to bundle with > WSJT-X, at least until an official release with support for current rigs > is available. We have over the last several versions included some > patches that were ahead of even the Hamlib master branch, all of those > have been submitted and accepted by the Hamlib developers. We would > either have to deny a lot of users support for their new rigs or ask > them to install versions of Hamlib that may clash with other > appliactions or system installed versions. By static linking Hamlib we > avoid that mess, unfortunately most Linux distributions object to static > linking other projects's libraries so the package maintainers have to > unpick out build scripts to comply. We would gladly revert to having > WSJT-X dynamically link to Hamlib, just like it does with Qt and FFTW3 > but on balance at the moment it is not the best option for users. That > may change soon. > > Note that your assertion that the Hamlib used with WSJT-X might cause > conflicts is rubbish, the WSJT-X exposes nothing from the Hamlib it > uses. There are no version conflicts unless you have messed with our > build scripts. > > 73 > Bill > G4WJS. > > > > _______________________________________________ > 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
