wsjt-devel — WSJT software development

[wsjt-devel] WSJTX installation issues under Trixie (ARM64)

[Scott <ss...@pt...>]

I upgraded to Trixie on my Pi4 and am attempting to install the installation package 2.7.1. 
 
Aside from a few overwrite issues I overcame, the install terminates looking for packages libboost-log, -filesystem, and –thread.  Specifically, the installation is looking for versions 1.74 of each but not finding any version of them.
 
To address this, I ran commands sudo apt install libboost-log, sudo apt install libboost-filesystem, and sudo apt install libboost-thread.  For each command, Trixie informed me that the latest version of the respective package was installed and the most up-to-date: libbost-log1.83.0.2+b2, libboost-filesystem1.83.02+b2, and libboost-thread1.83.0.2+b2.  So, while Trixie says they exist, wsjtx is unable to find any. 
 
Trying 2.6.0 results in the same failure.
 
Does anyone have a suggestion on how to overcome this?
 
73 W3WT
 

Re: [wsjt-devel] decoder.f90 executable stack

[Brian M. <bri...@gm...>]

Hi Roger, did you mean to send this to Brian Morrison instead of me?
Though it's nice to see some WSJT-X related emails, the first in a long
time.


On Wed, Nov 12, 2025 at 1:14 PM Roger Rehr via wsjt-devel <
wsj...@li...> wrote:

> HI Brian,
>
> If you didn't get this fixed,  then try substituting the following code
> for the "# Fortran setup" block in CMakeLists.txt in the main source
> directory.  If you try that please let me know whether or not it solves
> your issue.  If so, we'll add the change to the official code.  If not,
> I have a more complicated (and therefore less desirable) fix that could
> be done.
>
> Thanks and 73,
>
> Roger
> W3SZ
>
> --------------------
>
> #
> # Fortran setup
> #
> set (General_FFLAGS "-Wall -Wno-conversion -Wno-c-binding-type
> -fno-second-underscore")
>
> # FFLAGS depend on the compiler
> get_filename_component (Fortran_COMPILER_NAME ${CMAKE_Fortran_COMPILER}
> NAME)
>
> if (Fortran_COMPILER_NAME MATCHES "gfortran.*")
>    # gfortran-specific flags
>
>    if (CMAKE_OSX_DEPLOYMENT_TARGET)
>      set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS}
> -mmacosx-version-min=${CMAKE_OSX_DEPLOYMENT_TARGET}")
>    endif()
>
>    if (CMAKE_OSX_SYSROOT)
>      set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -isysroot
> ${CMAKE_OSX_SYSROOT}")
>    endif()
>
>    # Add assembler flag to disable executable stack
>    if (UNIX AND Fortran_COMPILER_NAME MATCHES "gfortran.*")
>      set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -Wa,--noexecstack")
>    endif()
>
>    set(CMAKE_Fortran_FLAGS_RELEASE "${CMAKE_Fortran_FLAGS_RELEASE}
> -fbounds-check -funroll-all-loops -fno-f2c
> -ffpe-summary=invalid,zero,overflow,underflow ${General_FFLAGS}")
>    set(CMAKE_Fortran_FLAGS_DEBUG   "${CMAKE_Fortran_FLAGS_DEBUG} -ggdb
> -O0 -fbacktrace -fcheck=all -fbounds-check -fno-f2c
> -ffpe-summary=invalid,zero,overflow,underflow ${General_FFLAGS}")
>
>    # FPE traps currently disabled in Debug configuration builds until
>    # we decide if they are meaningful, without these FP instructions
>    # run in nonstop mode and do not trap
>    #set (CMAKE_Fortran_FLAGS_DEBUG   "${CMAKE_Fortran_FLAGS_DEBUG}
> ${CMAKE_Fortran_FLAGS_DEBUG}  -ffpe-trap=invalid,zero,overflow")
>
> elseif (Fortran_COMPILER_NAME MATCHES "ifort.*")
>    # Intel Fortran
>    set(CMAKE_Fortran_FLAGS_RELEASE "${CMAKE_Fortran_FLAGS_RELEASE}
> -f77rtl ${General_FFLAGS}")
>    set(CMAKE_Fortran_FLAGS_DEBUG   "${CMAKE_Fortran_FLAGS_DEBUG} -f77rtl
> ${General_FFLAGS}")
>
> elseif (Fortran_COMPILER_NAME MATCHES "g77")
>    # g77
>    set(CMAKE_Fortran_FLAGS_RELEASE "${CMAKE_Fortran_FLAGS_RELEASE}
> -funroll-all-loops -fno-f2c -m32 ${General_FFLAGS}")
>    set(CMAKE_Fortran_FLAGS_DEBUG   "${CMAKE_Fortran_FLAGS_DEBUG}
> -fbounds-check -fno-f2c -m32 ${General_FFLAGS}")
>
> else()
>    message("CMAKE_Fortran_COMPILER full path: ${CMAKE_Fortran_COMPILER}")
>    message("Fortran compiler: ${Fortran_COMPILER_NAME}")
>    message("No optimized Fortran compiler flags are known, we just try
> -O3...")
>    set(CMAKE_Fortran_FLAGS_RELEASE "${CMAKE_Fortran_FLAGS_RELEASE} -O3
> ${General_FFLAGS}")
>    set(CMAKE_Fortran_FLAGS_DEBUG   "${CMAKE_Fortran_FLAGS_DEBUG} -g
> -fbacktrace -fcheck=all -fbounds-check ${General_FFLAGS}")
> endif()
>
> --------------------
>
> On 11/3/2025 8:03 AM, Brian Morrison via wsjt-devel wrote:
> > On Mon, 13 Oct 2025 18:16:48 +0200
> > Jaroslav Škarvada via wsjt-devel <wsj...@li...>
> > wrote:
> >
> >> Hi,
> >>
> >> linux distros are trying to harden with the noexecstack and the
> >> execstack in decoder.f90 is causing problems. E.g. [1], [2]. It seems
> >> the g++ linker doesn't allow combination of binaries with exec/noexec
> >> stacks [1], so the whole binary needs to be compiled with the
> >> execstack which may be unacceptable for some distros. The patch
> >> proposed in [1] uses mprotect, should something similar be upstreamed?
> >>
> >> Build failure of wsjtx-2.7.0 with the gcc-c++-15.2.1 in Fedora
> >> rawhide: [81%] Building Fortran object
> >> qmap/libqmap/CMakeFiles/qmap_impl.dir/f77_wisdom.f.o
> >> cd
> >>
> /builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build/qmap/libqmap
> >> && /usr/bin/gfortran -DBIGSYM=1 -DBOOST_ALL_DYN_LINK
> >> -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CHRONO_DYN_LINK
> >> -DBOOST_CHRONO_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK
> >> -DBOOST_FILESYSTEM_NO_LIB -DBOOST_LOG_DYN_LINK -DBOOST_LOG_NO_LIB
> >> -DBOOST_LOG_SETUP_DYN_LINK -DBOOST_LOG_SETUP_NO_LIB
> >> -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_THREAD_DYN_LINK
> >> -DBOOST_THREAD_NO_LIB -DCMAKE_BUILD -DFOX_OTP -DQT5 -DQT_CORE_LIB
> >> -DQT_NO_DEBUG -DUNIX
> >>
> -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build/qmap/libqmap
> >> -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/qmap/libqmap
> >>
> -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build/qmap/libqmap/qmap_impl_autogen/include
> >>
> -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build
> >> -I/usr/include -I/usr/include/qt5 -I/usr/include/qt5/QtCore
> >> -I/usr/lib64/qt5/mkspecs/linux-g++ -O2  -fexceptions -g
> >> -grecord-gcc-switches -pipe -Wall
> >> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
> >> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> >> -fstack-protector-strong
> >> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
> >> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> >> -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
> >> -mno-omit-leaf-frame-pointer -I/usr/lib64/gfortran/modules -DNDEBUG
> >> -fbounds-check -funroll-all-loops -fno-f2c
> >> -ffpe-summary=invalid,zero,overflow,underflow -Wall -Wno-conversion
> >> -fno-second-underscore -fvisibility=hidden -fPIC -c
> >>
> /builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/qmap/libqmap/f77_wisdom.f
> >> -o CMakeFiles/qmap_impl.dir/f77_wisdom.f.o [ 81%] Linking CXX
> >> executable ldpcsim240_74 /usr/bin/cmake -E cmake_link_script
> >> CMakeFiles/ldpcsim240_74.dir/link.txt --verbose=1
> >> /usr/bin/ld: error: decoder.f90.o: is triggering the generation of an
> >> executable stack (because it has an executable .note.GNU-stack
> >> section)
> >> /usr/bin/ld: failed to set dynamic section sizes: no error
> >> collect2: error: ld returned 1 exit status
> >>
> >> thanks & regards
> >>
> >> Jaroslav
> >>
> >> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278939
> >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2385733
> > Any update on this Jaroslav, or indeed anyone else? It's a bit of a
> > nightmare in Fedora at least.
> >
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] decoder.f90 executable stack

[Roger R. <w3...@co...>]

HI Brian,

If you didn't get this fixed,  then try substituting the following code 
for the "# Fortran setup" block in CMakeLists.txt in the main source 
directory.  If you try that please let me know whether or not it solves 
your issue.  If so, we'll add the change to the official code.  If not, 
I have a more complicated (and therefore less desirable) fix that could 
be done.

Thanks and 73,

Roger
W3SZ

--------------------

#
# Fortran setup
#
set (General_FFLAGS "-Wall -Wno-conversion -Wno-c-binding-type 
-fno-second-underscore")

# FFLAGS depend on the compiler
get_filename_component (Fortran_COMPILER_NAME ${CMAKE_Fortran_COMPILER} 
NAME)

if (Fortran_COMPILER_NAME MATCHES "gfortran.*")
   # gfortran-specific flags

   if (CMAKE_OSX_DEPLOYMENT_TARGET)
     set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} 
-mmacosx-version-min=${CMAKE_OSX_DEPLOYMENT_TARGET}")
   endif()

   if (CMAKE_OSX_SYSROOT)
     set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -isysroot 
${CMAKE_OSX_SYSROOT}")
   endif()

   # Add assembler flag to disable executable stack
   if (UNIX AND Fortran_COMPILER_NAME MATCHES "gfortran.*")
     set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -Wa,--noexecstack")
   endif()

   set(CMAKE_Fortran_FLAGS_RELEASE "${CMAKE_Fortran_FLAGS_RELEASE} 
-fbounds-check -funroll-all-loops -fno-f2c 
-ffpe-summary=invalid,zero,overflow,underflow ${General_FFLAGS}")
   set(CMAKE_Fortran_FLAGS_DEBUG   "${CMAKE_Fortran_FLAGS_DEBUG} -ggdb 
-O0 -fbacktrace -fcheck=all -fbounds-check -fno-f2c 
-ffpe-summary=invalid,zero,overflow,underflow ${General_FFLAGS}")

   # FPE traps currently disabled in Debug configuration builds until
   # we decide if they are meaningful, without these FP instructions
   # run in nonstop mode and do not trap
   #set (CMAKE_Fortran_FLAGS_DEBUG   "${CMAKE_Fortran_FLAGS_DEBUG} 
${CMAKE_Fortran_FLAGS_DEBUG}  -ffpe-trap=invalid,zero,overflow")

elseif (Fortran_COMPILER_NAME MATCHES "ifort.*")
   # Intel Fortran
   set(CMAKE_Fortran_FLAGS_RELEASE "${CMAKE_Fortran_FLAGS_RELEASE} 
-f77rtl ${General_FFLAGS}")
   set(CMAKE_Fortran_FLAGS_DEBUG   "${CMAKE_Fortran_FLAGS_DEBUG} -f77rtl 
${General_FFLAGS}")

elseif (Fortran_COMPILER_NAME MATCHES "g77")
   # g77
   set(CMAKE_Fortran_FLAGS_RELEASE "${CMAKE_Fortran_FLAGS_RELEASE} 
-funroll-all-loops -fno-f2c -m32 ${General_FFLAGS}")
   set(CMAKE_Fortran_FLAGS_DEBUG   "${CMAKE_Fortran_FLAGS_DEBUG} 
-fbounds-check -fno-f2c -m32 ${General_FFLAGS}")

else()
   message("CMAKE_Fortran_COMPILER full path: ${CMAKE_Fortran_COMPILER}")
   message("Fortran compiler: ${Fortran_COMPILER_NAME}")
   message("No optimized Fortran compiler flags are known, we just try 
-O3...")
   set(CMAKE_Fortran_FLAGS_RELEASE "${CMAKE_Fortran_FLAGS_RELEASE} -O3 
${General_FFLAGS}")
   set(CMAKE_Fortran_FLAGS_DEBUG   "${CMAKE_Fortran_FLAGS_DEBUG} -g 
-fbacktrace -fcheck=all -fbounds-check ${General_FFLAGS}")
endif()

--------------------

On 11/3/2025 8:03 AM, Brian Morrison via wsjt-devel wrote:
> On Mon, 13 Oct 2025 18:16:48 +0200
> Jaroslav Škarvada via wsjt-devel <wsj...@li...>
> wrote:
>
>> Hi,
>>
>> linux distros are trying to harden with the noexecstack and the
>> execstack in decoder.f90 is causing problems. E.g. [1], [2]. It seems
>> the g++ linker doesn't allow combination of binaries with exec/noexec
>> stacks [1], so the whole binary needs to be compiled with the
>> execstack which may be unacceptable for some distros. The patch
>> proposed in [1] uses mprotect, should something similar be upstreamed?
>>
>> Build failure of wsjtx-2.7.0 with the gcc-c++-15.2.1 in Fedora
>> rawhide: [81%] Building Fortran object
>> qmap/libqmap/CMakeFiles/qmap_impl.dir/f77_wisdom.f.o
>> cd
>> /builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build/qmap/libqmap
>> && /usr/bin/gfortran -DBIGSYM=1 -DBOOST_ALL_DYN_LINK
>> -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CHRONO_DYN_LINK
>> -DBOOST_CHRONO_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK
>> -DBOOST_FILESYSTEM_NO_LIB -DBOOST_LOG_DYN_LINK -DBOOST_LOG_NO_LIB
>> -DBOOST_LOG_SETUP_DYN_LINK -DBOOST_LOG_SETUP_NO_LIB
>> -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_THREAD_DYN_LINK
>> -DBOOST_THREAD_NO_LIB -DCMAKE_BUILD -DFOX_OTP -DQT5 -DQT_CORE_LIB
>> -DQT_NO_DEBUG -DUNIX
>> -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build/qmap/libqmap
>> -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/qmap/libqmap
>> -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build/qmap/libqmap/qmap_impl_autogen/include
>> -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build
>> -I/usr/include -I/usr/include/qt5 -I/usr/include/qt5/QtCore
>> -I/usr/lib64/qt5/mkspecs/linux-g++ -O2  -fexceptions -g
>> -grecord-gcc-switches -pipe -Wall
>> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>> -fstack-protector-strong
>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
>> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
>> -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
>> -mno-omit-leaf-frame-pointer -I/usr/lib64/gfortran/modules -DNDEBUG
>> -fbounds-check -funroll-all-loops -fno-f2c
>> -ffpe-summary=invalid,zero,overflow,underflow -Wall -Wno-conversion
>> -fno-second-underscore -fvisibility=hidden -fPIC -c
>> /builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/qmap/libqmap/f77_wisdom.f
>> -o CMakeFiles/qmap_impl.dir/f77_wisdom.f.o [ 81%] Linking CXX
>> executable ldpcsim240_74 /usr/bin/cmake -E cmake_link_script
>> CMakeFiles/ldpcsim240_74.dir/link.txt --verbose=1
>> /usr/bin/ld: error: decoder.f90.o: is triggering the generation of an
>> executable stack (because it has an executable .note.GNU-stack
>> section)
>> /usr/bin/ld: failed to set dynamic section sizes: no error
>> collect2: error: ld returned 1 exit status
>>
>> thanks & regards
>>
>> Jaroslav
>>
>> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278939
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2385733
> Any update on this Jaroslav, or indeed anyone else? It's a bit of a
> nightmare in Fedora at least.
>

Re: [wsjt-devel] Compiling 3.0.0-rc1 on openSUSE Tumblweed

[Marco C. <PY...@ou...>]

Thanks for theses adjustments George!

Also I'm an Opensuse Tumbleweed user and in order to get WSJTX 3.0 compiled, I had first to rollback cmake to version 3.

Hope that the devs team would take in consideration your inputs since not every user is able to modify the code like you!

Regards,

Marco PY1ZRJ

Inviato da Outlook per Android<https://aka.ms/AAb9ysg>
________________________________
From: George Baltz via wsjt-devel <wsj...@li...>
Sent: Wednesday, November 5, 2025 12:52:43 PM
To: WSJT software development <wsj...@li...>
Cc: George Baltz <geo...@gm...>
Subject: [wsjt-devel] Compiling 3.0.0-rc1 on openSUSE Tumblweed


openSUSE TW is a rolling distro, with all the latest, bright, shiny new software.  Building with cmake 4.1.2 and qt 6.10 shows a few problems.

I got the standard (qt5?) version to build and run with these hacks:

1) add -DCMAKE_POLICY_VERSION_MINIMUM=3.5..3.11 to the cmake configure command line

2) comment out line 199 of CMakeLists.txt

     #add_custom_target (install DEPENDS wsjtx-install)

3) Use `wsjtx-install` instead of `install` to install.

Did the same for the -improved version and it works well.

Tried the same for the -qt6 version and qt 6.10 complains  'void QSortFilterProx
yModel::invalidateFilter()’ is deprecated: Use begin/endFilterChange() instead [-Werror=deprecated-declarations]'


Build output is attached.

Any suggestions?

73 n3gb

[wsjt-devel] building WSJTX 3.0.0 improved on Windows 11

[<gr...@gr...>]

WSJTX developers:

 

    I am still attempting to build WSJTX-3.0.0_improved on Windows 11 from
JTSDK64.

I have made progress but have encountered a linking issue with the FFTW3
thread libraries.

 

The problem arises when linking jt9.exe. The diagnostic is as follows:

 

 

C:/JTSDK64-Tools/tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2
.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
libwsjt_fort_omp.a(downsam9.f90.obj):downsam9.f90:(.text+0x132): more
undefined references to `fftwf_plan_with_nthreads' follow

 

Is this a known problem?  Is there a fix for it?

 

Thanks in advance,

 

Gary R. Day

[wsjt-devel] Compiling 3.0.0-rc1 on openSUSE Tumblweed

[George B. <geo...@gm...>]

openSUSE TW is a rolling distro, with all the latest, bright, shiny new 
software.  Building with cmake 4.1.2 and qt 6.10 shows a few problems.

I got the standard (qt5?) version to build and run with these hacks:

1) add -DCMAKE_POLICY_VERSION_MINIMUM=3.5..3.11 to the cmake configure 
command line

2) comment out line 199 of CMakeLists.txt

#add_custom_target (installDEPENDS wsjtx-install)

3) Use `wsjtx-install` instead of `install` to install.

Did the same for the -improved version and it works well.

Tried the same for the -qt6 version and qt 6.10 complains  'void 
QSortFilterProx
yModel::invalidateFilter()’ is deprecated: Use begin/endFilterChange() 
instead [-Werror=deprecated-declarations]'

Build output is attached.

Any suggestions?

73 n3gb

Re: [wsjt-devel] decoder.f90 executable stack

[Brian M. <bd...@fe...>]

On Mon, 13 Oct 2025 18:16:48 +0200
Jaroslav Škarvada via wsjt-devel <wsj...@li...>
wrote:

> Hi,
> 
> linux distros are trying to harden with the noexecstack and the
> execstack in decoder.f90 is causing problems. E.g. [1], [2]. It seems
> the g++ linker doesn't allow combination of binaries with exec/noexec
> stacks [1], so the whole binary needs to be compiled with the
> execstack which may be unacceptable for some distros. The patch
> proposed in [1] uses mprotect, should something similar be upstreamed?
> 
> Build failure of wsjtx-2.7.0 with the gcc-c++-15.2.1 in Fedora
> rawhide: [81%] Building Fortran object
> qmap/libqmap/CMakeFiles/qmap_impl.dir/f77_wisdom.f.o
> cd
> /builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build/qmap/libqmap
> && /usr/bin/gfortran -DBIGSYM=1 -DBOOST_ALL_DYN_LINK
> -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CHRONO_DYN_LINK
> -DBOOST_CHRONO_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK
> -DBOOST_FILESYSTEM_NO_LIB -DBOOST_LOG_DYN_LINK -DBOOST_LOG_NO_LIB
> -DBOOST_LOG_SETUP_DYN_LINK -DBOOST_LOG_SETUP_NO_LIB
> -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_THREAD_DYN_LINK
> -DBOOST_THREAD_NO_LIB -DCMAKE_BUILD -DFOX_OTP -DQT5 -DQT_CORE_LIB
> -DQT_NO_DEBUG -DUNIX
> -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build/qmap/libqmap
> -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/qmap/libqmap
> -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build/qmap/libqmap/qmap_impl_autogen/include
> -I/builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/redhat-linux-build
> -I/usr/include -I/usr/include/qt5 -I/usr/include/qt5/QtCore
> -I/usr/lib64/qt5/mkspecs/linux-g++ -O2  -fexceptions -g
> -grecord-gcc-switches -pipe -Wall
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer -I/usr/lib64/gfortran/modules -DNDEBUG
> -fbounds-check -funroll-all-loops -fno-f2c
> -ffpe-summary=invalid,zero,overflow,underflow -Wall -Wno-conversion
> -fno-second-underscore -fvisibility=hidden -fPIC -c
> /builddir/build/BUILD/wsjtx-2.7.0-build/wsjtx-2.7.0/wsjtx/qmap/libqmap/f77_wisdom.f
> -o CMakeFiles/qmap_impl.dir/f77_wisdom.f.o [ 81%] Linking CXX
> executable ldpcsim240_74 /usr/bin/cmake -E cmake_link_script
> CMakeFiles/ldpcsim240_74.dir/link.txt --verbose=1
> /usr/bin/ld: error: decoder.f90.o: is triggering the generation of an
> executable stack (because it has an executable .note.GNU-stack
> section)
> /usr/bin/ld: failed to set dynamic section sizes: no error
> collect2: error: ld returned 1 exit status
> 
> thanks & regards
> 
> Jaroslav
> 
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278939
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2385733

Any update on this Jaroslav, or indeed anyone else? It's a bit of a
nightmare in Fedora at least.

-- 

Brian  G8SEZ

[wsjt-devel] wsjt-x vs n1mm time mismatch

[HASAN T. <has...@is...>]

I installed wsjtd- first, then n1mm. I open wsjt-x first, then n1mm. In wsjt-x, qso is automatically passed, only the day and time information is passed as the forward day and time. The day and time information is passed incorrectly in N1MM. 
yardım lütfen .PC win 10 64 bit 73 de TA2E 

[wsjt-devel] WSJTX build problem on Windows 11

[<gr...@gr...>]

Hello again to WSJT developers:

 

    Despite my best efforts I am still stimied at building WSJTX 3.0.0

improved on Windows 11 using JTSDK64-3.4.1.  Today I tried JTSDK64-4.0.0

but with no better result.

 

 

    After installing JTSDK64 and then clicking on the JTSDK64-setup shortcut

it presents a prompt that looks like:

 

PS C:\JTSDK64-Tools>

 

    According to the documentation it should stop in a setup

environment with a prompt that looks like

 

JTSDK-Setup>

 

According to the documentation I need to be in setup mode to configure

the Qt deployment.

 

Any suggestions will be much appreciated.

 

Gary R. Day

Re: [wsjt-devel] Sequencer Did Recognize 73 Because of a3 ?

[Iztok <s5...@s5...>]

Hello,

all OK: after R-13 RR73 or RRR is expected. 73 does not confirm RX of 
-13 raport.

73 gl, cu

Iztok, s52d

On 10/23/25 06:24, Tim Goeppinger via wsjt-devel wrote:
> I am using WSTJ-x 3.0.0 RC1
>
> Today I was working FR4OM on FT4, and I had an issue with the auto sequencing.    FR4OM's 73 message had the AP a3 in it, and was totally ignored by my auto sequencer.   I just continued to send my R-08 message.   Is this the way it should behave?
>
> 251022_150830    28.180 Tx FT4      0  0.0  567 FR4OM N6GP DM13
> 251022_150837    28.180 Rx FT4    -13  0.2 1447 N6GP FR4OM +03
> 251022_150845    28.180 Tx FT4      0  0.0  567 FR4OM N6GP R-13
> 251022_150852    28.180 Rx FT4     -8  0.2 1446 N6GP FR4OM 73  a3
> 251022_150900    28.180 Tx FT4      0  0.0  567 FR4OM N6GP R-08
> 251022_150915    28.180 Tx FT4      0  0.0  567 FR4OM N6GP R-08
>
> Tnx & 73,
> Tim N6GP
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Sequencer Did Recognize 73 Because of a3 ?

[Tim G. <ti...@ya...>]

I am using WSTJ-x 3.0.0 RC1

Today I was working FR4OM on FT4, and I had an issue with the auto sequencing.    FR4OM's 73 message had the AP a3 in it, and was totally ignored by my auto sequencer.   I just continued to send my R-08 message.   Is this the way it should behave?

251022_150830    28.180 Tx FT4      0  0.0  567 FR4OM N6GP DM13
251022_150837    28.180 Rx FT4    -13  0.2 1447 N6GP FR4OM +03
251022_150845    28.180 Tx FT4      0  0.0  567 FR4OM N6GP R-13
251022_150852    28.180 Rx FT4     -8  0.2 1446 N6GP FR4OM 73  a3
251022_150900    28.180 Tx FT4      0  0.0  567 FR4OM N6GP R-08
251022_150915    28.180 Tx FT4      0  0.0  567 FR4OM N6GP R-08

Tnx & 73,
Tim N6GP

[wsjt-devel] V3.0.0 rc1 issues

[Richard L. <ric...@gm...>]

Hi
Been using the new rc1 for a while and have a few issues to report.
Using Windows 10. All issues new to this RC1 and not seen in V2.7.0. My
usage is FT8 & FT4.

1. The link to the selected audio device comes up when you load app but
after a few TX cycles it drops out and you have to go to settings, Audio
tab and reselect the same device. Once you've done this once it seems to
hold onto it OK.

2. The log qso window keeps last Comments entered even though this is not
the selected option. Also it shows empty in the new qso comment field but
the previous old comment is logged.

3. In a qso exchange where it is necessary to repeat Tx3 before you get a
Tx4 confirmation the report sent changes each time the caller is decodes
and has a different decode report. This means it's impossible to know which
report the caller has actually received in the sequence. I don't recall
seeing this in V2.7. Example here where my sent report changes from R-11 to
R-10 to R-09 before I see the Tx4:

249 VA3BS G4AHN -01 251021_181822 28.180 Rx FT4 -11 0.5 1385 "on Odd"
250 G4AHN VA3BS R-11 251021_181830 28.180 Tx FT4 0 0.0 2491 "On Even"
251 VA3BS G4AHN -01 251021_181837 28.180 Rx FT4 -10 0.5 1385 "on Odd"
252 G4AHN VA3BS R-10 251021_181845 28.180 Tx FT4 0 0.0 2491 "on Odd"
253 VA3BS G4AHN -01 251021_181852 28.180 Rx FT4 -9 0.4 1385 "on Odd"
254 G4AHN VA3BS R-09 251021_181900 28.180 Tx FT4 0 0.0 2491 "On Even"
255 G4AHN VA3BS R-09 251021_181915 28.180 Tx FT4 0 0.0 2491 "on Odd"
256 G4AHN VA3BS R-09 251021_181930 28.180 Tx FT4 0 0.0 1385 "On Even"
257 G4AHN VA3BS R-09 251021_181945 28.180 Tx FT4 0 0.0 1385 "on Odd"
258 VA3BS G4AHN RR73 251021_181952 28.180 Rx FT4 -4 0.5 1385 "on Odd"

4. When calling CQ it sometimes does not auto select a caller and continues
with another CQ. Doesn't seem to be because of a late decode looking at my
UDP log. see example here at 145730.

145700 Tx 2316 + CQ G4AHN IO91

145715 Tx 2316 + CQ G4AHN IO91

145722 -11 0.4 2313 + G4AHN AB8E FM08  U.S.A. VA-WV

145730 Tx 2316 + CQ G4AHN IO91

145734 Tx 2316 + AB8E G4AHN -11

145745 Tx 2316 + AB8E G4AHN -11

145752 -7 0.3 2314 + G4AHN AB8E R-11  U.S.A.

145800 Tx 2316 + AB8E G4AHN RR73

145830 Tx 2316 + AB8E G4AHN RR73

145845 Tx 2316 + AB8E G4AHN RR73

145900 Tx 2316 + AB8E G4AHN RR73

145915 Tx 2316 + CQ G4AHN IO91

145930 Tx 2316 + CQ G4AHN IO91




Many thanks for all the hard work

73

Rich

G4AHN

Re: [wsjt-devel] Can't Enable Tx in Super Fox mode (WSJT-X version 2.7)

[Larry B. <lar...@ve...>]

Hi Jim,

I don't think it will transmit until he has decoded a superfox 
transmission.   It's designed this way to prevent blind calling.

73 -- Larry - W1DYJ



On 10/21/2025 19:07, Jim Reisert AD1C via wsjt-devel wrote:
> My father W1JR is running WSJT-X version 2.7.
>
> He can transmit in normal mode (and I believe Fox/Hound) mode, but
> when he switches to SF mode, clicking on "Enable Tx" doesn't work --
> the box never enables transmitting.  I just watched him do this
> (virtually), and I'm confused why.
>
> Any idea what could be the problem?
>
> Thanks - Jim AD1C
>
>

[wsjt-devel] Can't Enable Tx in Super Fox mode (WSJT-X version 2.7)

[Jim R. A. <jjr...@al...>]

My father W1JR is running WSJT-X version 2.7.

He can transmit in normal mode (and I believe Fox/Hound) mode, but
when he switches to SF mode, clicking on "Enable Tx" doesn't work --
the box never enables transmitting.  I just watched him do this
(virtually), and I'm confused why.

Any idea what could be the problem?

Thanks - Jim AD1C


-- 
Jim Reisert AD1C, <jjr...@al...>, https://ad1c.us

Re: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

[Dan C. <hot...@ho...>]

I’ve made a couple of handfuls of contacts with them, the ones that were made using SF all showed the verification with the exception of 1 17m contact on 10/18. Even though I got the RR73 from the station I worked, it never confirmed in Clublog. All others confirmed immediately. I can only assume that I worked a pirated call without having them do a log check. I have since reworked that band slot.
Sent from my iPhone

> On Oct 20, 2025, at 4:42 PM, Erik Icket via wsjt-devel <wsj...@li...> wrote:
> 
> Some more info,
> 
> I did a fallback to 2.7.0, and there as well, there is no OTP message.
> So the OM has a SF key (see ncdxf), but probably has not loaded his key by
> ticking OTP in the Advanced tab, and entering the key.
> 
> What about a hint at the hound side (and the fox side ?), that the fox is
> running without OTP key ?
> 
> 73's Erik
> ON4PB
> 
> -----Original Message-----
> From: Erik Icket <run...@gm...>
> Sent: Monday, 20 October 2025 22:28
> To: wsj...@li...
> Subject: SuperFox - OTP verification in rel 3.0.0-rc1
> 
> Dear developers,
> 
> This evening, I was working PJ6Y in SuperFox mode, but did not observe any
> OTP verification results.
> 
> ------ 2025-10-20 - 20:11:00 UTC - 20m - FT8 ------
> 201100 -5 0.4 746 ~ SP9MOV PJ6Y RR73
> 201100 -5 0.4 746 ~ TA2LG PJ6Y -01
> 201100 -5 0.4 746 ~ SQ2HL PJ6Y -18
> ------ 2025-10-20 - 20:11:30 UTC - 20m - FT8 ------
> 201130 -7 0.5 746 ~ SQ2HL PJ6Y RR73
> 201130 -7 0.5 746 ~ TA2LG PJ6Y -01
> 201130 -7 0.5 746 ~ ON4PB PJ6Y -04
> 
> Special operating activity is ticked, as well as SuperFox mode, Hound, OTP,
> Show OTP messages.
> 
> Should there be a either a $Verify$ or verified or invalid OTP result line
> in the Band Activity ?
> 
> 73's Erik
> ON4PB
> 
> 
> 
> 
> 
> 
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

[Erik I. <run...@gm...>]

Please read “hound side” and not “fox side” in my last phrase.

 

My apologies.

 

From: Erik Icket <run...@gm...> 
Sent: Monday, 20 October 2025 23:46
To: 'Joseph Taylor' <jo...@Pr...>; wsj...@li...
Subject: RE: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

 

Dear Joe,

 

I may well have been too naïve in believing so.

 

The thing is that on the hound side, in the absence of an OTP, and all OTP checkboxes ticked, you cannot really tell if an OTP verification is done or not.

I believe today, one can observe “$Verify$”, “K1ABC verified”, “K1ABC invalid” in the band activity pane.

What if we add a hint at the fox side that the callsign is “not verified” if all OTP checkboxes (Superfox mode, Hound, OTP, Show OTP messages) are ticked ?

 

73’s Erik

ON4PB

 

From: Joseph Taylor <jo...@Pr... <mailto:jo...@Pr...> > 
Sent: Monday, 20 October 2025 22:54
To: wsj...@li... <mailto:wsj...@li...> 
Cc: Erik Icket <run...@gm... <mailto:run...@gm...> >
Subject: Re: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

 

Hi Erik,

 

Are you sure the station you're receiving is the legitimate SuperFox? We have seen other examples where the "PJ6Y verified" message appears as expected. Here's one from several days ago.

 



 

    -- 73, Joe, K1JT

Re: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

[Erik I. <run...@gm...>]

Dear Joe,

 

I may well have been too naïve in believing so.

 

The thing is that on the hound side, in the absence of an OTP, and all OTP checkboxes ticked, you cannot really tell if an OTP verification is done or not.

I believe today, one can observe “$Verify$”, “K1ABC verified”, “K1ABC invalid” in the band activity pane.

What if we add a hint at the fox side that the callsign is “not verified” if all OTP checkboxes (Superfox mode, Hound, OTP, Show OTP messages) are ticked ?

 

73’s Erik

ON4PB

 

From: Joseph Taylor <jo...@Pr...> 
Sent: Monday, 20 October 2025 22:54
To: wsj...@li...
Cc: Erik Icket <run...@gm...>
Subject: Re: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

 

Hi Erik,

 

Are you sure the station you're receiving is the legitimate SuperFox? We have seen other examples where the "PJ6Y verified" message appears as expected. Here's one from several days ago.

 



 

    -- 73, Joe, K1JT

Re: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

[Joseph T. <jo...@Pr...>]

Hi Erik,

Are you sure the station you're receiving is the legitimate SuperFox? We have seen other examples where the "PJ6Y verified" message appears as expected. Here's one from several days ago.

[cid:1c518ba7-4742-42f7-8f5e-73b0e5c9f472]

    -- 73, Joe, K1JT

Re: [wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

[Erik I. <run...@gm...>]

Some more info,

I did a fallback to 2.7.0, and there as well, there is no OTP message.
So the OM has a SF key (see ncdxf), but probably has not loaded his key by
ticking OTP in the Advanced tab, and entering the key.

What about a hint at the hound side (and the fox side ?), that the fox is
running without OTP key ?

73's Erik
ON4PB

-----Original Message-----
From: Erik Icket <run...@gm...> 
Sent: Monday, 20 October 2025 22:28
To: wsj...@li...
Subject: SuperFox - OTP verification in rel 3.0.0-rc1

Dear developers,

This evening, I was working PJ6Y in SuperFox mode, but did not observe any
OTP verification results.

------ 2025-10-20 - 20:11:00 UTC - 20m - FT8 ------
201100 -5 0.4 746 ~ SP9MOV PJ6Y RR73
201100 -5 0.4 746 ~ TA2LG PJ6Y -01
201100 -5 0.4 746 ~ SQ2HL PJ6Y -18
------ 2025-10-20 - 20:11:30 UTC - 20m - FT8 ------
201130 -7 0.5 746 ~ SQ2HL PJ6Y RR73
201130 -7 0.5 746 ~ TA2LG PJ6Y -01
201130 -7 0.5 746 ~ ON4PB PJ6Y -04

Special operating activity is ticked, as well as SuperFox mode, Hound, OTP,
Show OTP messages.

Should there be a either a $Verify$ or verified or invalid OTP result line
in the Band Activity ?

73's Erik
ON4PB

[wsjt-devel] SuperFox - OTP verification in rel 3.0.0-rc1

[Erik I. <run...@gm...>]

Dear developers,

This evening, I was working PJ6Y in SuperFox mode, but did not observe any
OTP verification results.

------ 2025-10-20 - 20:11:00 UTC - 20m - FT8 ------
201100 -5 0.4 746 ~ SP9MOV PJ6Y RR73
201100 -5 0.4 746 ~ TA2LG PJ6Y -01
201100 -5 0.4 746 ~ SQ2HL PJ6Y -18
------ 2025-10-20 - 20:11:30 UTC - 20m - FT8 ------
201130 -7 0.5 746 ~ SQ2HL PJ6Y RR73
201130 -7 0.5 746 ~ TA2LG PJ6Y -01
201130 -7 0.5 746 ~ ON4PB PJ6Y -04

Special operating activity is ticked, as well as SuperFox mode, Hound, OTP,
Show OTP messages.

Should there be a either a $Verify$ or verified or invalid OTP result line
in the Band Activity ?

73's Erik
ON4PB

Re: [wsjt-devel] WSJTX build issue on Windows

[Gary R. <cga...@gm...>]

You might want to look over in the JTSDK reflector for Windows build assistance:

https://groups.io/g/JTSDK/topics
> On Oct 19, 2025, at 3:41 PM, Mike Hornsby via wsjt-devel <wsj...@li...> wrote:
> 
> I also attempted to do a windows 11 build of wsjtx. Ran into same issues and did not get any further. 
> 
> Was able to build easily on various raspberry pi’s and older pcs. PCs using Linux mint thanks to instructions from:
> http://www.kk5jy.net/wsjtx-build/
> 
> Much evidence exists on this list for not using windows to run wsjtx. Issues with Com ports, constant updates, Microsoft withdrawal of support for versions … windows has always been problematic as any new application install can update libraries and configurations that can impact other applications.
> 
> Added to this, for handicap types of uses I would build a WSJTx raspberry pi like appliance that is stand alone and plug and play. 
> 
> To keep it as simple an and low cost as possible, I would start with a 20 meter only version that operates on the radio VOX interface. Anyone have any stats on FT8 traffic by band? 
> 
> Also, I know from experience, with a 20 watts and a 20 meter ham stick, or if you have an attic or yard, a speaker wire dipole, you can work the globe.
> 
> GL ES 73 
> Mike KC8yom
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Oct 19, 2025, at 12:54 PM, grday--- via wsjt-devel <wsj...@li... <mailto:wsj...@li...>> wrote:
>> 
>> 
>> Hello WSJTX developers:
>>  
>>     I am trying to build WSJTX from the tarball wsjtx-3.0.0_improved_PLUS_250924.tgz
>> as recommended by dg2ycb several weeks ago, but have encountered
>> a barrier for which I am looking for a suggestion.
>>  
>>     I need to build WSJTX on a Windows 11 system.
>>     I think I have made pretty good progress in the sense that I have
>> gotten what I believe to be all of the dependant packages to build and
>> install, including Qt 5.15.2, boost, fftw, hamlib, all of the mingw
>> compilers, etc.
>>  
>>    I think I am close to getting wsjtx to build, but right now I am
>> pretty much stimied.
>>  
>>     I began by installing Qt 5.15.2 and jtsdk64-tools. Within the
>> jtsdk64-tools directory framework and from the mingw64 shell I installed
>> the various dependencies via the package manager.
>>  
>>     The wsjtx source is setup to be built via the CMake build utility
>> with which I am currently a novice. I have tried to build wsjtx from a
>> build directory  via the following commands:
>>  
>> cmake -G "MinGW Makefiles" \
>>   -DWSJT_GENERATE_DOCS=OFF \
>>   -DCMAKE_Fortran_FLAGS="-std=legacy -fallow-argument-mismatch" \
>>   -DCMAKE_BUILD_TYPE=Release \
>>   -DCMAKE_PREFIX_PATH="/c/Qt/5.15.2/mingw81_64;/c/JTSDK64-Tools/tools/msys64/mingw64" \
>>   ..
>>  
>> cmake --build . --parallel
>>  
>>     The diagnostic that I get is:
>>  
>> [ 38%] Performing configure step for 'hamlib'
>> 'C:\JTSDK64-Tools\src\wsjtx\build\hamlib-prefix\src\hamlib\configure' is not recognized as an internal or external command,
>> operable program or batch file.
>>  
>>     I tried building and installing hamlib separately which appeared
>> to work ok but then I found that the building of wsjtx is very tightly
>> coupled to the building of hamlib in the CMake build scripts. I tried
>> tweaking the top level CMakeLists.txt file, specificly the call to
>> ExternalProject_Add(hamlib to use the bash shell to execute configure
>> but that did not work.
>>  
>>    I also tried setting the CONFIG_SHELL environment variable, i.e.,
>>  
>> export CONFIG_SHELL=/usr/bin/sh
>>  
>> but it had no effect.
>>  
>>   Any suggestions will be much appreciated.
>>  
>>     As further background, I myself am a blind developer who has
>> volunteered to make some modifications to the UDP daemon for the
>> purpose of extending the current API so that more of the WSJTX functionality
>> is available via an external accessibility agent. I myself am not a
>> radio operator and have no call sign but my goal is to make more WSJTX
>> functions available to the WSJTX blind user group.
>>  
>> Thanks in advance,
>>  
>> Gary R. Day
>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li... <mailto:wsj...@li...>
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li... <mailto:wsj...@li...>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJTX build issue on Windows

[Mike H. <mik...@ma...>]

I also attempted to do a windows 11 build of wsjtx. Ran into same issues and did not get any further. 

Was able to build easily on various raspberry pi’s and older pcs. PCs using Linux mint thanks to instructions from:
http://www.kk5jy.net/wsjtx-build/

Much evidence exists on this list for not using windows to run wsjtx. Issues with Com ports, constant updates, Microsoft withdrawal of support for versions … windows has always been problematic as any new application install can update libraries and configurations that can impact other applications.

Added to this, for handicap types of uses I would build a WSJTx raspberry pi like appliance that is stand alone and plug and play. 

To keep it as simple an and low cost as possible, I would start with a 20 meter only version that operates on the radio VOX interface. Anyone have any stats on FT8 traffic by band? 

Also, I know from experience, with a 20 watts and a 20 meter ham stick, or if you have an attic or yard, a speaker wire dipole, you can work the globe.

GL ES 73 
Mike KC8yom









> On Oct 19, 2025, at 12:54 PM, grday--- via wsjt-devel <wsj...@li...> wrote:
> 
> 
> Hello WSJTX developers:
>  
>     I am trying to build WSJTX from the tarball wsjtx-3.0.0_improved_PLUS_250924.tgz
> as recommended by dg2ycb several weeks ago, but have encountered
> a barrier for which I am looking for a suggestion.
>  
>     I need to build WSJTX on a Windows 11 system.
>     I think I have made pretty good progress in the sense that I have
> gotten what I believe to be all of the dependant packages to build and
> install, including Qt 5.15.2, boost, fftw, hamlib, all of the mingw
> compilers, etc.
>  
>    I think I am close to getting wsjtx to build, but right now I am
> pretty much stimied.
>  
>     I began by installing Qt 5.15.2 and jtsdk64-tools. Within the
> jtsdk64-tools directory framework and from the mingw64 shell I installed
> the various dependencies via the package manager.
>  
>     The wsjtx source is setup to be built via the CMake build utility
> with which I am currently a novice. I have tried to build wsjtx from a
> build directory  via the following commands:
>  
> cmake -G "MinGW Makefiles" \
>   -DWSJT_GENERATE_DOCS=OFF \
>   -DCMAKE_Fortran_FLAGS="-std=legacy -fallow-argument-mismatch" \
>   -DCMAKE_BUILD_TYPE=Release \
>   -DCMAKE_PREFIX_PATH="/c/Qt/5.15.2/mingw81_64;/c/JTSDK64-Tools/tools/msys64/mingw64" \
>   ..
>  
> cmake --build . --parallel
>  
>     The diagnostic that I get is:
>  
> [ 38%] Performing configure step for 'hamlib'
> 'C:\JTSDK64-Tools\src\wsjtx\build\hamlib-prefix\src\hamlib\configure' is not recognized as an internal or external command,
> operable program or batch file.
>  
>     I tried building and installing hamlib separately which appeared
> to work ok but then I found that the building of wsjtx is very tightly
> coupled to the building of hamlib in the CMake build scripts. I tried
> tweaking the top level CMakeLists.txt file, specificly the call to
> ExternalProject_Add(hamlib to use the bash shell to execute configure
> but that did not work.
>  
>    I also tried setting the CONFIG_SHELL environment variable, i.e.,
>  
> export CONFIG_SHELL=/usr/bin/sh
>  
> but it had no effect.
>  
>   Any suggestions will be much appreciated.
>  
>     As further background, I myself am a blind developer who has
> volunteered to make some modifications to the UDP daemon for the
> purpose of extending the current API so that more of the WSJTX functionality
> is available via an external accessibility agent. I myself am not a
> radio operator and have no call sign but my goal is to make more WSJTX
> functions available to the WSJTX blind user group.
>  
> Thanks in advance,
>  
> Gary R. Day
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJTX build issue on Windows

[<gr...@gr...>]

Hello WSJTX developers:

 

    I am trying to build WSJTX from the tarball
wsjtx-3.0.0_improved_PLUS_250924.tgz

as recommended by dg2ycb several weeks ago, but have encountered

a barrier for which I am looking for a suggestion.

 

    I need to build WSJTX on a Windows 11 system.

    I think I have made pretty good progress in the sense that I have

gotten what I believe to be all of the dependant packages to build and

install, including Qt 5.15.2, boost, fftw, hamlib, all of the mingw

compilers, etc.

 

   I think I am close to getting wsjtx to build, but right now I am

pretty much stimied.

 

    I began by installing Qt 5.15.2 and jtsdk64-tools. Within the

jtsdk64-tools directory framework and from the mingw64 shell I installed

the various dependencies via the package manager.

 

    The wsjtx source is setup to be built via the CMake build utility

with which I am currently a novice. I have tried to build wsjtx from a

build directory  via the following commands:

 

cmake -G "MinGW Makefiles" \

  -DWSJT_GENERATE_DOCS=OFF \

  -DCMAKE_Fortran_FLAGS="-std=legacy -fallow-argument-mismatch" \

  -DCMAKE_BUILD_TYPE=Release \

 
-DCMAKE_PREFIX_PATH="/c/Qt/5.15.2/mingw81_64;/c/JTSDK64-Tools/tools/msys64/m
ingw64" \

  ..

 

cmake --build . --parallel

 

    The diagnostic that I get is:

 

[ 38%] Performing configure step for 'hamlib'

'C:\JTSDK64-Tools\src\wsjtx\build\hamlib-prefix\src\hamlib\configure' is not
recognized as an internal or external command,

operable program or batch file.

 

    I tried building and installing hamlib separately which appeared

to work ok but then I found that the building of wsjtx is very tightly

coupled to the building of hamlib in the CMake build scripts. I tried

tweaking the top level CMakeLists.txt file, specificly the call to

ExternalProject_Add(hamlib to use the bash shell to execute configure

but that did not work.

 

   I also tried setting the CONFIG_SHELL environment variable, i.e.,

 

export CONFIG_SHELL=/usr/bin/sh

 

but it had no effect.

 

  Any suggestions will be much appreciated.

 

    As further background, I myself am a blind developer who has

volunteered to make some modifications to the UDP daemon for the

purpose of extending the current API so that more of the WSJTX functionality

is available via an external accessibility agent. I myself am not a

radio operator and have no call sign but my goal is to make more WSJTX

functions available to the WSJTX blind user group.

 

Thanks in advance,

 

Gary R. Day

Re: [wsjt-devel] Superfox MacOS

[Gary R. <cga...@gm...>]

I am decoding them on 10 right now with Mac M2 and OS 15.7.1 WSJT-X improved AL plus

> On Oct 18, 2025, at 1:49 PM, John Stengrevics via wsjt-devel <wsj...@li...> wrote:
> 
> Probably something specific to your situation.  I worked PJ6Y on 10m super fox this morning.  Running a MacBook Pro with M3 Max chip and Tahoe 26.0.1 operating system.
> 
> 73,
> 
> John
> WA1EAZ
> 
>> On Oct 18, 2025, at 1:40 PM, Michael Morgan via wsjt-devel <wsj...@li...> wrote:
>> 
>> I was just trying to decode and work 5K0UA on 10M using super fox and on my Mac it would never decode them.  I switched to my windows pc and it decoded fine and I was able to work them.  My time was good on my Mac.  I don’t typically use my windows machine but one I got the time synced on it, the decodes started working right away.  I am using WSJ-X Improved 250924 on both.  On my Mac I am using the M1 build.  I did also try the standard WSJT build as as well.  Not sure if it is just my situation or something may be up with the Mac builds of super fox.  All other functions work fine.  Here’s a screenshot showing both running.  I did grab an audio file but not sure that is necessary since it works fine on the Windows side.  
>> 
>> 73’s
>> 
>> Michael, AA5SH
>> 
>> https://www.aa5sh.com/pics/wsjt-sf.png_______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Superfox MacOS

[John S. <jst...@co...>]

Probably something specific to your situation.  I worked PJ6Y on 10m super fox this morning.  Running a MacBook Pro with M3 Max chip and Tahoe 26.0.1 operating system.

73,

John
WA1EAZ

> On Oct 18, 2025, at 1:40 PM, Michael Morgan via wsjt-devel <wsj...@li...> wrote:
> 
> I was just trying to decode and work 5K0UA on 10M using super fox and on my Mac it would never decode them.  I switched to my windows pc and it decoded fine and I was able to work them.  My time was good on my Mac.  I don’t typically use my windows machine but one I got the time synced on it, the decodes started working right away.  I am using WSJ-X Improved 250924 on both.  On my Mac I am using the M1 build.  I did also try the standard WSJT build as as well.  Not sure if it is just my situation or something may be up with the Mac builds of super fox.  All other functions work fine.  Here’s a screenshot showing both running.  I did grab an audio file but not sure that is necessary since it works fine on the Windows side.  
> 
> 73’s
> 
> Michael, AA5SH
> 
> https://www.aa5sh.com/pics/wsjt-sf.png_______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel