On 02/04/2014 15:50, Greg Beam wrote: > HI Bill, Hi Greg, > > 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. Yes I agree that building hamlib does need a few MinGW extra prerequisites. Once set up there is no problem of course.
I would really like to get the WSJT-X project to build hamlib as an external project, but all the things you mention are a problem there with the added complexity that hamlib really needs to be built from an msys console whereas Qt programs like jt9 and wsjtx must be built from a windows console because of the way qt-project have built their MinGW environment. I will build a Windows hamlib for you with at least a static libraries. I hadn't realized that you were relying on the binary packages I posted earlier. I am currently trying to sort out the libusb dependency so I'll update the binaries when I've either sorted that out or given up. > > 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? No that won't work since hamlib is used for independent PTT port control for all interfaces. > > 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. I have put in a version check since there are so many fixes in hamlib 3.0 that I cannot give any guarantees that CAT control will work with the old library. I want developers and testers to use the new hamlib to help me iron out defects that remain. > > 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 >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> > ------------------------------------------------------------------------------ > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
