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 <[email protected]> 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 [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
