HI Bill, Thanks for the update.
Is there any chance of providing the required libraries for Windows, other wise, this change has a much larger impact than pkg-config. As you stated in the original release, Autotools, m4, Libtool and are all requirements to build Hamlib (I found it wants a few more also), which basically means, one needs MSYS (on Windows) installed in addition to the Qt5 tool chain. That is a pretty substantial requirement to provide one library. Alternatively, is there any way to simply tun off the Hamlib requirement at build time and rely on 3rd part tools such as DXL commander, HRD etc? Is Hamlib 1.12.x still an option? It just seems allot to fore the use of an unreleased Library that requires so much to accommodate it use. 73's Greg, KI7MT On 4/2/2014 12:46, Bill Somerville wrote: > 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 > ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
