A couple potential fixes, per request on IRC

Per your request in IRC, I just took a quick look at this and wanted to offer any feedback I could. (Pardon anything silly, it's rather late and I can't sleep! :P )

The bad news is that I'm seeing this lock up the kernel driver. It'd be worth getting mIKEjONES to take a look at this -- let's poke him on IRC and have him try to run this. 

Fortunately the dev-libusb_support is coming along. If you want to check out that branch, I think you should only need to change your bladerf_open() and bladerf_send_c16() to a bladerf_tx().

Here's a quick list of changes and rationale:
 - bm was uninitialized when getting passed to bladerf_enable_module(). This is likely one contributing factor in why you didn't see anything. Looking at linux/lib/src/bladerf.c, I see that it's missing a default case that results in a return value of BLADERF_ERR_INVAL...I'll add that so the next guy that encounters this at least gets an error from the library!
 - Added gain configurations since I believe TXVGA2 is @ 0 after loading the FPGA. You may know more about the gain setup that I do....I usually bug bpadalino ;)
 - Added a couple makefiles...just because!
 - Changed 'samples_per_buffer' -- It looks like you already accounted for the *2. I thought the driver required 1024 samples (2 * 1024 int16_t's = 4096 bytes) for read/send...but I may be wrong.
 - stdbool.h because I'm anal?

Hope this helps to some degree. If you see the kernel lockups too, I'll bring this up to date with the libusb stuff to see if that will at least allow you to progress while some driver debug takes place...