[Hackrf-dev] release 2017.02.1

Tue Feb 14 15:39:20 EST 2017

I now have the host tools working on Windows 10. Thanks to Dominic for assistance. If you want to update the Windows build instructions, I would be happy to test them out. Or if you would like a copy of the binaries, just let me know how to upload to the wiki.

Using Windows 10, I updated the firmware and CPLD on my HackRF One. Here is the output:

C:\local\hackrf\hackrf_tools>hackrf_info
hackrf_info version: unknown
libhackrf version: unknown (0.5)
Found HackRF
Index: 0
Serial number: 00000000000000******************   {actual s/n obfuscated by me}
Board ID Number: 2 (HackRF One)
Firmware Version: 2017.02.1 (API:1.02)
Part ID Number: 0xa000cb3c 0x005d475a

So just one minor question left: should the version numbers for hackrf_info and libhackrf show as 'unknown'?

________________________________
From: Dominic Spill <dominicgs at gmail.com>
Sent: February 14, 2017 9:20:59 AM
To: Gavin Jacobs
Subject: Re: [Hackrf-dev] release 2017.02.1

I tracked this down very late last night.  You are using the static version of libusb and I'm using the DLL. libusb-1.0.18-win\MS64\static\libusb-1.0.lib vs libusb-1.0.18-win\MS64\dll\libusb-1.0.lib

The tricky part was working out why this matters.  It turns out that Visual Studio 14 2015 has changed the way that some functions are linked, most notably the stdio.h functions, this wouldn't be a problem with binaries built with the same compiler or dynamically linked libraries, but when linking to a static library built with the different versions of the function, it causes a problem.

There are two fixes to this:
1) Use the dll version
2) Add legacy_stdio_definitions.lib to the linked libraries

Option 2 doesn't entirely solve it and there are some required code changes.  I recommend using the dll for now.

Thanks,
  Dominic

On 14 February 2017 at 08:19, Gavin Jacobs <apriljunkbox at hotmail.com<mailto:apriljunkbox at hotmail.com>> wrote:

Dominic,

Further to your questions:

I believe I have the latest version. I downloaded hacrkf-master.zip and all the files within are timestamped 2017-02-11 11:24.

Here is my CMAKE command (executed from C:\local\hackrf-master\host\build )

cmake ../ -G "Visual Studio 14 2015 Win64" -DLIBUSB_INCLUDE_DIR=c:\local\libusb-1.0.18-win\include\libusbx-1.0 -DLIBUSB_LIBRARIES=c:\local\libusb-1.0.18-win\MS64\static\libusb-1.0.lib -DTHREADS_PTHREADS_INCLUDE_DIR=c:\local\pthreads-w32-2-9-1-release\Pre-built.2\include -DTHREADS_PTHREADS_WIN32_LIBRARY=c:\local\pthreads-w32-2-9-1-release\Pre-built.2\lib\x64\pthreadVC2.lib -DPKG_CONFIG_EXECUTABLE=C:\local\pkg-config_0.26-1_win32\bin\pkg-config.exe

The only difference I see is the libusb version (1.0.18-win vs. 1.0.21).

Thanks,

Jake

________________________________
From: Dominic Spill <dominicgs at gmail.com<mailto:dominicgs at gmail.com>>
Sent: February 13, 2017 5:42:27 PM
To: Gavin Jacobs
Subject: Re: [Hackrf-dev] release 2017.02.1

On 13 February 2017 at 17:11, Gavin Jacobs <apriljunkbox at hotmail.com<mailto:apriljunkbox at hotmail.com>> wrote:
>
> Thanks for the pointer to pkgconfig. If you are updating the instructions, you'll need the extra info as follows.

I've been experimenting with this today and I've discovered that the pkg-config thing is my fault, you shouldn't need it for the Windows build, but I made an error in the config that complains if you don't have it.
>
> NB: in addition to the files in that zip, you also need two other DLLs as per steps 4 - 8 below:
>
> go to http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/
> download the file pkg-config_0.26-1_win32.zip
> extract the files to c:\programs\pk-config_0.26-1_win32
> download the file gettext-runtime_0.18.1.1-2_win32.zip
> extract JUST the file bin/intl.dll to c:\programs\pk-config_0.26-1_win32\bin
> go to http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.28
> download file glib_2.28.8-1_win32.zip
> extract JUST the file bin/libglib-2.0-0.dll to c:\programs\pk-config_0.26-1_win32

This is strange, I don't need these at all.  Although I've just discovered that none of my executables work.

> 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]

I seem to remember having these issues, but they should have been resolved recently.  Are you building from the 2017.02.1 release package?

Could you send me your cmake command line?  Mine is:
PS C:\Program Files\hackrf_all\bin> cmake.exe ../ -G "Visual Studio 14 2015 Win64" -DLIBUSB_INCLUDE_DIR=C:\src\libusb-1.0.21\include\libusb-1.0\ -DLIBUSB_LIBRARIES=C:\src\libusb-1.0.21\MS64\dll\libusb-1.0.lib -DTHREADS_PTHREADS_INCLUDE_DIR=C:\src\pthreads-w32-2-9-1-release\Pre-built.2\include\ -DTHREADS_PTHREADS_WIN32_LIBRARY=C:\src\pthreads-w32-2-9-1-release\Pre-built.2\lib\x64\pthreadVC2.lib -DPKG_CONFIG_EXECUTABLE=C:\src\pkg-config_0.26-1_win32\bin\pkg-config.exe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170214/4133b731/attachment.html>