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. ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
