On 02/04/2014 15:50, Greg Beam wrote: > HI Bill, Hi Greg & All, > > 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. I have updated the Windows binary package of hamlib 3.0 built from the latest integration branch of my hamlib 3.0 fork on SF. Here: https://dl.dropboxusercontent.com/u/4192709/Hamlib-integration-wsjtx.zip
The Linux and Mac binary packages there are not yet updated, but they should work as is anyway. I will update them as I build them for my own testing and development just in case anyone needs them. <snip> > 73's > Greg, KI7MT 73 Bill G4WJS. > > > > > 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 ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
