# Installing pre-compiled OOTs

**URL:** <https://www.ruby-forum.com/t/installing-pre-compiled-oots/242021>\
**Category:** GNU Radio\
**Created:** [May 20, 2015, 7:33pm UTC](https://www.ruby-forum.com/t/installing-pre-compiled-oots/242021 "2015-05-20T19:33:19Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\
**Post date:** [May 20, 2015, 7:33pm UTC](https://www.ruby-forum.com/t/installing-pre-compiled-oots/242021/1 "2015-05-20T19:33:19Z")

</div>

Hello everyone,

I come to you with a rather strange request 🙂

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  
same $INSTALL\_PREFIX
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

Leonardo

---

<div class="post-metadata">

**Author:** ![Leonardo\_SSCardoso](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/858c86/32.png) [@Leonardo\_SSCardoso](https://www.ruby-forum.com/u/Leonardo_SSCardoso)\
**Post date:** [May 20, 2015, 8:17pm UTC](https://www.ruby-forum.com/t/installing-pre-compiled-oots/242021/2 "2015-05-20T20:17:43Z")

</div>

Leonardo,

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

v/r,  
Rich

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

---

<div class="post-metadata">

**Author:** ![Leonardo\_SSCardoso](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/858c86/32.png) [@Leonardo\_SSCardoso](https://www.ruby-forum.com/u/Leonardo_SSCardoso)\
**Post date:** [May 20, 2015, 8:27pm UTC](https://www.ruby-forum.com/t/installing-pre-compiled-oots/242021/3 "2015-05-20T20:27:04Z")

</div>

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 =  
mymodule.detect\_gen\_mac\_b(“packet\_len”)  
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.

Thanks,

Leo

–  
Leonardo S. Cardoso  
Maitre de Conference  
CITI lab, INSA-Lyon - INRIA

---

<div class="post-metadata">

**Author:** ![Leonardo\_SSCardoso](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/858c86/32.png) [@Leonardo\_SSCardoso](https://www.ruby-forum.com/u/Leonardo_SSCardoso)\
**Post date:** [May 21, 2015, 7:47am UTC](https://www.ruby-forum.com/t/installing-pre-compiled-oots/242021/4 "2015-05-21T07:47:40Z")

</div>

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,  
Marcus