From c6c75c92dc54eb1d49974ed6d9ca0ef98dd80b73 Mon Sep 17 00:00:00 2001 From: Robin Mueller Date: Sun, 2 May 2021 14:53:02 +0200 Subject: [PATCH] updating READMEs for bbb and rpi --- doc/README-bbb.md | 19 ++++++------- doc/README-rpi.md | 72 +++++++++++++++++++++++++++++++++++------------ 2 files changed, 63 insertions(+), 28 deletions(-) diff --git a/doc/README-bbb.md b/doc/README-bbb.md index a5cf38b..159e92c 100644 --- a/doc/README-bbb.md +++ b/doc/README-bbb.md @@ -280,7 +280,7 @@ and running it on the BBB via command line. Navigate into the `fsfw_example` fol ```sh cmake -G "Unix Makefiles" -DOS_FSFW=linux -DTGT_BSP=arm/beagleboneblack -DLINUX_CROSS_COMPILE=ON -DCMAKE_BUILD_TYPE=Debug .. ``` - + On Windows, replace `-G "Unix Makefiles"` with `-G "MinGW Makefiles"`. Alternatively, you can use the helper shell scripts located inside `cmake/scripts/BBB/crosscompile` @@ -310,7 +310,6 @@ The toolchain path needs to be corrected, for example like shown in the followin - ## Setting up the TCF agent on the BBB It is recommended to set up a [TCF agent](https://wiki.eclipse.org/TCF) for comfortable @@ -365,11 +364,11 @@ Navigate to the folder containing the symlinks cd /usr/lib/arm-linux-gnueabihf ``` - Type `more libpthread`, press `TAB` and check whether the symbolic - link `libpthread.so` is shown. If it is not, we are going to set it up - manually to avoid issues when linking against `pthread` later. - Now you can find out where `libpthread.so` points with `readlink libpthread.so`. - This information is used to convert the absolute symlink to relative ones, for example with: +Type `more libpthread`, press `TAB` and check whether the symbolic +link `libpthread.so` is shown. If it is not, we are going to set it up +manually to avoid issues when linking against `pthread` later. +Now you can find out where `libpthread.so` points with `readlink libpthread.so`. +This information is used to convert the absolute symlink to relative ones, for example with: Run the following command to copy the symlink `libpthread.so.0` if it does not exist yet: @@ -383,15 +382,15 @@ Alternatively, you can correct the symlinks to use relative paths, for example w ln -s ../../../lib/arm-linux-gnueabihf/libpthread.so.0 libpthread.so ln -s ../../../lib/arm-linux-gnueabihf/librt.so.1 librt.so ``` - + Please note that there might also be issues with some symlinks or libraries not being copied properly, especially on Windows. This has occured with files like `libc.so.6`. If there are linker issues at a later stage, you can try to copy the symlinks manually from the Linux board to the sysroot with `scp`. - + For example, you can copy `libc.so.6` from the Linux board to the sysroot with the following command - + If there are issues with the cross-compilation process, manually copying the following symlinks can help: diff --git a/doc/README-rpi.md b/doc/README-rpi.md index 085e38f..7374ed4 100644 --- a/doc/README-rpi.md +++ b/doc/README-rpi.md @@ -125,18 +125,35 @@ toolchain binaries are added to the path accordingly. ```sh rsync -avHAXR --numeric-ids --info=progress2 @:/{lib,usr} ``` - - Please note that `rsync` sometimes does not copy shared libraries or symlinks properly, - which might result in errors when cross-compiling and cross-linking. It is recommended to run - the following commands in addition to the `rsync` command: - + + On Linux, it is recommended to repair some symlinks which can be problematic: + Navigate to the folder containing the symlinks first: + ```sh - scp @:/lib/arm-linux-gnueabihf/{libc.so.6,ld-linux-armhf.so.3,libm.so.6} /lib/arm-linux-gnueabihf - scp @:/usr/lib/arm-linux-gnueabihf/{libpthread.so,libc.so,librt.so} /usr/lib/arm-linux-gnueabihf + cd /usr/lib/arm-linux-gnueabihf ``` - - See the [troubleshooting](#troubleshooting) section for more details if the compilation process - is problematic. + + You can now use + + ```sh + readlink libpthread.so + ``` + + which will show an absolute location of a shared library the symlinks points to. This location + needs to be converted into a relative path. + + Run the following command to create a relative symlinks instead of an absolute ones. The pointed + to location might change to check it with `readlink` first before removing the symlinks: + + ```sh + rm libpthread.so + rm librt.so + ln -s ../../../lib/arm-linux-gnueabihf/libpthread.so.0 libpthread.so + ln -s ../../../lib/arm-linux-gnueabihf/librt.so.1 librt.so + ``` + + For more information on issues which can occur when cloning the root filesystem, + see the [troubleshooting](#troubleshooting) section. 3. It is recommended to install `gdb-multiarch`. This tool will allow remote debugging on the host computer. This step is not required if the `tcf-agent` is used. @@ -202,15 +219,23 @@ toolchain binaries are added to the path accordingly. ```sh rsync -vR --progress -rl --delete-after --safe-links pi@:/{lib,usr,opt/vc/lib} ``` - + Please note that `rsync` sometimes does not copy shared libraries or symlinks properly, - which might result in errors when cross-compiling and cross-linking. See the - [troubleshooting](#troubleshooting) section for more details. + which might result in errors when cross-compiling and cross-linking. It is recommended to run + the following commands in addition to the `rsync` command on Windows: + + ```sh + scp @:/lib/arm-linux-gnueabihf/{libc.so.6,ld-linux-armhf.so.3,libm.so.6} /lib/arm-linux-gnueabihf + scp @:/usr/lib/arm-linux-gnueabihf/{libpthread.so,libc.so,librt.so} /usr/lib/arm-linux-gnueabihf + ``` + + For more information on issues which can occur when cloning the root filesystem, + see the [troubleshooting](#troubleshooting) section. 5. It is recommended to install `gdb-multiarch`. This tool will allow remote debugging on the host computer. Replace `x86_64` with the correct processor architecture for other architectures. This is not required if the `tcf-agent` is used. - + ```sh pacman -S mingw-w64-x86_64-gdb-multiarch ``` @@ -356,25 +381,36 @@ There might be some issues with the pthread symbolic links. Navigate to the folder containing the symlinks ```sh -cd /c/User//beaglebone/rootfs/usr/lib/arm-linux-gnueabihf +cd /usr/lib/arm-linux-gnueabihf ``` Type `more libpthread`, press `TAB` and check whether the symbolic link `libpthread.so` is shown. If it is not, we are going to set it up manually to avoid issues when linking against `pthread` later. +Now you can find out where `libpthread.so` points with `readlink libpthread.so`. +This information is used to convert the absolute symlink to relative ones, for example with: -Run the following command to create a symlink to `libpthread.so.0` +Run the following command to copy the symlink `libpthread.so.0` if it does not exist yet: ```sh scp @:/usr/lib/arm-linux-gnueabihf/libpthread.so . ``` -Alternatively, you can also create the symlink pointing to the correct library with +Alternatively, you can correct the symlinks to use relative paths, for example with: ```sh -ln -s ../../../lib/arm-linux-gnueabihf/libpthread.so.0 libpthread.so +ln -s ../../../lib/arm-linux-gnueabihf/libpthread.so.0 libpthread.so +ln -s ../../../lib/arm-linux-gnueabihf/librt.so.1 librt.so ``` +Please note that there might also be issues with some symlinks or libraries not being copied +properly, especially on Windows. This has occured with files like `libc.so.6`. +If there are linker issues at a later stage, you can try to copy the symlinks manually from the +Linux board to the sysroot with `scp`. + +For example, you can copy `libc.so.6` from the Linux board to the sysroot with +the following command + If there are issues with the cross-compilation process, manually copying the following symlinks can help: