Bill, Greg, The dependency on a custom install of Hamlib could pose as a problem for many. Including testers. The Linux situation is also rather bad. To make things worse, I don't foresee the changes in Hamlib making its way to a public release any time soon. In the past, it took quite some time to get changes released. Then there is the time for the changes to propagate into the Linux distributions.
What do you think of using rigctld instead of linking with the lib? It seems rigctld works on Unix and Windows. We could then keep our custom hamlib as a separate package. 73, -- Edson PY2SDR On Wed, Apr 2, 2014 at 3:58 PM, Greg Beam <ki...@yahoo.com> wrote: > 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 > >>> 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
