[USRP-users] Boost modules not showing / Error when opening USRP

Josh Blum josh at ettus.com
Thu Sep 5 18:39:55 EDT 2013

On 09/04/2013 11:31 PM, Felix W. wrote:
> 2013/9/5 Josh Blum <josh at ettus.com>
>>> CMake configuring went smoothly but when I compiled there were errors for
>>> the tests about undefined symbols - obviously the boost unit test
>> framework
>>> lib was not found. After examining the CMake output I  noticed that
>>> although FindBoost found the Boost headers and the correct path to all
>> the
>>> lib files (including unit test framework), no Boost libraries are shown
>>> after "Boost libraries:". I guess, this is not expected behavior?
>> Just the print to stdout during cmake configure is blank, correct?
>> The build will use static linking with boost by default. In this case,
>> it wont print anything for boost libraries. And there is a define passed
>> to the build to control boost linking -- through magic MSVC #pragmas
>> So I think there is nothing to worry about here. :-)
> Okay, good to know. I'm still wondering about libboost_unit_test_framework
> not being found as the examples which use libboost_program_options that are
> also not header-only compile and execute without problems. Might it be an
> issue with my 1.54.0 boost installation?

Possibly. The FindBoost.cmake is looking for specific file names with
specific suffixes. Obviously its found most of the libraries. So its
possible you are missing libboost_unit_test_framework, or perhaps with
the expected suffix. Debug/release, single/multi-thread, and other
options all have different suffixes on their file names. Suffixes look
like vc100-mt-1_54.dll or vc100-mt-gd-1_54.dll and so on like that.

>>> After disabling the tests, compiling went fine. However, the progress is
>>> still limited. When executing [1], I get an access violation error
>> reading
>>> at 0x0 after the make() command. In Debug mode, the program runs on and I
>>> was even able to transmit some stuff, but it directly terminates in
>> Release
>>> mode.
>> Are you mixing a library built for Debug mode with an executable built
>> for Release mode? Perhaps by accident, like have you built UHD from
>> source, but there is a uhd.dll installed in the %PATH% from the official
>> UHD installer? Basically, any sort of mixing means an ABI
>> incompatibility, and things will bomb out very quickly.
> Thanks for the hint, that did the trick! The release version works now,
> too. But VS still shows me this access violation error (although it's not
> visible during execution in a 'cmd' window and everything runs as
> expected). Do I have to worry about this?

I wouldnt worry, but it might be worth figuring it out in the future.
Its still probably an issue of something unexpected in the PATH taking
precedence when the app is executed through MSVC vs the plain command
shell. Just a guess.


> Felix
>> -josh
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

More information about the USRP-users mailing list