I am trying to add 32-bit ncurses into my root file system
I am using intel yocto bsp sumo branch
Here is my local.conf:
require conf/multilib.conf
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
IMAGE_INSTALL_append = " dpkg gnutls lib32-glibc lib32-libgcc lib32-libstdc++ lib32-gnutls lib32-freetype lib32 -libx11 lib32-ncurses lib32-dpkg python3-six"
ncurses folder is present in tmp
build/tmp/work/x86-pokymllib32-linux/lib32-ncurses/6.0+20171125-r0
The image folder is created and has the libraries
/tmp/work/x86-pokymllib32-linux/lib32-ncurses/6.0+20171125-r0/image/lib
libncurses.so.5 libncurses.so.5.9 libncursesw.so.5 libncursesw.so.5.9 libtinfo.so.5 libtinfo.so.5.9
But these files are not present in root file system.
How can i debug or what should be my next step to get it into root file system. which log files should I look
Thanks for your time.
I found answer after posting query in yocto mailing list.
$ oe-pkgdata-util find-path */libncurses.so*
ncurses-libncurses: /lib64/libncurses.so.5
ncurses-libncurses: /lib64/libncurses.so.5.9
ncurses-dbg: /lib64/.debug/libncurses.so.5.9
lib32-ncurses-dbg: /lib/.debug/libncurses.so.5.9
ncurses-dev: /usr/lib64/libncurses.so
lib32-ncurses-dev: /usr/lib/libncurses.so
lib32-ncurses-libncurses: /lib/libncurses.so.5.9
lib32-ncurses-libncurses: /lib/libncurses.so.5
So including lib32-ncurses-libncurses in local.conf will solve the problem
IMAGE_INSTALL_append += "lib32-ncurses-libncurses"
I see libncurses.so in packages-split/lib32-ncurses-dev , what should I do to add it in rootfs
The default recipe won't install the development package into the rootfs unless explicitly instructed to do so. You can add this to your local.conf for quick testing:
IMAGE_INSTALL_append += lib32-ncurses-dev
You should now see the contents of packages-split/lib32-ncurses-dev inside your ncurses image folder and subsequently image rootfs.
There is a similar approach for dbg packages as well.
Related
I am building yocto linux for embedded linux platform.
The build is successful and root file system is generated.
however libgif.so library is missing in the root filesystem.
I want libgif to be compiled and copied in my generated root filesystem (in /usr/lib/)
I tried adding giflib in local.conf
DISTRO_FEATURES_append = " giflib "
I expect the giflib to be compiled and copied in the /usr/lib in root filesystem. but it isn't.
If i add EXTRA_IMAGEDEPENDS += " giflib " and just build giflib with "bitbake giflib" then the giflib is compiled and generated at path
Build/tmp/work/aarch64-poky-linux/giflib/5.1.4-r0/build/lib/.libs/giflib.so
Thats not how it works, sorry.
Just building the package will not automagically install it into any rootfs
You have to tell bitbake that you want giflib to be included in your image. This is done by adding it to IMAGE_INSTALL of your custom image.
Adding it to DISTRO_FEATURES will probably have no effect at all, because that is only parsed for specific keywords.
This describes how to add something to a custom image: Custom images in Yocto. You can technically also go the local.conf routes mentioned in the paragraphs above the linked one, but that only hinders proper reproductibility. A bit more extensively, I explain it here.
I would like to strip down my Yocto Linux before put in it to flash. Unneeded software, man pages, POCO sample codes and other documentation just waste resource, especially on the i.MX28 EVK with only 128MB flash.
My local.conf file looks following:
$ gedit conf/local.conf &
...
IMAGE_INSTALL_append = " poco nginx canutils vsftpd curl fcgi spawn-fcgi net-snmp util-linux ubiattach-klibc ubimkvol-klibc ubiformat-klibc minicom net-tools zeroconf avahi-autoipd mtd-utils u-boot-fw-utils ethtool"
...
I bitbake the image "core-image-base".
I was wondering, is there a way that I can delete all of the Unneeded files?
Can somebody help me howto strip down my Yocto Linux?
When you look into the recipe for core-image-base and the included core-image class (core-image-base.bb & core-image.bbclass) you will notice that there is only packagegroup-core-boot and packagegroup-base-extended in that image.
The description for those:
By default we install packagegroup-core-boot and packagegroup-base-extended packages;
this gives us working (console only) rootfs.
This lets assume that it's not supposed to be removed and that so you can't remove much software/files on the 'Yocto-way'. What you can do is writing patches which are removing files manually or take a look in how to build a tiny system with Yocto (Link to Development Manual).
You can activate this distribution by changing the DISTRO Variable in your local.conf:
DISTRO = "poky-tiny"
This is an example of a minimal console image:
recipes-core/images/core-image-small.bb
DESCRIPTION = "Minimal console image."
IMAGE_INSTALL= "\
base-files \
base-passwd \
busybox \
sysvinit \
initscripts \
${ROOTFS_PKGMANAGE_BOOTSTRAP} \
${CORE_IMAGE_EXTRA_INSTALL} \
"
IMAGE_LINGUAS = " "
LICENSE = "MIT"
inherit core-image
IMAGE_ROOTFS_SIZE ?= "8192"
This recipe produces an image of about 6.4MB. If you use poky-tiny by add DISTRO = "poky-tiny" to your conf/local.conf the image will be around 4MB.
To build this, you will need to add
INSANCE_SKIP_glibc-locale = "installed-vs-shipped"
You could also use PACKAGE_CLASSES ?= package_ipk package manager as it is the lightest and remove package-management feature from your production root file system altogether.
If you choose to have packagegroup-core-boot in your image, you could use BusyBox's mdev device manager instead of udev by specifying in your conf/local.conf
VIRTUAL-RUNTIME_dev_manager = "mdev"
If you are running root filesystem on a block device, use ext2 instead of ext3 or ext4 without the journal
Configure BusyBox with only the essential applets by providing your own configuration file in bbappend.
Review the glibc configuration, which can be changed via the DISTRO_FEATURES_LIBC distribution configuration variable. You can find the example in the poky-tiny distribution.
Consider switching to a ligher C library. Use uclibc or musl instead of the standard glibc http://www.etalabs.net/compare_libcs.html
to use musl, in local.conf
TCLIBC = "musl"
add meta-musl to conf/bblayers.conf
I'm using Yocto 1.8 to build a linux system.
I need to use the command "setcap" to set files capabilities during build, which is introduced via libcap package recipe: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/libcap/libcap_2.25.bb?h=master
The problem is that the recipe provides libcap package, which is only the library, and another subpackage called libcap-bin which contains the binaries I need to use. But I couldn't build or use the libcap-bin-native package inside my recipe as a dependancy (using DEPENDS variable). so everytime I call "setcap" binary, Yocto uses the host binaries (Ubuntu 14.04 64-bit) not the build system ones (as it's not there).
I need to know how to include the native binaries built from libcap-bin package in my native sysroot buildsystem to be used during recipe execution.
Example recipe to use setcap command:
DESCRIPTION = "Apply CAPs on files"
SECTION = "bin"
LICENSE = "CLOSED"
do_install() {
install -d ${D}${bindir}
touch ${D}${bindir}/testacl
}
DEPENDS = "libcap libcap-native"
#New task will be added to each recipe to apply attributes inside ipks
fakeroot do_setcaps() {
setcap 'cap_sys_admin,cap_sys_rawio+ep' ${WORKDIR}/packages-split/${PN}${bindir}/testacl
}
#Adding the new task just before do_package_write_ipk task
addtask setcaps before do_package_write_ipk after do_packagedata
This recipe is working fine, except that it uses the setcap command from my host system (Ubuntu 14.04 64-bit) which is located "/sbin/setcap"
The dependency package libcap-native only includes the library files inside my native sysroot, but not the binaries.
If I used this inside my recipe:
DEPENDS = "libcap-bin"
I got this error:
ERROR: Nothing PROVIDES 'libcap-bin'
I also saw this thread talking about the same topic:
Linux capabilities with yocto
But he uses Yocto > 2.3 and I'm using Yocto 1.8 , and I can't update it right now.
Any help?
PS: I already updated my yocto build system to preserve ACLs and extended attributes during IPK creation, and it's working and being preserved inside the IPK, inside the rootfs, and on the target after flashing.
I found the solution.
I had to add this to the libcap recipe
PACKAGECONFIG_class-native = "attr"
As the generated binaries (setcap & getcap) are depending on libattr, and this has to be configured manually.
I found that it's already configured for the target package
PACKAGECONFIG ??= "attr ${#bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam', '', d)}"
Sorry for disturbing.
I can't comment yet so comment here.
The command setcap should be provided by libcap-native. And please double check whether it exists in tmp/work/x86_64-linux/libcap-native/2.25-r0/image/:
$ find tmp/work/x86_64-linux/libcap-native/2.25-r0/sysroot-destdir/ -name setcap
tmp/work/x86_64-linux/libcap-native/2.25-r0/sysroot-destdir/buildarea3/kkang/cgp9/builds/qemumips64-Apr24/tmp/sysroots/x86_64-linux/usr/sbin/setcap
You can find setcap here after remove the prefix:
$ ls /buildarea3/kkang/cgp9/builds/qemumips64-Apr24/tmp/sysroots/x86_64-linux/usr/sbin/setcap
/buildarea3/kkang/cgp9/builds/qemumips64-Apr24/tmp/sysroots/x86_64-linux/usr/sbin/setcap
When cross compiling with CMake, I use a toolchain file which sets up the linker to look in a local copy of the root filesystem of the embedded (Linux) target.
Things come unstuck for a few fundamental libraries like libm or librt which are usually a symbolic link to an absolute location which cannot be resolved.
For example, on the target rootfs, librt is a symbolic link at /usr/lib/arm-linux-gnueabihf/librt.so which points to /lib/arm-linux-gnueabihf/librt.so.6
I thought setting the option CMAKE_SYSROOT to the root of the root filesystem would be enough to let CMake and/or gcc work out the link, but this doesn't work.
For now I'm just manually adjusting the links to be relative and then everything links ok. I assume there must be something I'm missing about cross-compiling with CMake though?
What is the paradime for ensuring cross-compilation and linking against libraries in a root filesystem?
The root filesystem is generated with the debootstrap tool. The complications have arisen from requiring to build the project against both Wheezy and Jessie root filesystem targets.
I am cross-compiling 3.4.0 kernel for an embedded device. Then I would like to install compat-wireless drivers which require /lib/modules/3.4/build directory and sub-files. Could anyone explain how can I build that directory so that when I do INSTALL_MOD_PATH=newmodules make modules_install it would load /lib/modules/$(uname -r)/build directory as well? I would appreciate for a clear explanation.
I am using debian distro. I know I can install the kernel headers by apt-get install linux-headers-$(uname -r), but I doubt it would be a good idea since the kernel sources might not be identical.
Typically /lib/modules/$(uname -r)/build is a soft-link to the directory where performed the build. So the way to do this is to simply do a
make modules_install INSTALL_MOD_PATH=/some/root/
in the build directory of the kernel where /some/root is where you want your cross compile pieces to end up. This will create a link to your kernel build path in /some/root/lib/modules/$(uname -r) ... verify that.
Now when you build the compat_wireless drivers specify the kernel build directory in the Makefile as /some/root using the KLIB_BUILD variable (read the Makefile)
make modules KLIB_BUILD=/some/root/lib/modules/$(uname -r)/build
this should do the trick for you.
EDIT A
In answer to your comment below:
Keep "newmodules" outside the kernel directory it's a bad idea to put it in the kernel directory. so mkdir newmodules somewhere like /home/foo or /tmp or something. This is one of the reasons your build link is screwed up
ALSO .../build is a soft link /to/kernel/build/location it will only copy over as a soft-link. You also need to copy over the actual kernel source / kernel build directory to your microSD, using the same relative location. For example,
Let's say your kernel source is in:
/usr/src/linux-3.5.0/
Your kernel build directory is:
/usr/src/linux-3.5.0-build/
Your newmodules (after following 1.) is in:
/tmp/newmodules/
So under /tmp/newmodules/ you see the modules installed in a tree like:
lib/modules/$(uname -r)/
when you do an ls -al in this directory, you'll see that build is a soft link to:
build -> /usr/src/linux-3.5.0-build/
Now let's say your microSD is mounted under /mnt/microSD
then you need to do the following
mkdir -p /mnt/microSD/usr/src
cp -a /usr/src/linux-3.5.0 /usr/src/linux-3.5.0-build /mnt/microSD/usr/src
cp -a /tmp/newmodules/lib /mnt/microSD/lib
Now you have all the content you need to bring over to your embedded environment. I take it you are doing the compat_wireless build on your target system rather than cross compiling it?
NOTE
If your kernel build is the same as the kernel source then just copy over the kernel source and ignore the linux-3.5.0-build in copy instructions above
This is old, but some people will need this information.
I have spent many hours to figure out where build folder comes from, and why it is just a link when I compile my own kernel. Finally figured it out;
Linux kernel usually just links the build and source folders to the source folder.
But!
Arch linux (probably some other distros too); has a manual script for deleting those links, and adding (filtered) files to build folder.
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux
I've extracted that script to work standalone (in a kernel source tree) here: https://gist.github.com/furkanmustafa/9e73feb64b0b18942047fd7b7e2fd53e