|
From: Bill S. <g4...@cl...> - 2020-03-26 14:08:43
|
On 26/03/2020 13:51, Black Michael via wsjt-devel wrote: > What makes you think WSJT-X needs to use the system libraries? > There's no such requirement that I've ever heard of. > WSJT-X is written (as are all applications) to use specific > capabilities in hamlib. > > I'll bet that if you do "ldd wsjtx|grep hamlib" you won't see hamlib > referenced at all...because it's statically linked. > > WSJT-X distributes the complete hamlib utility set with it too. > > Using the 3.3 version is just going to result in you getting lots of > complaints about bug and rigs that aren't implemented or don't work. > > We have finally cleared up all known bugs in hamlib and found a bunch > more through the use of static analysis tools. > > de Mike W9MDB Mike, Linux distributions have rules about what can be submitted as a package. Individual users can choose to build however they like but package maintainers have to follow the rules and guidelines that the distributions require. As Christoph points out there are issues even when statically linking packages, particularly in how to apply security patches that may appear post release of the underlying package. The WSJT-X upstream tarball does provide a mechanism for applying patches to both WSJT-X and the bundled Hamlib but discovering those patches and applying them becomes the responsibility of individual package maintainers. OTOH if WSJT-X were to dynamically link the child package then only the package maintainer of child package needs to deal with tracking security and other critical patches. This is tricky area, even if there were many more Hamlib releases it is still hard to get the latest rig support. I have long had plans to move to dynamic linking of Hamlib by WSJT-X but TBH Hamlib has not been stable enough or up to date enough in release form just yet. Let's hope that Hamlib 4, probably 4.1, allows that to happen without depriving too many users of support for rigs coming to the market soon. 73 Bill G4WJS. |