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
<mailto: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 <http://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 <http://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
<mailto:wsjt-devel@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>>
------------------------------------------------------------------------------
>> _______________________________________________
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
------------------------------------------------------------------------------
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
<mailto: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
