[Hackrf-dev] release 2017.02.1
Dominic Spill
dominicgs at gmail.com
Tue Feb 14 16:10:32 EST 2017
On 14 February 2017 at 13:39, Gavin Jacobs <apriljunkbox at hotmail.com> wrote:
>
> 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'?
This is because of the source archive that you downloaded (github makes
this a little confusing). When building from a git repository we detect
the git commit and use it for the version string, when we package a release
we replace the string with the release version string. Unfortunately, when
we tag a release GitHub produces two source archives that are neither git
repositories nor have the string updated, so you get the fallback version
string of "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>
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>
>> 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>
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
>>
>
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170214/f71562ba/attachment.html>
More information about the HackRF-dev
mailing list