Hi Thomas,
I'm still working on the new stable image for this rolling release distro, I have stopped the development for a while due to a robotic project I'm still following. Now I'm using GCC, eglibc and the whole toolchain for moebius (with ROS and few other requested components as well).
I was planning to create an option for having some sort of read/only version of Moebius for unattended usage on custom appliances (ie: robots) in order to avoid write operations on SD cards. log files are a big problem if you need them (instead of symlinking everything /dev/null) and I was thinking about creating some custom scripts for that (in a ramdisk). I didn't knew that software but it seems to be what I'm looking for, thanks for your tip and I'll plan to add it as well.
Regards
Ben
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you need further information I could try to assist in particular with the content of the webpage in German I have linked.
Some of the dependencies (getsebool) of package ramlog are available in package selinux-utils.
Installation of package policycoreutils makes no sense because it's too big.
As far as I remember there are other dependencies than getsebool, but all should be included in selinux-utils.
The current error I get when starting ramlog is this:
You have probably taken the executable as is and executed directly in this OS. I'm not using glibc but eglibc instead, I'm assuming this software is good and does not have any segfault on a defined environment. You probably need to compile it with the GCC supplied.
I need to take some time to investigate it
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's no stupid questions, just unasked ones.
If you have a binary executable build of your program, even if it's for the right platform (arm-hf) it's not probably right for this distro because I'm not using glibc. If this executable is dynamically using the glibc (syscall or whatever) you might need to have the same lib compiled as well. A possible solution might be to recompile the program with the right toolchain (gcc+binutils+libc+...) for this distro, but you need to recompile with moebius toolchain.
Pratically speaking when you handle with a device and you use it as a real embedded device you always prefer to strip unused pieces of code, you create your own versions of binaries without the frills of a general purpose distribution. I have worked with several embedded platforms (mostly ARM and MIPS) and the first thing you do is to create a toolchain for that architecture. When you want to save space or optimize it better you always skip glibc because it's too fat (consider a linux port for a wireless router for example) and you tend to use uglibc, eglibc or something like that. uGlibC it's probably the best choice for an embedded device but it's too radical for me because you have tons of problems (and patches as well) when you'd like to have a large package base, eglibc is a good balance between space, optimizations, speed and sw compatibility.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
However, I'm not feeling confortable with the compilation from source.
Could you please give some advice how to compile the program using moebius toolchain in a test environment (= LXC container on host running 32-bit Debian)?
I'm a noobie here, means I don't know how to setup the ARM-HF environment in the container.
Any advice, links, etc. are highly appreciated.
Creating LXC is no issue.
THX
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You may use these two options:
1) Do not use the cross compile tools at all. Just pickup your favorite Raspberry, install the gcc toolchain there ("moebius container install lang.gcc", "apt-get install gcc ...") and install gcc compiler and utils on the same machine. Decompress the .tar.gz file with your sources and compile them directly on the same machine so you can have binary compatible executables for the platform
2) I use Linux machines on a daily basis, at home and at work as well. My personal choice goes to Gentoo and I mainly use it on my workstations (always) and servers (where possible); with Gentoo you're familiar with cross-compile toolchains because you see some of them even during the installation process. Here are few links from my browser.
Gentoo specific)
I don't have .SPEC files or other packages built just for the distro, I'm just working with a toolchain for Broadcom ARM 2835, I'm not using crosstool-ng, just a plain gcc build.
Option (2) is tough but it's a nice challenge
Last edit: Andrea Benini 2016-02-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello!
What do you think about the idea of moving log files to RAM Using Ramlog.
There are some webpages (here and here) that cover this topic already, but I didn't manage to implement it w/o errror.
THX
Hi Thomas,
I'm still working on the new stable image for this rolling release distro, I have stopped the development for a while due to a robotic project I'm still following. Now I'm using GCC, eglibc and the whole toolchain for moebius (with ROS and few other requested components as well).
I was planning to create an option for having some sort of read/only version of Moebius for unattended usage on custom appliances (ie: robots) in order to avoid write operations on SD cards. log files are a big problem if you need them (instead of symlinking everything /dev/null) and I was thinking about creating some custom scripts for that (in a ramdisk). I didn't knew that software but it seems to be what I'm looking for, thanks for your tip and I'll plan to add it as well.
Regards
Ben
If you need further information I could try to assist in particular with the content of the webpage in German I have linked.
Some of the dependencies (getsebool) of package ramlog are available in package selinux-utils.
Installation of package policycoreutils makes no sense because it's too big.
As far as I remember there are other dependencies than getsebool, but all should be included in selinux-utils.
The current error I get when starting ramlog is this:
Maybe you can consider this when building it in the image.
Last edit: Thomas 2016-02-11
You have probably taken the executable as is and executed directly in this OS. I'm not using glibc but eglibc instead, I'm assuming this software is good and does not have any segfault on a defined environment. You probably need to compile it with the GCC supplied.
I need to take some time to investigate it
Hm... I'm not a software developer, and therefore this question may sound stupid...
If you are using eglibc with your image, why should I try to build/compile the program "ramlog" with GCC?
There's no stupid questions, just unasked ones.
If you have a binary executable build of your program, even if it's for the right platform (arm-hf) it's not probably right for this distro because I'm not using glibc. If this executable is dynamically using the glibc (syscall or whatever) you might need to have the same lib compiled as well. A possible solution might be to recompile the program with the right toolchain (gcc+binutils+libc+...) for this distro, but you need to recompile with moebius toolchain.
Pratically speaking when you handle with a device and you use it as a real embedded device you always prefer to strip unused pieces of code, you create your own versions of binaries without the frills of a general purpose distribution. I have worked with several embedded platforms (mostly ARM and MIPS) and the first thing you do is to create a toolchain for that architecture. When you want to save space or optimize it better you always skip glibc because it's too fat (consider a linux port for a wireless router for example) and you tend to use uglibc, eglibc or something like that. uGlibC it's probably the best choice for an embedded device but it's too radical for me because you have tons of problems (and patches as well) when you'd like to have a large package base, eglibc is a good balance between space, optimizations, speed and sw compatibility.
View and moderate all "Ideas and Suggestions" comments posted by this user
Mark all as spam, and block user from posting to "Support"
All right... this makes sense.
However, I'm not feeling confortable with the compilation from source.
Could you please give some advice how to compile the program using moebius toolchain in a test environment (= LXC container on host running 32-bit Debian)?
I'm a noobie here, means I don't know how to setup the ARM-HF environment in the container.
Any advice, links, etc. are highly appreciated.
Creating LXC is no issue.
THX
You may use these two options:
1) Do not use the cross compile tools at all. Just pickup your favorite Raspberry, install the gcc toolchain there ("moebius container install lang.gcc", "apt-get install gcc ...") and install gcc compiler and utils on the same machine. Decompress the .tar.gz file with your sources and compile them directly on the same machine so you can have binary compatible executables for the platform
2) I use Linux machines on a daily basis, at home and at work as well. My personal choice goes to Gentoo and I mainly use it on my workstations (always) and servers (where possible); with Gentoo you're familiar with cross-compile toolchains because you see some of them even during the installation process. Here are few links from my browser.
Gentoo specific)
General purpose)
...but here google is your friend, you'll see tons of links for it
I don't have .SPEC files or other packages built just for the distro, I'm just working with a toolchain for Broadcom ARM 2835, I'm not using crosstool-ng, just a plain gcc build.
Option (2) is tough but it's a nice challenge
Last edit: Andrea Benini 2016-02-23