I am using Yocto and I just would like to integrate a new library in my project.
I create a new recipe name "libxerces" which contains a file "libxerces-3.1.1.bb". The bb file is quite simple because it is based on autotools :
DESCRIPTION = "Xerces-c is a validating xml parser written in C++"
HOMEPAGE = "http://xerces.apache.org/xerces-c/"
PRIORITY = "optional"
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
PR = "r1"
SRC_URI = "http://mirror.bit.edu.cn/apache//xerces/c/3/sources/xerces-c-${PV}.tar.gz"
s="${WORKDIR}/xerces-c-${PV}"
inherit autotools pkgconfig
SRC_URI[md5sum] = "6a8ec45d83c8cfb1584c5a5345cb51ae"
SRC_URI[sha256sum] = "a42785f71e0b91d5fd273831c87410ce60a73ccfdd207de1b805d26d44968736"
PACKAGES =+ "${PN}-utils"
FILES_${PN} = "${libdir}/*.so"
FILES_${PN}-utils = "${bindir}/*"
FILES_${PN}-staticdev = "${libdir}/*.a"*
BBCLASSEXTEND += "native"
I added "libxerces" to my bb image by using IMAGE_INSTALL += " libxerces". Then, I try to build my image thru bitbake my-image-test and eveything is done correctly but libxerces returns an error because it can not be installed. Howerver, I note that libxerces-dbg, libxerces-utils, libxerces-samples are visible under /tmp/work/deploy/ipk. I know that libxml2 is integrated by default into poky layer but I have to use xerces..
I solved the error
ERROR: Unable to install packages.
Collected errors:
* opkg_install_cmd: Cannot install package libxerces.
overriding the PACKAGES variable.
In your case:
PACKAGES = "${PN} ${PN}-utils ${PN}-staticdev"
I think that is because the .so files goes to ${PN}-dev package by default.
I hope there is a smarter solution, but for now I fixed in this way.
If you are building a library and the library offers static linking, you can control which static library files (*.a files) get included in the built library.
The PACKAGES and FILES_* variables in the meta/conf/bitbake.conf configuration file define how files installed by the do_install task are packaged. By default, the PACKAGES variable includes ${PN}-staticdev, which represents all static library files.
FILES_${PN}-staticdev ="" # for static libs
FILES_${PN}-dev ="" # for dynamic libs
FILES_${PN}-dbg ="" # for debug options
you need to add above line to your recipe
Related
Got error when I build the project like in the below. I tried so many things but never succeeded. I'm using m1 MacBook. Is this related with this error ?
[CXX1405] exception while building Json A problem occurred starting process 'command '/Users/serhat/Library/Android/sdk/cmake/3.18.1/bin/cmake''
in build.gradle:
externalNativeBuild {
cmake {
path "CMakeLists.txt"
}
}
and this is CmakeList.txt :
# For more information about using CMake with Android Studio,read the
# documentation: https://d.android.com/studio/projects/add-native-code.html
# Sets the minimum version of CMake required to build the native library.
cmake_minimum_required(VERSION 3.4.1)
# Creates and names a library, sets it as either STATIC
# or SHARED, and provides the relative paths to its source code.
# You can define multiple libraries, and CMake builds them for you.
# Gradle automatically packages shared libraries with your APK.
add_library( # Sets the name of the library.
native-lib
# Sets the library as a shared library.
SHARED
# Provides a relative path to your source file(s).
src/main/cpp/native-lib.cpp )
# Searches for a specified prebuilt library and stores the path as a
# variable. Because CMake includes system libraries in the search path by
# default, you only need to specify the name of the public NDK library
# you want to add. CMake verifies that the library exists before
# completing its build.
find_library( # Sets the name of the path variable.
log-lib
# Specifies the name of the NDK library that
# you want CMake to locate.
log )
# Specifies libraries CMake should link to your target library. You
# can link multiple libraries, such as libraries you define in this
# build script, prebuilt third-party libraries, or system libraries.
target_link_libraries( # Specifies the target library.
native-lib
# Links the target library to the log library
# included in the NDK.
${log-lib} )
I fixed this issue :
softwareupdate --install-rosetta
I am working with Linux built with Yocto. I would like to add to the image my app to /bin and some header file to /usr/include. I have no problem with adding the app to /bin, but I am not able to add the header file to my rootfs. The .h file is added to a proper package, but it is not copied to rootfs.
Here is my recipe:
bindir = "${localdir}/bin"
incldir = "${localdir}/usr/include"
FILESEXTRAPATHS_prepend := "${THISDIR}/files/:"
SRC_URI = "file://My_app_dir/* \
\
"
S = "${WORKDIR}"
FILES_${PN} += "${incldir}/*"
do_compile() {
cd My_app_dir/src
make
}
do_install() {
install -d ${D}${bindir}
cp "${S}/My_app_dir/src/my_app" "${D}${bindir}/my_app"
install -d ${D}${incldir}
cp "${S}/My_app_dir/some_lib.h" "${D}${incldir}/some_lib.h"
}
After building the image, the include file exists in /build/tmp/work/<machine>/<my_app>/image/usr/include.
Do you have any idea why I cannot add .h file to /usr/include in rootfs? Thank you in advance for any help.
The header files (among other files like pkgconfig and shared library symlinks) are not added to the main package (say foo), but to the development package (e.g. foo-dev). This is called package split and you can learn more in the Package Splitting of the official documentation. The development packages (and BTW also the debug foo-dbg) are not installed by default.
But please be aware that adding the development package may pull other dependencies (because of various runtime dependencies) and files (there are other files in the development package).
Please note that your line FILES_${PN} += "${incldir}/*" has no effect, as the files in $includedir (i.e. FILES_${PN}-dev) are split before the FILES_${PN} are processed. The order is defined in the variable PACKAGES (check the official documentation).
BTW, there are minor things in the recipe which you can update (unrelated to your question though):
You can use location of standard system paths in the respective variables bindir, includedir etc.
install is preferred over the cp in do_install.
The line FILESEXTRAPATHS_prepend := "${THISDIR}/files/:" is needed only in bbappends. The files directory inside the recipe's directory is in the standard search path of files (among other paths like ${PN} etc.).
have a bit of a problem creating a recipe for yocto. More specifically i have to install a library from git that normally installs like this:
./bootstrap
./configure --sysconfdir=/etc
make
sudo make install
My question is how can I add this to the recipe functions do_configure, do_compile, do_install. Haven't found much information or examples online.
Update 1:
This is the library that i want to integrate into yocto
https://github.com/NXPNFCLinux/linux_libnfc-nci
It's just a regular autotools based library. The main issues, that someone ought to fix, are to make the build create versioned libraries and to add a LICENSE or COPYING file.
However, a quick recipe could look like:
SUMMARY = "Linux NFC stack for NCI based NXP NFC Controllers"
HOMEPAGE = ""
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://src/include/linux_nfc_api.h;endline=17;md5=42fdb99b3ff2c12f594b22a774cb7308"
SECTION = "libs"
SRC_URI = "git://github.com/NXPNFCLinux/linux_libnfc-nci.git"
SRCREV = "118ea118cecda55c1b6a87d151a77b04515687df"
PV = "2.0+git${SRCPV}"
S = "${WORKDIR}/git"
inherit autotools
FILES_${PN} += "${libdir}/libnfc_nci_linux-1.so"
# Make sure it isn’t in the dev package’s files list
FILES_SOLIBSDEV = "${libdir}/libnfc_nci_linux.so"
A versioned library would allow us to remove the last three lines.
How can i write own package for recipe in arago project build? I know little bit that it can be bitbake files. But how can i write, no idea. I searched on internet, but failed to find any good source to start. can someone provide me link or example to start?
Regards
Linux Learner.
Create own recipe with Yocto using Bitbake:
Use Yocto Project for Embedded systems. It's documentation and support is awesome. You can get started Yocto Project.
Build your own recipe(for the first time build takes quiet good amount of time)
Getting Yocto Project:
Follow step-by-step procedure given Gumstix-YoctoProject-Repo till bitbake gumstix-console-image
Now you got yocto project on your machine. Start writing your own recipes. I will show you how to create a hello world recipe.
1) goto /yocto/poky/<create a folder as meta-robot>
2) goto /yocto/poky/meta-robot/<create a folder as /recipes-robot> and <another folder /conf>
3) goto /yocto/poky/meta-robot/recipes-robot/<create another folder /hello>
4) goto /yocto/poky/meta-robot/recipes-robot/hello/<create a file as 'hello_2.7.bb'>
5) Paste this in your hello_2.7.bb
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI[md5sum] = "fc01b05c7f943d3c42124942a2a9bb3a"
SRC_URI[sha256sum] = "fd593b5bcf6d1bb6d7d1bb7eefdccdc0010cf2c4985ccb445ef490f768b927c0"
SRC_URI = "ftp://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz"
inherit autotools gettext
6) goto /yocto/poky/meta-robot/conf/<create a file as layer.conf>
7) paste this in your layer.conf file
# We have a conf directory, append to BBPATH
BBPATH .= ":${LAYERDIR}"
# We have a recipes directory, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "meta-robot"
BBFILE_PATTERN_meta-robot := "^${LAYERDIR}/"
BBFILE_PRIORITY_meta-robot = "7"
8) Open /yocto/build/conf/bblayers.conf file
9) Add your recipe folder path in bblayers file
ex: /home/xyz/yocto/poky/meta-robot \
10) open /yocto/poky/meta-gumstix-extras/recipes-images/gumstix/gumstix-console-image.bb file and under TOOLS_INSTALL add your recipe name i.e.hello \
11) Open your terminal type $ cd /yocto
12) $ source ./poky/oe-init-build-env
13) type bitbake gumstix-console-image
That's it. Your image with your own package will be ready in some time.
You can find your image in /yocto/build/tmp/deploy/images/
All the Best.
Arago is a distribution based on OpenEmbedded project and Bitbake build tool. Logically, you should start with Bitbake manual and OpenEmbedded manual. These are slightly outdated, but still relevant in most part. After that, there is a good, simple tutorial found here.
Also I find #oe channel on FreeNode to be very useful.
EDIT: There is a newer manual for Yocto/Poky that also covers Bitbake and OpenEmbedded.
I think what the other guy has answered to create a new recipe is actually creating a layer.
You can do it by
$ . ./setup-environment build-dir
$ yocto-layer create custom #here you may change the name to your custom layer name.
If you do this, it will automatically ask you to create an example recipe for you.
But I guess that's not the question.
You need to change or customize .bb file.
It has few fields namely
SOURCE_URI=" "
This is the one where you are getting the source tar file for the package.
Then do_compile = " " and do_install = " ". This may not be easy for a newbee like you and me.
You can create a recipe using create-recipe or recipetool.
Check the below link for their usage
http://ashversity.blogspot.in/2016/02/creating-new-yocto-recipe.html
Is there an easy way to install SCons as an egg using zc.buildout? My initial thought was that since it uses distutils I would be able to install it using zc.recipe.egg and thought that the egg would be set up in such a way that the SCons scripts go to ${buildout:directory}/bin and SCons gets added to the PYTHONPATH.
[buildout]
parts =
python
[python]
recipe = zc.recipe.egg
interpreter = mython
eggs =
SCons == 2.0.1
Unfortunately, I don't think SCons' setup.py is written in such a way that it works well with zc.recipe.egg. I end up with:
${buildout:directory}/eggs/scons-2.0.1-py2.6.egg/
${buildout:directory}/eggs/scons-2.0.1-py2.6.egg/scons-2.0.1/
${buildout:directory}/eggs/scons-2.0.1-py2.6.egg/scons-2.0.1/SCons/
${buildout:directory}/eggs/scons-2.0.1-py2.6.egg/EGG-INFO/scripts/
This would work if (2) were on PYTHONPATH and the contents of (4) were copied or linked to the bin directory.
Ideally, I would like to install this as an egg to make use of my global eggs-directory; I don't want to have several copies of the same build tool. Is it possible to accomplish this goal using existing recipes, or should I write my own recipe?
EDIT: I made a personal copy and modified SCons' setup.py arguments so that a scons entry point will be created. The only changes I made: remove 'cmdclass', add 'entry_points'.
arguments = {
'name' : "scons",
...
'scripts' : scripts,
'entry_points' : {
'console_scripts':
['scons = SCons.Script:main']
}
}
This kind of works. It gives me a scons script in bin/scons, but not sconsign, scons-time, or scons.bat. I put it in a tar in /var/www/eggs and serve it with apache.
[buildout]
parts =
python
[python]
recipe = zc.recipe.egg:scripts
interpreter = mython
eggs =
scons == 2.0.1
find-links =
http://localhost/eggs/
Not sure if I want to continue in this direction.
Oh my. I looked into the setup.py for SCons, and it is a bit of a mess. It even stubbornly only installs in /usr/local when installing on a Mac. It certainly is not suitable for use with setuptools (and thus zc.buildout).
You can use zc.recipe.command to run the setup.py script with ${buildout:executable} setup.py and configure it to install in a parts subdir, then use a separate part to symlink all the scripts into bin/:
[buildout]
parts = scons
[scons-download]
recipe = gocept.download
url = http://prdownloads.sourceforge.net/scons/scons-2.0.1.tar.gz
md5sum = beca648b894cdbf85383fffc79516d18
[scons-install]
recipe = plone.recipe.command
command = ${buildout:executable} ${scons-download:location}/setup.py install --prefix=${buildout:parts-directory}/scons-install
location = ${buildout:parts-directory}/scons-install
[scons]
recipe = cns.recipe.symlink
symlink =
scons
scons-time
sconsign
symlink_base = ${scons-install:location}/bin
symlink_target = ${buildout:bin-directory}
So, we ignore setuptools altogether, do not build an egg, but instead just download the tarball, run setup.py manually, then symlink the interesting parts.