discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX,


From: Garver, Paul W
Subject: Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)
Date: Sun, 13 Nov 2016 12:49:37 +0000

Mac setup has v3.0.10. I upgraded on the Linux setup from 3.0.8, but it didn't 
make a difference. Good thought, though. 

My intuition is saying it is something with the fact that the viterbi call is a 
templated function. Either I'm not calling it quite right or SWIG isn't 
wrapping it correctly. 

Paul Garver


> On Nov 12, 2016, at 10:17 PM, Cinaed Simson <address@hidden> wrote:
> 
> Maybe the version of swig?
> 
> On Debian Jessie, it's
> 
>  swig2.0 -version
> 
> which generates
> 
>  SWIG Version 2.0.12
> 
> -- Cinaed
> 
> 
>> On 11/12/2016 06:47 PM, Garver, Paul W wrote:
>> I've isolated the issue further. I have a viterbi_algorithm_combined()
>> call [1] in a work function in one of the blocks in the OOT module.
>> Here's the snippet.
>> 
>> 
>> // Call Viterbi decoder on the input
>> 
>> trellis::viterbi_algorithm_combined(d_fsm->I(),d_fsm->S(),d_fsm->O(),
>> 
>> d_fsm->NS(),d_fsm->OS(),d_fsm->PS(),d_fsm->PI(),22,-1,-1,8,
>> 
>> d_constellation,digital::TRELLIS_EUCLIDEAN,soft_decisions,&(bits[0]));
>> 
>> If I comment this out, all functions show up as expected in the python
>> module. With the function, none of the SWIG wrappers appear. BUT, OSX
>> has no problem with it. Strange! I don't know if SWIG is mangling this
>> because it is a template function or if it is something totally different.
>> 
>> Here are the two setups:
>> 
>> "Linux Setup"
>> OS: Ubuntu 16.04.1 LTS
>> GR: v3.7.10.1-144-g7b0dfd80
>> 
>> g++ 5.4.0
>> 
>> 
>> "Mac Setup"
>> 
>> OS: OSX 10.10.4
>> 
>> GR: v3.7-MacPorts-devel-git-e10637b(20160809)
>> 
>> clang --version Apple LLVM version 6.1.0 (clang-602.0.53)
>> 
>> 
>> Not sure what other details are relevant. Anyone have any ideas?
>> 
>> 
>> 
>> 
>> 
>> [1]
>> http://gnuradio.org/doc/doxygen/namespacegr_1_1trellis.html#aac3ff175700850a652cf80fb44b436eb
>> 
>> 
>> 
>> ------------------------------------------------------------------------
>> *From:* Discuss-gnuradio
>> <address@hidden> on behalf of
>> Daniel P. Martin <address@hidden>
>> *Sent:* Saturday, November 12, 2016 9:27 PM
>> *To:* address@hidden
>> *Subject:* Re: [Discuss-gnuradio] Linking gr-digital in OOT Module
>> (Success on OSX, fails on Linux)
>> 
>> Just today I had a problem like this in an OOT module on Ubuntu. I'd
>> added a callback method to allow gnuradio-companion to set a changed
>> parameter. I'm not sure if this is the way it's supposed to work, but I
>> had to go back to the build directory and do a "cmake ../" to get swig
>> to discover the change and build a python wrapper for the method. So:
>> make clean, cmake ../, make, sudo make install, sudo ldconfig. Good luck!
>> 
>> Dan
>> 
>> 
>>> On 11/12/16 2:55 PM, Garver, Paul W wrote:
>>> I’ve got an out-of-tree module which uses gr-trellis and gr-digital. In the 
>>> root OOT module directory’s CMakeLists.txt I’ve added:
>>> 
>>> set(GR_REQUIRED_COMPONENTS RUNTIME TRELLIS DIGITAL)
>>> 
>>> I’ve got a Mac OS X and Linux setup. On the MAC setup ( GR 
>>> v3.7-MacPorts-devel-git-e106376b(20160809)), the OOT module compiles and 
>>> executes as expected. However, on the Linux setup (GR 
>>> v3.7.10.1-144-g7b0dfd80) I get the "AttributeError:’module’ object has no 
>>> attribute” error.
>>> 
>>> Running a Python session on Linux, importing the OOT module, and doing 
>>> dir() yields none of the functions in the OOT module.
>>> 
>>> The odd thing is that the OS X compilation is clearly linking 
>>> libgnuradio-digital as found by
>>> # otool -L
>>> 
>>> BUT using ldd on the Linux compiled version does NOT show linking to 
>>> libgnuradio-digital
>>> 
>>> I’m thinking that not linking gr-digital is causing this issue. It is the 
>>> exact same code. My understanding is that adding DIGITAL as shown above is 
>>> sufficient for correct linkage, but it isn’t linking in Linux. Is there any 
>>> reason I would need to explicitly add the digital library to CMakeLists in 
>>> lib/?
>>> 
>>> PWG
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>> -- 
>> Dr. Daniel Martin
>> Acadia Controls, LLC
>> 110 Gateway Commons Dr
>> Gorham, ME
>> 207 838-6465 mobile
>> 207 839-6303 fax, office
>> www.acadiacontrols.com <http://www.acadiacontrols.com>
>> 
>> 
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> Discuss-gnuradio Info Page - lists.gnu.org
>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>> lists.gnu.org
>> To see the collection of prior postings to the list, visit the
>> Discuss-gnuradio Archives. Using Discuss-gnuradio: To post a message to
>> all the list ...
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



reply via email to

[Prev in Thread] Current Thread [Next in Thread]