Re: [Hamlib-developer] WSJT-X build error with latest hamlib version
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
Re: [Hamlib-developer] WSJT-X build error with latest hamlib version
|
From: George B. <geo...@gm...> - 2025-08-03 20:30:22
|
What error did you get when changing rig_get_conf to rig_get_conf2?
rig_get_conf() has a serious problem in that it does no checking on the
length of the output - rig_get_conf2 adds the length of the output
buffer to the parameter list so no overrun. It was added by Mike B. in
Jan 2022, so I hope everyone has it by now.
73 n3gb
On 8/3/25 2:56 PM, Uwe, DG2YCB wrote:
> Hi Nate, George, Roger and all,
>
> Okay, let me summarize again the current situation:
> Today I noticed that the latest *Hamlib v4.7 is no longer* (fully)
> *compatible with WSJT-X*. *This is a severe issue* for us, especially
> since a new v3.0.0 is planned soon! The problems result from the
> following two changes in Hamlib:
>
> *1. Hamlib commit 20eeb96:*
> These changes lead to an incompatibility with WSJTX module
> HamlibTransceiver.cpp. On my Linux MInt 22.1 machine, it leads to the
> following compilation error:
> [ 82%] Built target jt9
> [ 82%] Building CXX object
> CMakeFiles/wsjt_qt.dir/Transceiver/HamlibTransceiver.cpp.o
> /home/uwe/jt/wsjtx/Transceiver/HamlibTransceiver.cpp: In member
> function ‘QByteArray HamlibTransceiver::impl::get_conf(const char*)’:
> /home/uwe/jt/wsjtx/Transceiver/HamlibTransceiver.cpp:336:33: error:
> ‘int rig_get_conf(RIG*, hamlib_token_t, char*)’ is deprecated
> [-Werror=deprecated-declarations]
> 336 | error_check (rig_get_conf (rig_.data (), token,
> value.data ()), tr ("getting a configuration item"));
> | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from
> /home/uwe/jt/wsjtx/Transceiver/HamlibTransceiver.cpp:15:
> /home/uwe/jt/hamlib/include/hamlib/rig.h:2971:1: note: declared here
> 2971 | rig_get_conf HAMLIB_PARAMS((RIG *rig,
> | ^~~~~~~~~~~~
> Changing rig_get_conf to rig_get_conf2 in HamlibTransceiver.cpp
> doesn't fix it, and changing the entire code would lead to loosing
> backwards compatibility. Keep in mind, that it must also work with
> macOS, Raspberry Pi 32-bit/64-bit, etc., and that not all these
> systems offer the latest hamlib versions. Thus, loosing backwards
> compatibility would end up in a mess!
>
> Compilation worked when I disabled the (red) line 336 in
> HamlibTransceiver.cpp, however, at best, it's a poor workaround. And
> who knows how it will behave on other operating systems when this line
> is disabled.
> QByteArray HamlibTransceiver::impl::get_conf (char const * item)
> {
> token_t token = rig_token_lookup (rig_.data (), item);
> QByteArray value {128, '\0'};
> if (RIG_CONF_END != token) // only get if valid for rig model
> {
> // error_check (rig_get_conf (rig_.data (), token, value.data
> ()), tr ("getting a configuration item"));
> }
> return value;
> }
> *
> 2. Nate's changes to his build environment.*
> Over the past few years, I have always used the binaries from
> https://n0nb.users.sourceforge.net/ to create the official Windows
> packages for WSJT-X and WSJT-X Improved. However, this no longer works
> because Hamlib can no longer be found with the module provided for
> this purpose in WSJT-X (/CMake/Modules/FindHamlib.cmake). That's very
> bad! All works well immediately if I go back to Hamlib 4.6.3.
> CMake Error at CMake/Modules/LibFindMacros.cmake:263 (message):
> REQUIRED PACKAGE NOT FOUND
>
> We only found some files of Hamlib, not all of them. Perhaps your
> installation is incomplete or maybe we just didn't look in the right
> place?
> This package is REQUIRED and you need to install it or adjust CMake
> configuration in order to continue building wsjtx.
>
> Relevant CMake configuration variables:
>
> Hamlib_INCLUDE_DIR=C:/JTSDK64-Tools/tools/hamlib/qt/5.12.12/include
> Usb_INCLUDE_DIR=C:/JTSDK64-Tools/tools/libusb/1.0.24/include/libusb-1.0
> Hamlib_LIBRARY=<not found>
> Usb_LIBRARY=C:/JTSDK64-Tools/tools/hamlib/qt/5.12.12/bin/libusb-1.0.dll
>
> You may use CMake GUI, cmake -D or ccmake to modify the values. Delete
> CMakeCache.txt to discard all values and force full re-detection if
> necessary.
>
> Call Stack (most recent call first):
> CMake/Modules/FindHamlib.cmake:23 (libfind_process)
> CMakeLists.txt:1009 (find_package)
>
> But also here: Any changes to the code used for years in WSJT-X will
> most likely lead to chaos, because of the many OS and GCC versions the
> users have, if we loose backwards compatibility.
>
> For testing purposes, I just compiled 64-bit binaries of the latest
> Hamlib source code myself using the JTDSK64 kit. This worked and I was
> able to compile WSJT-X 3.0.0 with it on Windows. At least that's
> something. Strangely enough, the compilation error I encountered with
> Linux did not occur there. But that shows us how different it can be.
> I don't want to be confronted with hundreds of complaints from all
> those people with their various RPi OSs or the different x86_64 or
> M1/M2/M3 variants of macOS!
> But I also need 32-bit binaries for the 32-bit versions of WSJT-X and
> WSJT-X Improved. Unfortunately, compiling with my JTSDK always leads
> to errors when trying to compile 32-bit Hamlib binaries. It was so
> nice that we could always use the reliable binaries from the
> https://n0nb.users.sourceforge.net/ site. It would be very
> disappointing if that were no longer possible in the future. This
> complicates every new version of WSJT-X.
>
> *I sincerely hope that solutions can be found for the problems
> identified.* I would really regret it if Hamlib were no longer
> considered reliable enough in the future. Then we would have to
> completely change course for WSJT-X in the long term when it comes to
> CAT control.
>
> I would also greatly appreciate it if such serious changes in Hamlib
> were coordinated with us WSJT-X developers beforehand. The repeated
> Hamlib problems of recent years have already severely damaged its
> reputation in the eyes of many. Of course, we always tried to argue it
> away objectively. Unfortunately, there are few to no alternatives on
> Linux and macOS. Therefore, I repeat my request: Please resolve these
> issues so that WSJT-X can continue to use Hamlib for CAT control of
> the rigs in the future.
>
> 73 de DG2YCB,
> Uwe
> ________________________________________
> German Amateur Radio Station DG2YCB
> Dr. Uwe Risse
> eMail: dg...@gm...
> Info: www.qrz.com/db/DG2YCB
>
>
> Am 03.08.2025 um 19:24 schrieb Nate Bargmann:
>> * On 2025 03 Aug 08:01 -0500, DG2YCB, Uwe wrote:
>>> Hi Roger, hi Nate,
>>>
>>> I have just tried to build WSJT-X on Linux with the latest Hamlib version
>>> 4.7~git-20250803-989623ec5, but it resulted in the build error listed below.
>>> It builds fine with Hamlib 4.6.3. Any idea where this new compilation error
>>> comes from?
>>>
>>> @Nate: Has anything been changed in Hamlib in this regard? Because we don't
>>> have anything changed in our WSJT-X code regarding Hamlib.
>> Yes, this commit by George:
>>
>> https://github.com/Hamlib/Hamlib/commit/20eeb96787a1e2dd67e158b52337f64ab47517e7
>>
>> This is in reference to Issue #924
>>
>> https://github.com/Hamlib/Hamlib/issues/924
>>
>>
>> Finally, please do not email me only on questions like these. Such
>> questions should be posted toh...@li...
>> that way all developers can be involved. Unfortunately, I now have a
>> long thread in my mail box with questions I'm unable to answer directly
>> so get get suitable answers this should be reposted to our mailing list.
>>
>> Thank you.
>>
>> 73, Nate
>>
> |
