Building From Source: Getting CMake error

[scancapecod]

Hi,

I am trying to learn how to build from source, using the tutorial at this link: https://github.com/Nuand/bladeRF/wiki/G ... rom_source

I have followed the instructions, but left out steps 3-9 under the "Installing libusbx" section as I already have an installed bladeRF on the PC I'm working with (I used the Windows Installer to initially set it up back in January). If this is what's steering me wrong I feel like a dope.

I get to the point where I run CMake, point myself to the source code and where to build the binaries, select Visual Studio 12 (2013), and click Finish to start the configuration. Off it goes, only to halt with the following error:

Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
C:/Program Files (x86)/Project/lib does not exist. Defaulting libbladeRF install location to C:/Program Files (x86)/Project/lib.
CMake Error at host/libraries/libbladeRF/CMakeLists.txt:168 (message):
libusb-1.0 not found. This is required to use the libbladeRF libusb
backend. For binary releases, try setting LIBUSB_PATH.


Configuring incomplete, errors occurred!
See also "C:/bladerf/host/build/CMakeFiles/CMakeOutput.log".
See also "C:/bladerf/host/build/CMakeFiles/CMakeError.log".

Well, there are no errors in either of the above logs that I can see, but neither of the two listed folders under the above "could NOT find" line exist on my PC because I had no instructions to do so.

In all likelihood I'm doing something wrong, or there's a step missing from the tutorial. Can anyone point me in the right direction?

Thanks.

[scancapecod]

OK, I think I see that it's bonking at CMAKE_INSTALL_PREFIX which points to C:/Program Files (x86)/Project which isn't there. It's looking for libusb-1.0 content that isn't there, I guess.

[jynik]

Hi there Scott,

Allow me to explain each of the things you saw here, and hopefully steer you back on course...

Code: Select all

Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE) 

pkg-config is a tool used to get some information about an installed package, such as where its files are and compiler/linker flags required when building against a library. In the case of libbladeRF, this is generally only used in Linux and OSX, so it's just a harmless status message in Windows -- no need to worry about this one.

Code: Select all

C:/Program Files (x86)/Project/lib does not exist. Defaulting libbladeRF install location to C:/Program Files (x86)/Project/lib.

Don't worry about this one just yet. Things are still being worked on for the Windows installer side of things, so I don't believe this is terribly relevant. When all is built, you can just take the bladeRF.dll and executables from the build directory and plop them wherever you'd like.

Code: Select all

CMake Error at host/libraries/libbladeRF/CMakeLists.txt:168 (message):
libusb-1.0 not found. This is required to use the libbladeRF libusb
backend. For binary releases, try setting LIBUSB_PATH.

Here's the one that's causing things to grind to a halt. CMake is looking for the libusb contents that you would have installed in C:\Program Files (x86)\libusb-1.0.18\ during steps 1 and 2 of the "Installing libusb(x)" portion of guide.

In the CMake window, double check that the LIBUSB_PATH entry and ensure this matches the path to the libusb folder you unzipped earlier. (This libusb folder is the one containing directories such as: examples, include, MINGW32, MS64, etc.) This defaults to C:/Program Files (x86)/libusb-1.0.18, which may not necessarily be the same place you decided you'd like to place the libusb files.

Hope that helps!
Jon

[jynik]

I have followed the instructions, but left out steps 3-9 under the "Installing libusbx" section as I already have an installed bladeRF on the PC I'm working with (I used the Windows Installer to initially set it up back in January). If this is what's steering me wrong I feel like a dope.

Ah - I glossed over this detail earlier. This is definitely the problem. Please don't feel like a "dope" though, it's non-obvious and I'll explain here...

Generally, to use a library you just need the shared library (a DLL in windows). However, to develop and build against it, you need some other files: header files to let you know what functions and parameters are present, perhaps debug symbols, etc.

When you previously used the Windows installer, it only ships with the DLL and not the development files. (No need to ship lots and lots of unneccessary files with an installer, right?)

When you want to build from source, we need those extra development files. This is what the "Installing libusbx" section is mainly all about.

So all you should have to do is go back and do steps 3-9, then try again. In general, my advice to people is to not skip steps in the guides. When writing these, I generally try to avoid excessive steps or will try to mark things optional when relevant; otherwise assume it's needed.

If you feel something is unclear in the guides, always feel free to either update the wiki or bring it to someone's attention on here or on IRC. If you have a question, at least a handful of people have the exact same question, so it should get addressed up front.

Cheers!
Jon

[scancapecod]

Thanks Jon,

So as not to blow up my stable setup I'll restart this project on another 64 bit Windows 8.1 PC and follow it through its entirety. I appreciate the help. Figures it's the one thing I left out!

[jynik]

Hi Scott,

I can certainly understand wanting to keep a stable setup!

For what it's worth, there should be no issue with just removing the git repository you checked out and starting back at step 1.

Technically, you could do a 'git clean' to remove any files not checked into the respository (e.g., the build directory), and a 'git checkout -f' to revert any files you may have changed back to their state in their state. Tortoise-git has some slightly different terminology, in an attempt to make their GUIs consistent across revision control tools, I believe. I think they have a "revert" option and a "clean" option, though.

Once you have something built from source that you're happy with, you can always tuck away the contents of the build/output directory somewhere safe (preferably with the FPGA image and firmware image associated with them...just in case). This way, you'll have something to sanity check with the next time you go to do an update.

Best of luck!
Jon

[scancapecod]

Just as a followup, this worked flawlessly for me this morning on a Windows 7 Pro 32 bit laptop. Now I'll go back to the main machine and try it again. I know this is "in your sleep" stuff for you folks, but for someone that knows zilch about programming and compiling it's a victory for me.

Thanks Jon.

[scancapecod]

OK, I've completed this on a 64 bit machine now, but my observation is that there is no difference in the procedure than there is on a 32 bit PC.

Is this normal or do I have to do something different to build an x64 version of this? Or, does that even matter? Sorry for the novice questions.

[jynik]

I don't have a whole bunch of experience on the Windows or Visual Studio side of things...but I'll take a stab at answering this. Please correctly if I'm even mildy wrong on anything!

The difference in the procedure would be when you first hit "Configure" in CMake, and are presented with the pop-up that states, "Specify the generator for this project." If you recall, there's a dropdown for various compilers and versions, with a "Use default native compilers" radio button selected by default.

When you select the compiler, you choose either the 32-bit version (e.g., Visual Studio 11), or the 64-bit version (e.g., Visual Studio 11 Win64). CMake should generate a Visual studio solution (Microsoft's name for a group of projects, I guess) file set up for what you specified.

However, once you're in Visual Studio, you can add and modify the various build configurations to your heart's content. Some googling and searching around MSDN will lead you to various documentation regarding this.

As an aside, it's moderately confusing to me that Visual Studio 11 is the 2012 version. However, I see that in CMake 3.0.0, they now list it as "Visual Studio 11 2012" rather than just "Visual Studio 11" to help alleviate that confusion.

No need to apologize for asking questions - this is why we have the forums!

[scancapecod]

Yep, that did it, the choice of the x64 version. The current version is "Visual Studio Express 13 for Windows Desktop"...which translates to "Visual Studio 12 2013" in CMake. I chose the X64 option and the end result when I tried to run bladerf-cli on the 32 bit machine it very nicely told me to go screw. Moving the files to the 64 bit PC next to this one resulted in it working fine.

Nifty, thanks!