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 directory now (not the Qt5\Tools, rather JTSDK-QT/tools), but
when using MSYS env, I doubt that pgk-config is on the path unless it's
installed on / in MSYS also.
There's a side affect that will need addressing in the JTSDK-QT update
script. If the april-2014.txt goes missing, or is deleted, the update
script will copy what's in SVN back over to JTSDK-QT/hamlib3 which is
the build from April-2014, so be aware of that. Setting the SDK prefix
path should *not* delete that file, so from that aspect, things should
be ok.
73's
Greg, KI7MT
On 9/24/2014 16:08, Bill Somerville wrote:
> 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. I must have changed
> my MSYS profile to have the $HOME (~) at the same place as
> %HOMEDRIVE%%HOMEPATH%
>>
>> or wherever your MSYS installation is, possibly under
>> C:/MinGW/MSYS/home/joe/.. .. ..
>>
>> Wherever the prefix path is set too during configure, you'll need to
>> update JTSDK-QT toolchain.cmake file to match that path, something like:
>>
>> C:/Mingw/msys/home/joe/hamlib-prefix
>>
>> if using the build example.
> Alternatively set the install prefix to the place that JTSDK-QT expects
> to find the hamlib installation, that way the PkgConfig file in hamlib
> will be correct. Either way is fine. Moving the hamlib installation post
> install is not the right way to go as it breaks it.
>>
>> 73's
>> Greg, KI7MT
> 73
> Bill
> G4WJS.
>>
>> On 9/24/2014 14:05, Joe Taylor wrote:
>>> 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
>>>> ../src/autogen.sh --prefix=$HOME/hamlib-prefix \
>>>> --disable-shared --enable-static \
>>>> --without-cxx-binding --disable-winradio \
>>>> CC=<path-to-Qt-MinGW-tools>/gcc \
>>>> CXX=<path-to-Qt-MinGW-tools>/g++ \
>>>> CFLAGS="-fdata-sections -ffunction-sections" \
>>>> LDFLAGS="-Wl,--gc-sections"
>>>> make
>>>> make install
>>> Since I have Greg's JTSDK-QT installed, for "<path-to-Qt-MinGW-tools>" I
>>> substituted "C:/JTSDK-QT/qt5/Tools/mingw48_32/bin".
>>>
>>>> this will leave a hamlib binary package installed at
>>>> c:/Users/<user-name>/hamlib-prefix which is what needs to be on your
>>>> CMAKE_PREFIX_PATH. On Windows you almost certainly will be using a CMake
>>>> toolchain file and this is where you will need to specify the hamlib
>>>> binary location as one of the paths in CMAKE_PREFIX_PATH.
>>> Both "make" and "make install" ran to completion without errors.
>>> I find no hamlib binary package installed at
>>> c:/Users/<user-name>/hamlib-prefix :
>>>
>>> joe@phy-joe ~/hamlib_g4wjs
>>> $ ls -l
>>> total 24
>>> drwxr-xr-x 50 joe Administrators 8192 Sep 24 09:11 build
>>> drwxr-xr-x 58 joe Administrators 16384 Sep 24 09:05 src
>>>
>>> However, I do find libhamlib.a and libhamlib.la in
>>> .../build/src/.libs, and after copying them to their normal location in
>>> Greg's JTSDK-QT, WSJT-X seems to build correctly. (The build was,
>>> however, using the old (4/2/2014) include files, and perhaps other parts
>>> of the April 2014 build of hamlib.)
>>>
>>> So...
>>>
>>> 1. Has something in "make install" failed to work for me as you expected?
>>>
>>> 2. I see no use of CMAKE_PREFIX_PATH anywhere in CMakeLists.txt, and
>>> inserting the line
>>> set (CMAKE_PREFIX_PATH C:/Users/Joe/hamlib_g4wjs)
>>> at the top of CMakeLists.txt seems to do nothing. Have I got something
>>> wrong here?
>>>
>>> -- Joe, K1JT
>>>
>>> ------------------------------------------------------------------------------
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> wsjt-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> wsjt-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
73's
Greg, KI7MT
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
