embedding_oot_modules_or_custom_libraries_binaries_in_minus_scenario
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
embedding_oot_modules_or_custom_libraries_binaries_in_minus_scenario [2016/04/12 13:31] – [gnuradio Out Of Tree (OOT) modules] mimbert | embedding_oot_modules_or_custom_libraries_binaries_in_minus_scenario [2016/04/21 17:06] (current) – mimbert | ||
---|---|---|---|
Line 6: | Line 6: | ||
-gnuradio version different from the version on the nodes | -gnuradio version different from the version on the nodes | ||
- | -binaries relying on shared libraries which are not installed on the cortexlab nodes (uncommon libraries or custom libraries) | + | -executable |
- | -binaries relying on versions of shared libraries which are not present on on the cortexlab nodes (perhaps because the binaries where compiled on a different operating system, or a different version of the same operating system. | + | -executables |
-gnuradio "Out Of Tree" (OOT) modules, that is, custom gnuradio components (blocks, and possibly associated gnuradio-companion block metadata) which are not install on the cortexlab nodes. These OOT modules may rely themselves on other gnuradio version, custom binaries or libraries not installed on the nodes, or with the wrong version, such as in (1), (2), (3). | -gnuradio "Out Of Tree" (OOT) modules, that is, custom gnuradio components (blocks, and possibly associated gnuradio-companion block metadata) which are not install on the cortexlab nodes. These OOT modules may rely themselves on other gnuradio version, custom binaries or libraries not installed on the nodes, or with the wrong version, such as in (1), (2), (3). | ||
Line 16: | Line 16: | ||
There is basically no way to avoid this issue: users need to target the same gnuradio version than the one on the cortexlab nodes. | There is basically no way to avoid this issue: users need to target the same gnuradio version than the one on the cortexlab nodes. | ||
- | Actually this is not only about gnuradio, but about the whole package of software used to run the radio on the nodes. We refer to this package as the **cortexlab toolchain**. | + | Actually this is not only about gnuradio, but about the whole package of software used to run the radio on the nodes. We refer to this package as the **cortexlab toolchain**. |
- | + | ||
- | * [[http:// | + | |
- | * some gnuradio additional modules / blocks, such as blocks which interface with the radio hardware ([[http:// | + | |
- | * some gnuradio additional modules adding convenient tools, which we decided to incude, such as [[http:// | + | |
- | * software for supporting the picosdr: [[http:// | + | |
There is currently three possibilities for working with the same version of toolchain than the one on the cortexlab nodes: | There is currently three possibilities for working with the same version of toolchain than the one on the cortexlab nodes: | ||
* use the cortexlab toolchain which is installed on the airlock frontend. It is the exact same toolchain as on the nodes, the only difference is that there is no hardware (usrp, picosdr, jtag) connected to the frontend. | * use the cortexlab toolchain which is installed on the airlock frontend. It is the exact same toolchain as on the nodes, the only difference is that there is no hardware (usrp, picosdr, jtag) connected to the frontend. | ||
- | * build a cortexlab toolchain on a user's workstation. We provide the [[https:// | + | * build a cortexlab toolchain on a user's workstation. We provide the [[https:// |
- | * build the same version of gnuradio than on airlock, without using our '' | + | * build the same version of gnuradio than on airlock, without using our '' |
- | Besides, the main advantage of the [[https:// | + | ===== Packaging executable binaries or libraries |
- | * it is possible to have more than one toolchain installed in parallel. You only need to re-run the root script to switch to a different toolchain, and reboot (or possibly restart udev), and re-source the environment configuration script. | + | Ususally, one compiles an executable binary or library on the same system |
- | * you are sure that it does not conflict with anything in the regular directory tree structure of your system. In particular, it cannot conflit with the debian package system. | + | |
- | * everything from the toolchain is kept separated in the toolchain directory | + | |
- | ===== gnuradio Out Of Tree (OOT) modules ===== | + | * one may compile on its own workstation (we assume a 64 bits linux workstation, |
+ | * one may compile on airlock. airlock runs the same operating system with the same libraries as the the radio nodes, so we are sure that it should work on the nodes. | ||
+ | |||
+ | The last issue is that we need to configure the compilation of the binaries such that the install location of the binaries is the final location where they will be executed, on the radio nodes, but we will need to install them first into a staging area where we will assemble our task file. This is the concept of a [[https:// | ||
+ | |||
+ | The location on the cortexlab nodes where the task will be unpacked and executed is **''/ | ||
+ | |||
+ | Thus, the compilation / stage installation of a custom binary in a minus task scenario has the following scheme, assuming that the task is assembled in directory ''/ | ||
+ | |||
+ | (in the following, we assume that we compile directly on '' | ||
+ | |||
+ | == For autotools project == | ||
+ | |||
+ | $ ./configure --prefix=/ | ||
+ | $ make | ||
+ | $ make DESTDIR=/ | ||
+ | |||
+ | == For cmake project == | ||
+ | |||
+ | $ cmake -DCMAKE_INSTALL_PREFIX=/ | ||
+ | $ make | ||
+ | $ make DESTDIR=/ | ||
+ | |||
+ | Then, in both cases, we will find in ''/ | ||
+ | |||
+ | $ mv / | ||
+ | $ rm -rf / | ||
+ | |||
+ | Then we can assemble our task: | ||
+ | |||
+ | $ minus task create / | ||
+ | |||
+ | If we compile on a workstation instead of '' | ||
+ | ==== gnuradio Out Of Tree (OOT) modules ==== | ||
+ | |||
+ | A gnuradio OOT module is just a special case of custom binary, as described in the previous section. | ||
The gnuradio build system is designed to allow [[https:// | The gnuradio build system is designed to allow [[https:// | ||
+ | |||
+ | '' | ||
+ | |||
+ | Then, as described in the previous section, run cmake and install this way: | ||
+ | |||
+ | $ cmake -DCMAKE_INSTALL_PREFIX=/ | ||
+ | $ make | ||
+ | $ make DESTDIR=/ | ||
+ | $ mv / | ||
+ | $ rm -rf / | ||
+ | |||
+ | ==== multiple chained dependencies ==== | ||
+ | |||
+ | The most complex situation is when you need to embed into a minus task a binary (be it a gnuradio OOT module, an executable or a library) which depends itself from other binaries (libraries, most of the time) which need to be also embedded in the minus task. These dependency chains may be longer (eg. OOT module //A// depends on library //B//, which depends on library //C// and //D//, and library //C// depends on //D// also, as well as on library //E//). | ||
+ | |||
+ | In this situation, you need to compile everything in reverse order starting from the end of the chain (the libraries which have no custom dependencies. In the previous example, the order would be //E//, //D//, //C//, //B//, //A//). The challenge is to be able to tell following libraries (in the order of compilation) where to find previous ones includes (for compilation) and libs (for linking) | ||
+ | |||
+ | FIXME explain how to, when compiling //D//, telling it where to find //E// | ||
+ |
embedding_oot_modules_or_custom_libraries_binaries_in_minus_scenario.1460460703.txt.gz · Last modified: 2016/04/12 13:31 by mimbert