Mike,
what non-optional features only present in libusb 1.0.23 does Hamlib
require? Surely the libusb version present when building can be detected
during configure and the sources adjusted with macros to suit the older
libusb versions? This after all is what the configure phase is all about.
73
Bill
G4WJS.
On 07/09/2021 13:05, Black Michael via wsjt-devel wrote:
USB is one of those technologies that doesn't stand still. Can't help
it if package maintainers are 1.5 years behind the curve.
I simply can't guarantee future compatibility but will try to maintain
it. That's why I put in the testlibusb.c program to catch this type
of thing before it's mandatory and before I implement some things
under libusb.
Hamlib has already been patched to allow this to compile now.
Mike W9MDB
On Tuesday, September 7, 2021, 06:54:24 AM CDT, Claude Frantz via
wsjt-devel <wsjt-devel@lists.sourceforge.net> wrote:
On 9/7/21 12:36 PM, Kari Sillanmäki via wsjt-devel wrote:
Hi Kari, Bill and all,
> I tried to compile WSJT-X 2.5.0-rc6 on XUbuntu 18.04.5 LTS but got an
> error:
> function); did you mean ‘LIBUSB_SPEED_SUPER’?
> case LIBUSB_SPEED_SUPER_PLUS: speed = "10G"; break;
> ^~~~~~~~~~~~~~~~~~~~~~~
> LIBUSB_SPEED_SUPER
> /tests/testlibusb.c:343:2: warning: #warning LIBUSB-1.0.23 will be
> required in Hamlib > 4.3 [-Wcpp]
> #warning LIBUSB-1.0.23 will be required in Hamlib > 4.3
In my opinion, the hamlib code should be changed in order to accept
libusb in older 1.0 releases, while avoiding to include the additional
functionalities provided by 1.0.23. As I can see, many recent
distributions have libusb < 1.0.23.
Best wishes,
Claude (DJ0OT)
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel