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
