I enconter a problem I hope to be solved quickly.
I have grace to BUILDROOT compile a Linux zImage Kernel, build a rootfs, have a bootloader, so everething is right.
But at the boot, the system is so minimal that i don't have got some package manager like apt-get, yum, etc....
Despite the fact i've got the network (wget is possible), I don't know how to have a simply gcc in my host (Buildroot don't permit to compile gcc anymore)
or more simply a package manager.
It is so boring to cross compile everything that I think the better solution is to apt-get packages, resolve dependencies and install it for an ARM architecture..
I recompile with Package manager options including IPKG and OPKG but the repositories don't work and the commands return nothing (I.E. ipkg --list, etc..)
Did someone had the same problems and what is the best way to have a good Package Manager on a minimal system compiled and build grace to Buildroot.
What is the best way to have anymore a Native compile toolchain on the ARM host ?
Thanks to your answers
My purpose is to natively compile my code including -lm -lpthread and LIRC module and header files on this minimal host system.
Stefan, France
---- additional informations ---
hello,
i refresh this tag for set informations :
recently buildroot does no longer permit natively compile gcc package
even if make and other tools are available on the recent buildroot distribution
gcc and other tags are marked as deprecated
so it is needed / obligated to cross compile on the host
so what i did
for convenience, i've the Makefile for my code with dependencies
for pthread and lirc_client
If anybody interested, ask me,
stef, France
The Buildroot reference documentation has plenty of details about these questions. Please see http://buildroot.org/downloads/manual/manual.html#faq-no-compiler-on-target and http://buildroot.org/downloads/manual/manual.html#faq-no-binary-packages.
I've added dpkg inside buildroot in order to have dpkg on my board... it was really easy to do.
The only thing I had to hack is to create a fake ldconfig.
Related
I'm trying to cross-build LÖVE (https://love2d.org) for an ARM Linux device (Rockchip RK3066) from Ubuntu 16.04.
As the documentation says, I installed all dependencies on Ubuntu and was able to build it (for Ubuntu, as a test). Now I'm going for the cross-build.
Before building, I have to run ./configure. So far I've been able to get the toolchain's gcc compiler to be accepted, but when it looks for the dependencies, I get this error:
checking for luajit5.1... no
checking for luajit51... no
checking for luajit... no
configure: error: Package requirements (luajit) were not met:
No package 'luajit' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables lua_CFLAGS
and lua_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
Could this be fixed by cross-building luajit for the device and add it to the toolchain binaries, or could I just try to make the ./configure script look for the luajit I installed in Ubuntu?
If it's the latter, would someone kindly point me on the right direction? I've opened like 20 pages already with a similar error message and none of them had a valid answer.
Thanks a lot in advance.
I have a software (ubertooth host ) that I need to compile on ARM, I have already compiled it on a normal Linux X64 machine and it worked. The process contains :
cmake ..
make
make install
Any help regarding how to cross compile for an armhf processor?
Linux Debian Stretch has some precompiled tools for cross compiling:
crossbuild-essential-armhf
I guess that package is the one that suit your target architecture. Firstly I would try to compile with it. Probably you need to launch the build commands with the variable CROSS_COMPILE assigned properly. Eg:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
Other option is creating your own toolchain. Have a look to this other link https://crosstool-ng.github.io/ where you can see how to create your toolchain. This toolchain is compatible with buildroot.
If it does not work, maybe this link could be useful:
http://www.jumpnowtek.com/beaglebone/BeagleBone-Systems-with-Buildroot.html
It explain how to build buildroot for beaglebone. Buildroot is a build system used for embebed systems. It is easy to integrate new modules (libraries, binaries) to be build as part of the firmware. Once you have generated your binary for your target architecture, you only have to copy the necessary files into your target system.
If you decide to build with buildroot, have a look to the documentation:
https://buildroot.org/downloads/manual/manual.html
Buildroot have support for packages based on cmake, so that, even easier if you decide for it.
I am new to yocto and developing drivers. I got source code (alter_driver.c and Makefile) for the drivers but I don't have any idea how to compile and get altera_driver.ko file, so that I can load that drivers and use them.
The version of yocto kernel is 3.0.32-yocto-standard which I got from terminal command uname -r.
Please help me in compiling the drivers. Thank you.
I suggest you read the Yocto Kernel Development Manual (the link is to current version: you should use the one for your Yocto release). If the only thing you have is a out-of-tree module, see part 2.5.2 which explains how to create a recipe for your driver.
The short version is: make a copy of the example recipe, add your sources in the files/-directory, modify the Makefile to build your sources... but read the manual, it's pretty good.
Also, the Kernel Lab may be useful: it mostly talks about working with a full kernel but also covers an out-of-tree module example (lab 4).
I am trying to build an alternative compilation suite on my debian-testing machine (sorry, real question is actually at bottom).
Technically it is a "cross-compilation" because I need to use this toolchain on another machine, but hardware is compatible (x86_64-unknown-linux-gnu) so I don't need to bother about build/host/target differencies.
On the other hand I do need to worry about prefix/sysroot because I cannot install in any standard location (to be more precise: I could install anywhere, since I have root access there, but I shouldn't); This leaves me with my $HOME, some completely non-standard place (e.g.: /usr/local/my/toolchain) or some semi-standard (e.g.: /opt) place. In any case I will need to do something to enable compilation to find includes and libs in such places and runtime linker to find needed .so.
My requirements are:
I have a running Linux that shouln't be messed with.
This system does not have a "C" compiler.
Said linux is BusyBox-based, so I will need a substantial amount of utilities to do any serious compiling there, including make, sed, awk, ..., beside the compiler proper.
I would be happy to stuff my augmented toolchain in /opt, but that is not a requirement; any place is ok as long as it's accessible by more than a single user, I would like ot avoid installing in $HOME.
I am aware of "optware", I installed it and it does work... up to a point. Unfortunately:
It's really old software
it's only 32bit (my system is Linux syno0 3.2.40 #5004 SMP Thu Nov 6 15:26:44 CST 2014 x86_64 GNU/Linux).
Some programs won't compile because provided libs have 32/64 mismatch.
Real motivation to do all this exercise is I need to install some perl modules needed for one application that will have to run there and to install them from cpan I need a native compiler (and other stuff, of course).
Similar arguments about a Ruby-on-rails application I should port there.
If at all possible I should try to use the "native" libs in /lib:/lib64:/usr/lib:/usr/lib64:/usr/lib32 ("static" .a libs are not available).
I had a limited success preparing a custom tarball from an available toolchain for my processor, relocating it to /opt, stuffing needed apps in its sysroot and compiling with: CPPFLAGS="-I/opt/include" and LDFLAGS="-L/opt/lib -Wl,-rpath -Wl,/opt/lib".
This enables me to build almost everything "LFS-style", but it's rather error-prone and 64-bit-only.
I seem to understand it should possible to automatize all this by a careful mix of --prefix, --with-sysroot, --with-native-system-header-dir, --enable-multilib and their friends.
I tried to understand exactly how they should be used and failed, for a reason or another. I didn't find any exhaustive documentation and information in GCC instalation docs are confusing me.
Can someone, please, give me a recipe to build this toolchain?
Any pointer to in-depth documentation welcome, but I suspect some tutoring will be necessary.
I assume recompilation of Binutils and GCC is mandatory, Glib is probably not needed; anything else can be recompiled "native" on target.
TiA
ZioByte
After installing your toolchain in nonstandard places you need to set environment(maybe system-wide) correctly for GCC using LIBRARY_PATH and C_INCLUDE_PATHor CPLUS_INCLUDE_PATH.
Environment Variables Affecting GCC
I see three ways to automate setting path variables for your relocatable toolchain:
on every relocation adding your GCC path to your PATH environment variable. And create alias in your busybox profile (usually /etc/profile)
alias example:
alias gcc='TOOLCHAIN_PREFIX=$(which gcc | rev | cut -d"/" -f3-10 |rev); \
LIBRARY_PATH=$TOOLCHAIN_PREFIX/lib/ \
C_INCLUDE_PATH=$TOOLCHAIN_PREFIX/include/ gcc'
creating for your toolchain launcher-script that will calculate pathes, but you'll should launch it with direct path, setting it when you launch build process, or of course you can add its location to PATH environment varaible.
script example
#!/bin/sh
TOOLCHAIN_PREFIX=$(echo $0 | rev | cut -d"/" -f3-10 |rev);
LIBRARY_PATH=$TOOLCHAIN_PREFIX/lib/ \
C_INCLUDE_PATH=$TOOLCHAIN_PREFIX/include/ \
$TOOLCHAIN_PREFIX/bin/gcc-4.*
The most reliable and ergonomic way — create install/uninstall script that will unpack and set environment correctly, to relocate toolchain you will uninstall from it from one prefix and install to another. If you have dpkg on your debian-testing system, .deb package is best choice.
I can see no way to set environment fully automatically. But we can reduce it to setting just one path — path of toolchain.
HINT* For better stability you should isolate your toolchain and also install in your prefix Linux Kernel headers and Glib
I'd like to use setcap, part of libcap-bin, on an embedded Linux device. I use buildroot and see that it has the packages libcap and libcap-ng available, but not libcap-bin.
I googled around but cannot find the source for libcap-bin to produce the setcap binary for the ARM target board.
On Ubuntu I just install with:
sudo apt-get install libcap-bin
Where can I get the source and how can I build libcap-bin for my ARM board?
As others have explained: you can't expect a 1:1 match between the packages you're seeing in your Ubuntu/Debian distribution and the packages you're seeing in Buildroot.
Ubuntu/Debian packages take source packages (in this case libcap) and create multiple binary packages from them, in order to allow you to install only the library, or the library + development files, or the library + programs, etc. For example, look at http://packages.ubuntu.com/source/quantal/libcap2, which is the reference page for the libcap2 source package: it gives you the list of binary packages generated in Ubuntu from this source package.
On the other hand, in Buildroot, there is only the concept of source packages. One package in Buildroot == one tarball from a given software component. Therefore, there is only package/libcap. At the moment, package/libcap/libcap.mk is written to only install the library because no-one needed the setcap and getcap programs. But you can extend package/libcap/libcap.mk (and possibly package/libcap/Config.in) to enable the compilation of the programs as well. As another commenter noted, you will need to add attr as a dependency (though the commenter wrongly said that Buildroot didn't had attr: it does have it, see package/attr).