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
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
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 src
git
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
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 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
autogen.sh to
On 24/09/2014 17:50, KI7MT wrote:
Hi Greg,
Hi Joe,
On 9/24/2014 16:31, Joe Taylor wrote:
snip
The only complaint issued by any of the scripts is this one from the
JTSDK-QT command build wsjtx package:
###
CPack: Create
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:
snip
The only complaint issued by any of the scripts is this one from the
JTSDK-QT command build wsjtx package:
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
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 don't think
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 version of
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 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
13 matches
Mail list logo
