On 02/04/2014 19:58, Greg Beam wrote: > Hi Bill, Hi Greg, > > 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? No I use a Windows console and the mingw48_32 toolchain provided by Qt. This is toolchain is required for clean builds because the Qt libraries are fully compatible with it.
I do have a bunch of stuff from a MinGW install on my dev environment PATH but definitely nothing from the msys environment as that is NOT compatible with Windows console operation or with the Qt SDK. > > 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. The previous binary hamlib (3.0) package didn't have static libs built, this was deliberate since I know static linking of hamlib doesn't work for now at least. The build changes I made don't enforce static linking of hamlib, nor do they enforce v3.0 if pkg-config isn't available. I won't enforce the final checks until I have a fully working WSJT-X build with static hamlib v3.0. > > 73's > Greg, KI7MT 73 Bill G4WJS. > > > 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 >>>> 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 >> > ------------------------------------------------------------------------------ > _______________________________________________ > 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
