Re: [Hamlib-developer] WSJT-X build error with latest hamlib version

[Uwe, D. <dg...@gm...>]

Hi Nate,

Yes, that broke it. According to my tests, changing “gcc-mingw” to “gcc” 
is sufficient to get it back working. It would be great if you could 
change your build scripts accordingly. Otherwise, we would have to see 
if we can add an exception rule for this in our file FindHamlib.cmake.

Meanwhile, Roger has found a solution for line 336 of our 
HamlibTransceiver.cpp module. With this, WSJT-X compiles correctly again 
on both Linux and Windows, at least for me. Let's see if it is backward 
compatible with the older hamlib versions.

These two measures could therefore solve the problem. However, we still 
need to test all of this on the many other operating systems (and also 
with Qt6). Not that it still causes problems somewhere.

In any case, thanks for your help and efforts!

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 23:39 schrieb Nate Bargmann:
> I just double-checked and compared the Windows binary archives between
> the 4.6.4 release and 4.7~git.
>
> The only changes are:
>
> ~/tmp/hamlib-w64-4.6.4
> $ tree lib/
> lib/
> ├── gcc
> │   └── libhamlib.dll.a
> └── msvc
>      ├── libhamlib-4.def
>      └── libhamlib-4.lib
>
> 3 directories, 3 files
>
>
> ~/tmp/hamlib-w64-4.7~git
> $ tree lib/
> lib/
> ├── gcc-mingw
> │   ├── libhamlib-4.lib
> │   └── libhamlib.dll.a
> └── msvc
>      └── libhamlib-4.def
>
> 3 directories, 3 files
>
> If this is where the issue lies it should be possible to direct the
> build system to try one and then the other.  If this is not the issue,
> then I am at a loss at the moment.
>
> 73, Nate
>