GNURadio OOT模块调用外部.so库时出现AttributeError问题求助

I’ve run into this exact issue before — compilation succeeds, but Python throws an AttributeError when trying to use the module. The root cause almost always boils down to how LimeSuite is integrated into GNURadio’s SWIG bindings or subtle linking gaps. Let’s walk through the fixes step by step:

1. Fix Your SWIG Interface File (.i) #

GNURadio relies on SWIG to connect C++ code to Python. If your block uses LimeSuite classes/functions, you need to make sure SWIG knows about them:

• Add %include "LimeSuite.h" (or the specific LimeSuite header you’re using) to your module’s .i file. If there are internal LimeSuite symbols SWIG can’t parse, add %ignore directives to skip them (e.g., %ignore LMS_InternalHelperFunc;).
• Double-check that your C++ block class uses the GNURadio API macro — something like class GR_MYMODULE_API MyLimeBlock : public gr::block { ... };. Without GR_MYMODULE_API, the class symbols won’t be exported, so Python can’t see them.

2. Correct CMake Linking for Python Extensions #

Adding -lLimeSuite to CMAKE_CXX_FLAGS works for compiling the C++ code, but GNURadio’s Python extensions need explicit linking. Update your module’s CMakeLists.txt to link LimeSuite directly to the SWIG-generated Python target:

# After you've declared your SWIG module with GR_SWIG_MAKE
GR_SWIG_INSTALL(TARGETS mymodule_swig DESTINATION ${GR_PYTHON_DIR}/mymodule)

# Link LimeSuite to the Python extension
target_link_libraries(mymodule_swig PRIVATE ${LIMESUITE_LIBRARIES})

Using LIMESUITE_LIBRARIES ensures you’re linking against the full path of libLimeSuite.so, which avoids runtime "file not found" issues.

3. Check Runtime Library Access #

Even if compilation passes, the Python interpreter might not locate libLimeSuite.so at runtime:

• Run ldd /path/to/your/build/python/mymodule/_mymodule_swig.so (replace with your actual path) to check if libLimeSuite.so is listed as "found". If it’s missing, add the library path to your environment:

  export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH
  

• For a permanent fix, add this to your CMakeLists.txt to embed the library path into your module:

  set(CMAKE_INSTALL_RPATH "${LIMESUITE_LIBRARY}/../")
  set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
  

4. Verify Python Bindings Are Generated #

After re-running cmake && make install, check the generated Python files (in your build’s python/ directory or install path) to see if your LimeSuite-dependent methods/classes are present. If they’re missing, your SWIG interface isn’t exposing them correctly — go back to step 1 and double-check your .i file.

5. Test with a Minimal Block #

To rule out code-specific issues, create a tiny test block that only calls a simple LimeSuite function (like LMS_GetDeviceList). If this test block throws the same error, the problem is in your binding/linking setup. If it works, the issue is in your original block’s code (e.g., a typo in a method name, or trying to access a private method from Python).

内容的提问来源于stack exchange，提问作者m3x1m0m