Just wanted to follow up on this, because I thought of something in the
shower this morning.
If you compile your block controller as a shared library and you want your
block to be initialized/used with the default UHD apps, you can use
LD_PRELOAD to ensure the block registration happens at runtime. For
instance:
$ LD_PRELOAD=/usr/local/lib/librfnoc-clabs.so uhd_usrp_probe
--args=addr=192.168.10.2
...if your RFNoC controller is registered inside that .so, it will be
loaded and registered for uhd_usrp_probe.
Just a helpful trick if you want to (for instance) use rfnoc_rx_to_file to
test your block, since it has the option to specify a custom block to
insert between the radio and the host.
Nick
On Tue, Apr 9, 2019 at 10:51 AM John Medrano <john.d.medr...@gmail.com>
wrote:
> Thank you.
>
> Using:
>
> set(RFNOC_MYMOD_LIB_OPT -Wl,--whole-archive rfnoc-mylib
> -Wl,--no-whole-archive)
> target_link_libraries(rfnoc_myapp ${RFNOC_MYMOD_LIB_OPT} <...the rest of
> your libs...>)
>
> We are able to use our controller.
>
> On Mon, Apr 8, 2019 at 11:52 AM Nick Foster <bistrom...@gmail.com> wrote:
>
>> OK, I looked further into it. UHD registers out-of-tree block controllers
>> using the UHD_RFNOC_BLOCK_REGISTER macro, which under the hood creates a
>> static function and a fixture which calls it before main(). Problem is,
>> when linking your out-of-tree executable, the linker sees that the static
>> fixture is never explicitly called from your program, and it optimizes it
>> out. So your block is never getting registered.
>>
>> There's a number of ways to fix it. I don't know how UHD does it
>> internally. If you are linking your library statically, you can do
>> something like the following in the CMakeLists.txt for the application (not
>> the library):
>>
>> set(RFNOC_MYMOD_LIB_OPT -Wl,--whole-archive rfnoc-mylib
>> -Wl,--no-whole-archive)
>> target_link_libraries(rfnoc_myapp ${RFNOC_MYMOD_LIB_OPT} <...the rest of
>> your libs...>)
>>
>> Using --whole-archive will force the linker to include all the contents
>> of your custom static lib in the application. This includes the static
>> constructor.
>>
>> If you're linking dynamically, this may or may not be a problem for you.
>> If it is, you can do something like
>> set_target_properties(rfnoc_myapp PROPERTIES LINK_WHAT_YOU_USE TRUE)
>>
>> ...which sets the -Wl,--no-as-needed linker flag, indicating to the
>> linker that it should include dynamic libraries that aren't explicitly
>> called. This isn't a great solution as it can result in linking to
>> libraries which really aren't used.
>>
>> You can debug this approach by calling the UHD_STATIC_BLOCK macro in your
>> library and just having it print something to stdout. If you don't see the
>> print in your application, it's not linking static objects correctly.
>>
>> Nick
>>
>> On Mon, Apr 8, 2019 at 8:24 AM John Medrano <john.d.medr...@gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> We have verified that library is being linked.
>>>
>>> When we run nm <program name> | grep <block name>
>>>
>>> We see the following:
>>> 0000000000030310 W _ZNK3uhd7device314get_block_ctrlINS_5rfnoc19<block
>>> name>_block_ctrlEEEN5boost10shared_ptrIT_EERKNS2_10block_id_tE
>>> 000000000023d6e0 V _ZTIN3uhd5rfnoc19<block name>_block_ctrlE
>>> 0000000000034b00 V _ZTSN3uhd5rfnoc19<block name>_ctrlE
>>>
>>> We continue to get same error.
>>>
>>> We have several blocks and we tried with all of them with same result.
>>>
>>>
>>> On Wed, Mar 27, 2019 at 4:36 PM Nick Foster <bistrom...@gmail.com>
>>> wrote:
>>>
>>>> Make very sure that your program is actually linking in the library
>>>> correctly. Linkers are weird and their interaction with build systems is
>>>> often unpredictable and sometimes perverse. Find the symbols in the
>>>> compiled library with nm and see that they aren't undefined. Use make
>>>> VERBOSE=1 to see the library actually being used.
>>>>
>>>> Nick
>>>>
>>>> On Wed, Mar 27, 2019 at 2:55 PM John Medrano <john.d.medr...@gmail.com>
>>>> wrote:
>>>>
>>>>> Thank you for the response.
>>>>>
>>>>> I have added to CMakeList.txt:
>>>>>
>>>>> find_library(SLADEW_LIB gnuradio-SLADEW)
>>>>> if(NOT SLADEW_LIB)
>>>>> message(FATAL_ERROR "SLADEW library not found")
>>>>> endif()
>>>>>
>>>>> add later I add:
>>>>>
>>>>> target_link_libraries(rfnoc_freqmod ${UHD_LIBRARIES}
>>>>> ${Boost_LIBRARIES} ${SLADEW_LIB})
>>>>>
>>>>> It compiles fine but I still get same messages on start up.
>>>>>
>>>>> Please advise:
>>>>> John
>>>>>
>>>>>
>>>>> On Wed, Mar 27, 2019 at 3:00 PM Nick Foster <bistrom...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Your program needs to be linked against the library which your custom
>>>>>> block controller is compiled into, if in fact your block is using a
>>>>>> custom
>>>>>> block controller.
>>>>>>
>>>>>> uhd_usrp_probe and the other UHD utilities aren't linked against the
>>>>>> custom library. This isn't generally a problem since the utilities and
>>>>>> examples don't make use of your custom block.
>>>>>>
>>>>>> Nick
>>>>>>
>>>>>> On Wed, Mar 27, 2019, 1:26 PM John Medrano via USRP-users <
>>>>>> usrp-users@lists.ettus.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> We have a custom RFNOC block that we have created. When we using
>>>>>>> GNURadio/Python everything works fine. When follow the examples in
>>>>>>> uhd/host/examples and generate an executable using C++, we get an error
>>>>>>> on
>>>>>>> execution.
>>>>>>>
>>>>>>> We noticed that on start up the python program has no issue locating
>>>>>>> controllers for all our custom blocks (FreqMod):
>>>>>>>
>>>>>>> 2019-Mar-27 13:52:50.824938,0x7f36d447c740,log.cpp:460,2,UHD,linux;
>>>>>>> GNU C++ version 7.3.0; Boost_106501; UHD_3.14.0.0-220-g97935b15
>>>>>>> 2019-Mar-27
>>>>>>> 13:52:50.947109,0x7f36d447c740,x300_impl.cpp:400,2,X300,X300
>>>>>>> initialization
>>>>>>> sequence...
>>>>>>> 2019-Mar-27
>>>>>>> 13:52:51.229789,0x7f36d447c740,x300_impl.cpp:1731,2,X300,Maximum frame
>>>>>>> size: 1472 bytes.
>>>>>>> 2019-Mar-27
>>>>>>> 13:52:51.279558,0x7f36d447c740,x300_impl.cpp:942,2,X300,Radio 1x clock:
>>>>>>> 200
>>>>>>> MHz
>>>>>>> 2019-Mar-27
>>>>>>> 13:52:51.298743,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
>>>>>>> block control (NOC ID: 0xF1F0D00000000000)
>>>>>>> 2019-Mar-27
>>>>>>> 13:52:51.336670,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>>>>>>> passed (Throughput: 1302 MB/s)
>>>>>>> 2019-Mar-27
>>>>>>> 13:52:51.387156,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>>>>>>> passed (Throughput: 1320 MB/s)
>>>>>>> 2019-Mar-27
>>>>>>> 13:52:51.430922,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/Radio_0,Initializing
>>>>>>> block control (NOC ID: 0x12AD100000000001)
>>>>>>> 2019-Mar-27
>>>>>>> 13:52:51.529115,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/Radio_1,Initializing
>>>>>>> block control (NOC ID: 0x12AD100000000001)
>>>>>>> 2019-Mar-27
>>>>>>> 13:52:51.628687,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DUC_0,Initializing
>>>>>>> block control (NOC ID: 0xD0C0000000000000)
>>>>>>> 2019-Mar-27
>>>>>>> 13:52:51.666650,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DUC_1,Initializing
>>>>>>> block control (NOC ID: 0xD0C0000000000000)
>>>>>>> 2019-Mar-27
>>>>>>> 13:52:51.704298,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DDC_0,Initializing
>>>>>>> block control (NOC ID: 0xDDC0000000000000)
>>>>>>> 2019-Mar-27
>>>>>>> 13:52:51.741327,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DDC_1,Initializing
>>>>>>> block control (NOC ID: 0xDDC0000000000000)
>>>>>>> 2019-Mar-27
>>>>>>> 13:52:51.920546,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/FreqMod_0,Initializing
>>>>>>> block control (NOC ID: 0x2833DDBAA1C8E99C)
>>>>>>>
>>>>>>> But when we run uhd_usrp_probe or our program we get:
>>>>>>>
>>>>>>> 2019-Mar-27
>>>>>>> 13:50:48.142811,0x7f489075e7c0,x300_impl.cpp:400,2,X300,X300
>>>>>>> initialization
>>>>>>> sequence...
>>>>>>> 2019-Mar-27
>>>>>>> 13:50:48.424155,0x7f489075e7c0,x300_impl.cpp:1731,2,X300,Maximum frame
>>>>>>> size: 1472 bytes.
>>>>>>> 2019-Mar-27
>>>>>>> 13:50:48.494774,0x7f489075e7c0,x300_impl.cpp:942,2,X300,Radio 1x clock:
>>>>>>> 200
>>>>>>> MHz
>>>>>>> 2019-Mar-27
>>>>>>> 13:50:48.509901,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
>>>>>>> block control (NOC ID: 0xF1F0D00000000000)
>>>>>>> 2019-Mar-27
>>>>>>> 13:50:48.546377,0x7f489075e7c0,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>>>>>>> passed (Throughput: 1317 MB/s)
>>>>>>> 2019-Mar-27
>>>>>>> 13:50:48.596601,0x7f489075e7c0,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>>>>>>> passed (Throughput: 1304 MB/s)
>>>>>>> 2019-Mar-27
>>>>>>> 13:50:48.638428,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/Radio_0,Initializing
>>>>>>> block control (NOC ID: 0x12AD100000000001)
>>>>>>> 2019-Mar-27
>>>>>>> 13:50:48.736751,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/Radio_1,Initializing
>>>>>>> block control (NOC ID: 0x12AD100000000001)
>>>>>>> 2019-Mar-27
>>>>>>> 13:50:48.838951,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DUC_0,Initializing
>>>>>>> block control (NOC ID: 0xD0C0000000000000)
>>>>>>> 2019-Mar-27
>>>>>>> 13:50:48.877079,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DUC_1,Initializing
>>>>>>> block control (NOC ID: 0xD0C0000000000000)
>>>>>>> 2019-Mar-27
>>>>>>> 13:50:48.916659,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DDC_0,Initializing
>>>>>>> block control (NOC ID: 0xDDC0000000000000)
>>>>>>> 2019-Mar-27
>>>>>>> 13:50:48.957457,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DDC_1,Initializing
>>>>>>> block control (NOC ID: 0xDDC0000000000000)
>>>>>>> 2019-Mar-27
>>>>>>> 13:50:49.135814,0x7f489075e7c0,block_ctrl_base_factory.cpp:77,3,RFNOC,Can't
>>>>>>> find a block controller for key FreqMod, using default block
>>>>>>> controller!
>>>>>>> 2019-Mar-27
>>>>>>> 13:50:49.139122,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/FreqMod_0,Initializing
>>>>>>> block control (NOC ID: 0x2833DDBAA1C8E99C)
>>>>>>>
>>>>>>> The error we receive is directly related to the above. Please advise.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> John
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> USRP-users@lists.ettus.com
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
