Hi Bill, Ok, thank you.
One other question. How are you setup to build on Windows, are you using MSYS + MinGW32 from mingw.org to build the QT projects? I ran into thread issues when I tried that, and thus, ended up having to use MinGW32 for WSJT & WSPR, and mingw48_32 from QT5 tools. If your setup using just MSYS + MinGW, and we can get that to work for all 5 apps, that would certainly simplify things. As a side note, I was able to build WSJT-X from the package you'd sent previous. It didn't find the Static Hamlib binaries, but it's up and running on 20m. 73's Greg, KI7MT On 4/2/2014 18:30, Bill Somerville wrote: > 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 > ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
