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.
Related
I am climbing the learning curve of Yocto (Honister) trying to add an third party executable ELF file to my Linux image.
My current issue is that the ELF requires a couple of shared libraries e.g. libpam.so. I have created a recipe that builds these libraries from source code and puts then in the correct place in the file system, but they are not being added to the shared library cache (e.g. not listed when you run /sbin/ldconfig -p | grep pam on the resulting system).
I can correct this manually on a running system via /sbin/ldconfig /path/to/library but I assume I am missing a something in my do_install() step or something.
My reading of the various docs suggest that the bitbake build process should automatically sort this out
On a side note the library version of Linux-PAM is is 1.5.2 but the automake Makefile.am file specifies a version number of 0.85.1
libpam_la_LDFLAGS = -no-undefined -version-info 85:1:85
Is there a way I can access this 0.85.1 version number from an environment variable similar to ${PV} (which returns 1.5.2)
Thanks
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.
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
I cannot seem to configure OpenCV to link to a non-/usr/lib set of FFMPEG libraries.
My LD_LIBRARY_PATH contains a direct link to the folder for the custom install of FFMPEG:
LD_LIBRARY_PATH=/pathto/ffmpeg-0.10.2/lib
Additionally, I've configured pkgconfig as:
PKG_CONFIG_PATH=/samepathto/ffmpeg-0.10.2/lib/pkgconfig/
Within CMake however I cannot find any setting for path to FFMPEG - either in basic or custom. The only setting related to FFMPEG appears to be WITH_FFMPEG type setting (set to ON).
I can build OpenCV but it seems to link to the system libraries for libavcodec - this causes a conflict as the system libraries are version .52 and the version in my install of FFMPEG are .53. Linking an app on a machine without the same system libraries seems to NOT link to my custom install of OpenCV (specifically the libavcodec) because of this (I'm installing these libraries on a shared network folder).
I am not sure if my problem is with building and linking to the wrong version of FFMPEG or if it is something with my environment after building (and then linking to the wrong ffmpeg).
I am building on Linux, Redhat 6, OpenCV 2.3.1.
Something like
export LD_LIBRARY_PATH=/ffmpeg_install_path/lib/
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/ffmpeg_install_path/lib/pkgconfig
export PKG_CONFIG_LIBDIR=$PKG_CONFIG_LIBDIR:/ffmpeg_install_path/lib/
should work. At least it works for OpenCV 2.4.x on my Ubuntu.
For OpenCV 3.x and ffmpeg 3.x, I have to apply the following patch
diff --git a/cmake/OpenCVFindLibsVideo.cmake b/cmake/OpenCVFindLibsVideo.cmake
index 13b62ac..bab9df3 100644
--- a/cmake/OpenCVFindLibsVideo.cmake
+++ b/cmake/OpenCVFindLibsVideo.cmake
## -228,6 +228,12 ## if(WITH_FFMPEG)
if(FFMPEG_libavresample_FOUND)
ocv_append_build_options(FFMPEG FFMPEG_libavresample)
endif()
+ CHECK_MODULE(libavcodec HAVE_FFMPEG)
+ CHECK_MODULE(libavformat HAVE_FFMPEG)
+ CHECK_MODULE(libavutil HAVE_FFMPEG)
+ CHECK_MODULE(libswscale HAVE_FFMPEG)
+ CHECK_MODULE(libswresample HAVE_FFMPEG)
+ CHECK_MODULE(libavresample HAVE_FFMPEG)
if(HAVE_FFMPEG)
try_compile(__VALID_FFMPEG
"${OpenCV_BINARY_DIR}"
And with the following script to build
#!/bin/bash
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/Applications/ffmpeg/lib
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$HOME/Applications/ffmpeg/lib/pkgconfig
export PKG_CONFIG_LIBDIR=$PKG_CONFIG_LIBDIR:$HOME/Applications/ffmpeg/lib
cmake \
-D BUILD_EXAMPLES=ON \
-D BUILD_TESTS=OFF \
-D OPENCV_EXTRA_EXE_LINKER_FLAGS="-Wl,-rpath,$HOME/Applications/ffmpeg/lib" \
-D CMAKE_BUILD_TYPE=RELEASE \
-D CMAKE_INSTALL_PREFIX=$HOME/Applications/opencv \
/path/to/opencv
Also, when build ffmpeg, I have to enable flags --enable-avresample.
It's years after the question was asked, but I recently ran into the kinds of issues described in this question! I'd like to add my input.
First: I only built the static ffmpeg libraries (for reasons), which the opencv build process is somewhat hostile towards. There have been posts by opencv developers stating that they don't support an opencv build against static ffmpeg libraries, but my thinking was "what if you're also building static opencv libraries? Certainly that should be supported?"
And the answer is yes, you can compile static opencv libraries against static ffmpeg libraries! I did this with opencv 4.1.1 against ffmpeg 4.2. I had to use the following cmake options:
cmake3 \
-D BUILD_opencv_apps=OFF \
-D BUILD_opencv_python2=OFF \
-D BUILD_SHARED_LIBS=OFF \
-D WITH_FFMPEG=ON \
-D OPENCV_FFMPEG_SKIP_BUILD_CHECK=ON \
These options result in a set of opencv static libraries that include whatever ffmpeg static libraries that you've also built, assuming your PKG_CONFIG_PATH is setup to correctly find those libraries (or if you've installed them to some default system location).
Q/A:
Why can't we build apps?
The opencv build process assumes that you are building and linking against shared libraries, even if you only build static libraries. This seems like a shortcoming in the build process rather than a technical limitation; perhaps some day this will be fixed.
What is the OPENCV_FFMPEG_SKIP_BUILD_CHECK flag?
There is a step in ffmpeg's cmake process where an application is built and linked using the same faulty build process as opencv's other applications. It's faulty in the sense that the process assumes that you're linking against shared libraries when it doesn't need to; you can perform the same build steps yourself while not making that assumption and create a working application. Thus, this build check needs to be turned off in order for opencv to accept that yes, in fact, any static libraries it finds are okay to use. This is
And why do you disable python support?
The opencv python build process explicitly produces a shared library loadable by Python.
Does this imply that you're still building the tests suite even with the static libraries?
Yes. But I haven't tried running them
In addition to Andrey's answer:
I found that (for my configuration) the opencv 4.1.1 build-system did not correctly add the ffmpeg library path (though it did set the include directory.) My workaround was to supply these paths with the following cmake build arguments:
-DCMAKE_SHARED_LINKER_FLAGS=" -Wl,-rpath-link $FFMPEG_LIBDIR -L$FFMPEG_LIBDIR"
-DCMAKE_MODULE_LINKER_FLAGS=" -Wl,-rpath-link $FFMPEG_LIBDIR -L$FFMPEG_LIBDIR"
-DCMAKE_EXE_LINKER_FLAGS=" -Wl,-rpath-link $FFMPEG_LIBDIR -L$FFMPEG_LIBDIR"
where $FFMPEG_LIBDIR is the path to your ffmpeg library binaries.
It was necessary to use the -rpath-link otpion, because the build system didn't supply all necessary ffmpeg library arguments for my ffmpeg installation.
Examining modules/videoio/cmake/detect_ffmpeg.cmake, it looks like FFMPEG can also be coerced to accept user supplied library paths by specifying:
-DHAVE_FFMPEG=ON
-DFFMPEG_INCLUDE_DIRS=(path to your ffmpeg include directories)
-DFFMPEG_LIBRARIES=(list of ffmpeg libraries, e.g. -lavcodec)
But if we perform this method, the build system displays "YES" to FFMPEG, but "NO" to the individual modules (didn't debug further.)
Some users will find that they may need to supply the --sysroot linker argument in the linker flags, or specify -DCMAKE_SYSROOT as a build argument
Hope this helps someone :)