[Hamlib-developer] WSJT-X build error with latest hamlib version
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
[Hamlib-developer] WSJT-X build error with latest hamlib version
|
From: Uwe, D. <dg...@gm...> - 2025-08-03 18:56:50
|
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
>
|
