Hi Bill, I may have misunderstood the issue. I thought that you were having issues with Hamlib on Linux and on Windows. I stand corrected.
I agree that it should not be a problem with Qt5 on linux.In the worst case, compiling from sources would not be a problem. 73, -- Edson PY2SDR On Wed, Apr 2, 2014 at 4:32 PM, Bill Somerville <g4...@classdesign.com>wrote: > On 02/04/2014 20:10, Edson W. R. Pereira wrote: > > > Bill, Greg, > > Hi Edson, > > > 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. > > I don't see the problem (at least not with hamlib). > > On Windows the installer (and the release build) fully package all the > required libraries. There are no external dependencies other that standard > o/s DLLs. > > On Mac the installer (and the release build) create a Mac bundled > application, again with all external dependencies embedded apart from > standard o/s dylibs. > > On Linux my latest changes will mean that hamlib is statically linked > (actually it will probably be statically linked on all platforms for > consistency). The external dependencies are fftw which is available on all > recent Linux distros and Qt5 which is on some. > > So the problem is Qt5 on Linux, not hamlib. Since qt-project.org provide > comprehensive binary installers for many platforms I don't think this is a > big issue. > > > 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. > > I don't understand this suggestion, rigctld is a server that can be talked > to by hamlib clients instead of talking directly to the rig. The hamlib > integration in WSJT-X can already do this as the network rigctl backend is > just another hamlib backend. We would still have to ship a rigctld with the > latest hamlib linked to get the correct functionality. Doesn't this double > the issues with two hamlib programs that have to be statically linked to > hamlib 3.0? > > > 73, > > -- Edson PY2SDR > > 73 > Bill > G4WJS. > > > > > > 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 > listwsjt-devel@lists.sourceforge.nethttps://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
