Installing pre-compiled OOTs

Hello everyone,

I come to you with a rather strange request :slight_smile:

I’m looking into the possibility of installing OOTs that were
precompiled in one system onto another.

Lets consider basic stuff first:

  1. Versions of all software are identical in both systems (linux,
    gnuradio, uhd, build suite, etc…).
  2. I’m copying all relevant binaries and compiled stuff from
    $INSTALL_PREFIX/lib to another computer and installing in exactly the
  3. LD_LIBRARY_PATH, PYTHONPATH, PKG_CONFIG_PATH, etc, are set correctly
    on both systems and tested for OOTs build locally in each.

Will this crazy idea work? If not, why?

If it is possible, then what will be the limitations (ex: different
version of software, different $INSTALL_PREFIX)?

Thank you.

Best regards



Have you tried copying the entire module directory (including build)
one computer to another? What errors do you see when you do that?


On Wed, May 20, 2015 at 10:31 AM, Leonardo S. Cardoso <

Hi Richard,

You mean copying the whole module directory and doing a “make install”
in the remote computer?

I havent tried that, but I guess that would end up the same way, since
all I’m doing is copying the target directory (where “make install” puts
things) from one computer to another. This doesn’t work, by the way. I
get an error that looks like this:

self.mymodule_detect_gen_mac_b_0 =
AttributeError: ‘module’ object has no attribute ‘detect_gen_mac_b’

If I take the whole module directory and redo “cmake”+”make”+”make
install” it works perfectly, but my whole point is avoiding compiling
everything again.



Leonardo S. Cardoso
Maitre de Conference

Hi Leonardo,

the most elegant way of this is

  • making/having a pyBOMBS recipe for that OOT
  • configuring pyBOMBS to build into a prefix
  • build the OOTs using that
  • and usings pyBOMBS’ “package” command to create a .tar.gz out of that
  • unpack the package where you want to use it

This really needs both machines to have the same versions of all
libraries used – not only an exact GNU Radio match version match, but
all libraries that the OOTs might link to – most importantly among
these, boost.
Most of the time this simply means that either both machines are
identical from a software perspective, or all the things you’ll need to
stuff into that prefix might make it easier to just rebuild on the
target instead.

Basically, the problem you’re facing is the same all linux distributions
have been trying to solve for the last 22 years or so – and to be
honest, keeping dependencies coherent is still not a solved issue.

Best regards,