Adding library in CMakeList.txt and setting environment variable
LD_PRELOAD=/usr/local/lib/"my lib" fixed the original problem.
I did not have to set --whole-archive option.
Thank you.
On Tue, Apr 16, 2019 at 12:33 PM Nick Foster <bistrom...@gmail.com> wrote:
> 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
