Thanks for the pointer to pkgconfig. If you are updating the instructions, you'll need the extra info as follows.
NB: in addition to the files in that zip, you also need two other DLLs as per steps 4 - 8 below: 1. go to http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/ 2. download the file pkg-config_0.26-1_win32.zip<http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/pkg-config_0.26-1_win32.zip> 3. extract the files to c:\programs\pk-config_0.26-1_win32 4. download the file gettext-runtime_0.18.1.1-2_win32.zip<http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/gettext-runtime_0.18.1.1-2_win32.zip> 5. extract JUST the file bin/intl.dll to c:\programs\pk-config_0.26-1_win32\bin 6. go to http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.28 7. download file glib_2.28.8-1_win32.zip<http://ftp.acc.umu.se/pub/gnome/binaries/win32/glib/2.28/glib_2.28.8-1_win32.zip> 8. extract JUST the file bin/libglib-2.0-0.dll to c:\programs\pk-config_0.26-1_win32 Meanwhile, getting pkgconfig fixed the cmake step, but now MSBUILD step is reporting errors such as: libusb-1.0.lib(core.obj) : error LNK2001: unresolved external symbol __imp__iob [C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj] libusb-1.0.lib(core.obj) : error LNK2019: unresolved external symbol __imp__vsnprintf referenced in function usbi_log_v [C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj] libusb-1.0.lib(core.obj) : error LNK2019: unresolved external symbol __imp__snprintf referenced in function usbi_log_v [C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj] libusb-1.0.lib(windows_usb.obj) : error LNK2001: unresolved external symbol __imp__snprintf [C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj] libusb-1.0.lib(windows_usb.obj) : error LNK2019: unresolved external symbol __imp_sprintf referenced in function guid_to_string [C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj] libusb-1.0.lib(windows_usb.obj) : error LNK2019: unresolved external symbol __imp_sscanf referenced in function force_hcd_device_descriptor [C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj] C:\local\hackrf-master\host\build\libhackrf\src\Debug\hackrf.dll : fatal error LNK1120: 5 unresolved externals [C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj] Thanks for any suggestions. Jake ________________________________ From: Dominic Spill <[email protected]> Sent: February 13, 2017 12:13:06 PM To: Gavin Jacobs Cc: [email protected] Subject: Re: [Hackrf-dev] release 2017.02.1 On 13 February 2017 at 11:56, Gavin Jacobs <[email protected]<mailto:[email protected]>> wrote: > > I looked at your build output here: > https://ci.appveyor.com/project/mossmann/hackrf/build/job/2muwvs91hw1g3w6m > > My attempt matches yours up to line 97; but on line 98 yours says: > -- Found PkgConfig: C:/pkg-config/bin/pkg-config.exe > > and mine says: > -- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE) > > I suspect this is a prerequisite that is not mentioned in the instructions, > so your example has helped. I tried to find pkgConfig for Windows, but there > wasn't any obvious choice. Which version do you use? Ah, I see the problem, the build instructions don't mention pkg-config, I'll fix that. I used this version of pkg-config: http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/pkg-config_0.26-1_win32.zip You will also need to pass the location of pkg-config to cmake, something like this: -DPKG_CONFIG_EXECUTABLE="C:\pkg-config\bin\pkg-config.exe" You can see our Appveyor config here, which is probably more up to date than the build instructions in the readme file: https://github.com/mossmann/hackrf/blob/master/appveyor.yml That includes the download of the prerequisites in the "install" section, followed by the cmake and msbuild steps below it. Thanks, Dominic > ________________________________ > From: Dominic Spill <[email protected]<mailto:[email protected]>> > Sent: February 13, 2017 10:08:15 AM > To: Gavin Jacobs > > Cc: [email protected]<mailto:[email protected]> > Subject: Re: [Hackrf-dev] release 2017.02.1 > > On 13 February 2017 at 09:35, Gavin Jacobs > <[email protected]<mailto:[email protected]>> wrote: > > > > I have a dual boot computer (Windows and Ubuntu). So, I could use the > > Ubuntu system to update the firmware, but would I need to update hackrf > > host on both OS? > > That's correct. You can also use the hackrf_spiflash tool under Windows to > update the firmware, once you have it built. > > > If yes, then I would like to hear from anyone who has actually built the > > latest hackrf host tools on Windows. The instructions on the git site don't > > work, so I'm looking for someone who has made it work. And if such a person > > can be found, can you post the procedure? Or can you simply post the > > binaries? > > I have built the HackRF tools on a Windows system recently and I have also > set up automated builds using Appveyor: > https://ci.appveyor.com/project/mossmann/hackrf > > Could you give more details on what doesn't work with the instructions and I > will attempt to fix them. > > Thanks, > Dominic > > ______________________________ > > From: HackRF-dev > > <[email protected]<mailto:[email protected]>> > > on behalf of Rustu Yucel > > <[email protected]<mailto:[email protected]>> > > Sent: February 11, 2017 10:22:34 PM > > To: Michael Ossmann > > Cc: > > [email protected]<mailto:[email protected]> > > Subject: Re: [Hackrf-dev] release 2017.02.1 > > > > Thanks for new firmware! But how about update with Windows OS? > > > > Sent from my iPhone > > > > > On 12 Feb 2017, at 05:16, Michael Ossmann > > > <[email protected]<mailto:[email protected]>> wrote: > > > > > > Brian, > > > > > > That's great to hear! My guess is that it was the reduction of power > > > consumption that helped. Have you tried running your HackRF off a > > > powered hub? > > > > > > Mike > > > > > > > > >> On Sat, Feb 11, 2017 at 06:59:15PM -0700, Brian Gieryk wrote: > > >> > > >> Before the update, I was running the Hackrf in GQRX on a Raspberry Pi 3B. > > >> > > >> Input rate was 1 Msps, I could only run narrow fm, and I could not run > > >> DSP and use my mouse at the same time. In other words, performance was > > >> all but unusable... > > >> > > >> After the update, I can now run 1.5 Msps, my mouse functions, and Wide > > >> fm is not great, but it is not overloading the cpu any longer. In other > > >> words, useability increased by a factor of 10, at least! > > >> > > >> Thank you very much to the development team that made this happen! > > >> > > >> Brian > > >> KE6IYC > > >> > > >> Sent from my iPhone > > >> > > >>> On Feb 11, 2017, at 15:33, Michael Ossmann > > >>> <[email protected]<mailto:[email protected]>> wrote: > > >>> > > >>> Release 2017.02.1 is tagged in git with packages available for download: > > >>> > > >>> https://github.com/mossmann/hackrf/releases > > >>> > > >>> > > >>> HackRF 2017.02.1 Release Notes > > >>> > > >>> To upgrade to this release, you must update libhackrf and hackrf-tools > > >>> on your > > >>> host computer. You must also update firmware on your HackRF. It is > > >>> important > > >>> to update both the host code and firmware for this release to work > > >>> properly. > > >>> If you only update one or the other, you may experience unpredictable > > >>> behavior. > > >>> > > >>> Major changes in this release include: > > >>> > > >>> - Sweep mode: A new firmware function enables wideband spectrum > > >>> monitoring by > > >>> rapidly retuning the radio without requiring individual tuning requests > > >>> from > > >>> the host computer. The new hackrf_sweep utility demonstrates this > > >>> function, > > >>> allowing you to collect spectrum measurements at a sweep rate of 8 GHz > > >>> per > > >>> second. Thanks to Mike Walters, author of inspectrum, for getting this > > >>> feature working! > > >>> > > >>> - Hardware synchronization: It is now possible to wire the expansion > > >>> headers of > > >>> two or more HackRF Ones together so that they start sampling at the same > > >>> time. This is advantageous during phase coherent operation with clock > > >>> synchronized HackRFs. See the -H option of hackrf_transfer. Thank > > >>> you, Mike > > >>> Davis! > > >>> > > >>> - A new utility, hackrf_debug, replaces three older debug utilities, > > >>> hackrf_si5351c, hackrf_max2837, and hackrf_rffc5071. > > >>> > > >>> - Power consumption has been reduced by turning off some microcontroller > > >>> features we weren't using. > > >>> > > >>> There have been many more enhancements and bug fixes. For a full list > > >>> of > > >>> changes, see the git log. > > >>> > > >>> Special thanks to Dominic Spill who has taken over much of the software > > >>> development effort and has helped with nearly every improvement since > > >>> the > > >>> previous release! > > >>> _______________________________________________ > > >>> HackRF-dev mailing list > > >>> [email protected]<mailto:[email protected]> > > >>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > > _______________________________________________ > > > HackRF-dev mailing list > > > [email protected]<mailto:[email protected]> > > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > _______________________________________________ > > HackRF-dev mailing list > > [email protected]<mailto:[email protected]> > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > > > _______________________________________________ > > HackRF-dev mailing list > > [email protected]<mailto:[email protected]> > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > > > _______________________________________________ > HackRF-dev mailing list > [email protected]<mailto:[email protected]> > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev >
_______________________________________________ HackRF-dev mailing list [email protected] https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
