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/?
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio