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
