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: Sat, 12 Nov 2016 22:36:28 +0000

Hi Michael,

Thanks for the tip. I've done this to no avail. Is there a way to get some more 
useful error output? Seems like a SWIG thing, and I don't know too much about 
how it works other than it wraps c/c++ functions. 

Paul Garver


> On Nov 12, 2016, at 4:48 PM, Michael Dickens <address@hidden> wrote:
> 
> Hi Paul - You are correct that adding "DIGITAL" as you write should add
> that component in for headers and library linking. Did you clean the
> build directory after changing this setting? Sometimes CMake won't redo
> the linkage internally, and one just has to "rm -rf" the whole build
> directory and start from go. Hope this is useful. - MLD
> 
>> On Sat, Nov 12, 2016, at 02: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/? 



reply via email to

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