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 revisionLast revisionBoth sides next revision | ||
| embedding_oot_modules_or_custom_libraries_binaries_in_minus_scenario [2016/04/12 14:49] – [Packaging executable binaries or libraries in a minus task scenario] mimbert | embedding_oot_modules_or_custom_libraries_binaries_in_minus_scenario [2016/04/21 17:02] – mimbert | ||
|---|---|---|---|
| Line 35: | Line 35: | ||
| * everything from the toolchain is kept isolated in the toolchain install directory, instead of being scattered everywhere. | * everything from the toolchain is kept isolated in the toolchain install directory, instead of being scattered everywhere. | ||
| * 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 only restart udev? that needs to be checked), and re-source the environment configuration script. | * 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 only restart udev? that needs to be checked), and re-source the environment configuration script. | ||
| + | |||
| + | When building a toolchain on a user's workstation, | ||
| ===== Packaging executable binaries or libraries in a minus task scenario ===== | ===== Packaging executable binaries or libraries in a minus task scenario ===== | ||
| Line 47: | Line 49: | ||
| The location on the cortexlab nodes where the task will be unpacked and executed is **''/ | 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: | + | 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 == | == For autotools project == | ||
| + | |||
| + | $ ./configure --prefix=/ | ||
| + | $ make | ||
| + | $ make DESTDIR=/ | ||
| == For cmake project == | == 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 ==== | ==== 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:// | ||
| Line 58: | Line 83: | ||
| '' | '' | ||
| - | ==== Custom binaries / libraries | + | 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.txt · Last modified: 2016/04/21 17:06 by mimbert