Hi All,
this is an update for those that are building hamlib themselves for WSJT-X.
I recently noticed that the hamlib build process does not strip the
executable artefacts, this has not mattered until we added a copy of the
rigctld server to the WSJT-X build artefacts. There is no defect but t
On 24/09/2014 22:52, KI7MT wrote:
> Hi Bill, Joe,
Hi Greg,
>
> I did some testing with this today. I Downloaded & Installed (unzipped):
>
> http://hivelocity.dl.sourceforge.net/project/mingwbuilds/external-binary-packages/msys%2B7za%2Bwget%2Bsvn%2Bgit%2Bmercurial%2Bcvs-rev13.7z
>
> I used this vers
Hi Bill, Joe,
I did some testing with this today. I Downloaded & Installed (unzipped):
http://hivelocity.dl.sourceforge.net/project/mingwbuilds/external-binary-packages/msys%2B7za%2Bwget%2Bsvn%2Bgit%2Bmercurial%2Bcvs-rev13.7z
I used this version of MSYS as it has Git, SVN, Hg, and all Autotools
On 24/09/2014 18:09, KI7MT wrote:
Hi Greg,
> HI Joe,
>
> I forgot to mention, when building the package:
>
> build wsjtx package
>
> the script will perform at build tree configure first, then, it runs:
>
> cmake --build . --target package
>
> %OPTION% is not set, so the default is Release
>
> I d
HI Joe,
I forgot to mention, when building the package:
build wsjtx package
the script will perform at build tree configure first, then, it runs:
cmake --build . --target package
%OPTION% is not set, so the default is Release
I don't think you need to build the install target:
build wsjtx ri
A small clarification:-
On 24/09/2014 17:53, Bill Somerville wrote:
> On 24/09/2014 17:50, KI7MT wrote:
> Hi Greg,
>> Hi Joe,
>>
>>
>> On 9/24/2014 16:31, Joe Taylor wrote:
>
>
>>> The only complaint issued by any of the scripts is this one from the
>>> JTSDK-QT command "build wsjtx package":
>>
On 24/09/2014 17:50, KI7MT wrote:
Hi Greg,
> Hi Joe,
>
>
> On 9/24/2014 16:31, Joe Taylor wrote:
>> The only complaint issued by any of the scripts is this one from the
>> JTSDK-QT command "build wsjtx package":
>>
>> ###
>> CP
Hi Joe,
On 9/24/2014 16:31, Joe Taylor wrote:
> Hi Bill and Greg,
>
> As you recognized, the procedure I went through installed the newly
> built hamlib files, but not in the places I had expected. My mistake.
>
> I have now changed the "--prefix=..." part of the command that invokes
> autog
On 24/09/2014 17:31, Joe Taylor wrote:
> Hi Bill and Greg,
Hi Joe,
>
> As you recognized, the procedure I went through installed the newly
> built hamlib files, but not in the places I had expected. My mistake.
>
> I have now changed the "--prefix=..." part of the command that invokes
> autogen.sh
On 24/09/2014 17:22, KI7MT wrote:
> HI Bill,
Hi Greg,
>
> I agree, personally, I would set, if building for JTSDK-QT, the
> --prefix=C:/JTSDK-QT/hamlib3/mingw32
>
> that should produce: ../hamlib3/mingw32/{bin,include,lib,share} and the
> associated sub-folders.
Sounds good.
>
> I'm not sure if MSY
Hi Bill and Greg,
As you recognized, the procedure I went through installed the newly
built hamlib files, but not in the places I had expected. My mistake.
I have now changed the "--prefix=..." part of the command that invokes
autogen.sh to read "--prefix=C:/JTSDK-QT/hamlib3/mingw32", and all
HI Bill,
I agree, personally, I would set, if building for JTSDK-QT, the
--prefix=C:/JTSDK-QT/hamlib3/mingw32
that should produce: ../hamlib3/mingw32/{bin,include,lib,share} and the
associated sub-folders.
I'm not sure if MSYS comes with pkg-config or not. The SDK's have it in
the tools director
On 24/09/2014 16:59, KI7MT wrote:
Hi Greg,
> Hi Joe,
>
> If you used the MSYS shell, $HOME/hamlib-prefix is going to be in your
> MSYS /home/joe directory, probably not the Windows User path, something
> like:
>
> C:/MSYS/home/joe/hamlib-prefix
Ah OK, I thought only Cygwin did that sort of stuff.
Hi Joe,
If you used the MSYS shell, $HOME/hamlib-prefix is going to be in your
MSYS /home/joe directory, probably not the Windows User path, something
like:
C:/MSYS/home/joe/hamlib-prefix
or wherever your MSYS installation is, possibly under
C:/MinGW/MSYS/home/joe/.. .. ..
Wherever the prefix p
On 24/09/2014 15:05, Joe Taylor wrote:
> Hi Bill,
Hi Joe,
>
> Some feedback on your build procedure for hamlib on Windows.
>
> I followed your suggested procedure:
>
>> In an MSYS shell:-
>>
>> mkdir ~/hamib-prefix
>> cd ~/hamlib-prefix
>> git clone git://git.code.sf.net/u/bsomervi/hamlib src
>> cd
Hi Bill,
Some feedback on your build procedure for hamlib on Windows.
I followed your suggested procedure:
> In an MSYS shell:-
>
> mkdir ~/hamib-prefix
> cd ~/hamlib-prefix
> git clone git://git.code.sf.net/u/bsomervi/hamlib src
> cd src
> git checkout integration
> mkdir ../build
> cd ../build
Hi Bill,
Thanks for corrected Mac script for new hamlib3.
WSJT-X 1.4.0-rc1 r4345 running OK with new hamlib3 on Mac with 10.9.4 (Debug
version at present.)
--- John G4KLA
--
Meet PCI DSS 3.0 Compliance Requirements wi
An update for Mac builders.
It appears that the Mac clang LLVM compilers do not support the
function-sections, data-sections and, gc-sections options so those
should be omitted on Mac builds. they probably only make sense for ELF
binary targets anyway which is not the case on OS-X anyway so if
Hi All,
I have just pushed the latest updates I've made to Hamlib 3 to my public
fork of the project. These changes are not yet fully completed so I have
not submitted them to the hamlib team yet.
Also I intended to change the WSJT-X compile and link commands in the
CMake script to ensure any
On 27/04/2014 19:22, Chuck Forsberg WA7KGX wrote:
Hi Chuck,
> The new hamlib fork seems to work with my 756PRO
> and wsjtx r4065. I have not tried split yet.
OK, I would appreciate a test with split even if you don't intend to
operate that way. I would like to find out what caused the issues you
The new hamlib fork seems to work with my 756PRO
and wsjtx r4065. I have not tried split yet.
On the FT-817nd, I turned off the LOCK and it seems to
work also. With a cat that freely roams the desktop
the LOCK function gets a fair amount of use.
On 04/27/2014 06:49 AM, Bill Somerville wrote:
>
Hi All,
My fork of Hamlib-3 has diverged again from the official master. The
change only effects the Icom IC-756Pro rig, that's the Pro not the Pro
II or Pro III.
If this is your rig you need to update your git workspace and rebuild
Hamlib. For those unfamiliar with git:
cd .../src/u-bsomervi
22 matches
Mail list logo
