[wsjt-devel] WSJT-X Forewarning of some build changes.

[Bill S. <g4...@cl...>]

Hi All,

because we are currently using a fork of hamlib and also because even 
when all the changes in the fork are accepted and released as a new 
version of hamlib is probably a long way off; it is necessary to deal 
with how we link to hamlib in our release packages.

On Windows and Mac we currently bundle the hamlib and other dependencies 
(fortarn, fftw & Qt5) as DLLs/dylibs in the installed package. On Linux 
there isn't an equivalent solution and shipping non-standard (where 
non-standard means newer versions from that available via distribution 
package repositories) is not really possible. Fortran and fftw are ok as 
a suitable version is in all repos that I know of. Qt5 is in some of the 
newer Linux repos but not all. Hamlib (v3.0) isn't in any repo.

The normal approach with non-standard libraries is to static link them 
into the application. Unfortunately building a Qt5 suitable for static 
linking is very difficult (maybe impossible) so we can't do much about 
that, OTOH qt-project.org provides easy to use installers for Qt5 for 
many platforms. So for Qt5 I think we will have to let Linux users who 
don't have Qt5 in their distribution package repositories sort out the 
Qt5 dependency themselves.

For hamlib we are able to static link. To enable this I have upgraded 
the CMake find module for hamlib to include static linking capabilities. 
Hamlib uses pkg-config to tell clients how to link it so you will need 
to have pkg-config installed on your build machines. It is a standard 
package on all Linux distros, it is available from MacPorts on Mac. On 
Windows it is a bit more complicated as the full pkg-config package for 
MinGW has a circular dependency with glib. So I suggest you install 
pkg-config-lite which you can get from here 
https://sourceforge.net/projects/pkgconfiglite/ Install the latest 
binary package and make sure it is on you MinGW PATH for builds.

While sorting this out I discovered a defect in the hamlib pkg-config 
generation, a fix for has been submitted to the hamlib developers. My 
integration branch of my hamlib fork has the fix in place.

So you will need to update your hamlib sources:

cd <source-dir>/u-bsomervi-hamlib
git pull origin integration

Then rebuild hamlib. In the past I have suggested a hamlib configuration 
with only dynamic libraries, because of these changes you probably want 
to build static hamlib archives (the WSJT-X build will still work with 
the dynamic libs but static is now preferred). Reconfigure your hamlib 
build as follows:

Assume you build out of the source tree in a sub-directory called 
'build' and install into 'c:\test-install\hamlib'

cd build
../autogen --prefix /c/test-install/hamlib
make clean && make && make install

Once that is done you can re-build WSJT-X as usual. I would recommend 
deleting the CMakeCache.txt in your WSJT-X build tree(s) and 
re-configuring since CMake isn't perfect at picking up changes in 
external dependencies.

Sorry for the disruption, but we have to move towards being able to 
deliver clean installer packages for all supported platforms.

73
Bill
G4WJS.