I am adding a custom recipe to my image. It is bases on DBCPPP. This project is built using cmake. My issue only comes to light when I include a new layer meta-swupdate. It seems meta-swupdate alters the kernel in a way that conflicts with dbcppp. My full error is:
Error: Transaction test error:
file /usr/lib/libxml2.so.2.9.10 conflicts between attempted installs of dbcppp-1.0+gitr0+fa8ce17468-r0.cortexa7t2hf_neon and libxml2-2.9.10-r0.cortexa7t2hf_neon
To build and include dbcppp I added the recipe:
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "gitsm://github.com/xR3b0rn/dbcppp.git;protocol=https;branch=master"
PV = "1.0+gitr${SRCPV}"
SRCREV = "${AUTOREV}"
DEPENDS += " boost"
S = "${WORKDIR}/git"
inherit pkgconfig cmake
FILES_${PN} += "/usr/lib/xml2Conf.sh /usr/lib/lib*.so.*"
SOLIBS = ".so"
FILES_SOLIBSDEV = ""
INSANE_SKIP_${PN} += "dev-so"
I have read a few other questions and attempted two solutions by adding a do_install_append step.
Change folder permission level install -d 0755 ${D}/usr/lib
Remove the folder rm -rf ${D}/usr/lib
Neither solution worked. I need both libraries in my application and I unsure how to proceed.
Edit: After some further reading I found a suggestion to delete the tmp, cache, and sstate-chace folders. I did this but I receive the same error.
Edit: My local.conf has PACKAGE_CLASSES ?= 'package_rpm' defined. if I remove this I still get a do_rootfs error, but the error message is not helpful.
Edit: In my recipe for dbcppp I have attempted to remove the file in question. This gives me the same error. Makes no difference.
do_install_append() {
rm -rf /usr/lib/libxml2.so.2.9.10
}
Related
I am using yocto build a linux image that integrates some layers of wlan and a specific wifi chip, but seems like patching of one of the files is failing (details below)
Steps that I did:
Created a working directory
initialized a repo for kernel 4.14.98 via:
repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-sumo -m imx-4.14.98-2.3.3.xml
sync the repo via repo sync
created a tmp folder outside of the current working dir, and download the specific code for wifi via
repo init -u git://codeaurora.org/quic/le/le/manifest.git -b release -m CHSS.LNX_FSLS.1.0-01200-QCAAUTOHOSTHZ.xml –repo-url=git://codeaurora.org/tools/repo.git –repo-branch=caf-stable
repo the sync
copy the meta-qti-connectivity and wlan-opensource folders into the source folder of the working directory
Download the files for a specific wifi chip and copy over meta-qticonnectivity-prop and wlanproprietary into the source folder of the working directory
So now we have added additional 4 directories into the source folder of the working directory
Set up the build environment
Run bitbake core-image-minimal
and I see the following error:
ERROR: wpa-supplicant-git-r0 do_patch: Command Error: 'quilt --quiltrc <working_directory>/linux_image/build/tmp/work/imx8qxpmek-poky-linux/wpa-supplicant/git-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output:
Applying patch 0009-Sync-with-mac80211-next.git-include-uapi-linux-nl802.patch
patching file src/drivers/nl80211_copy.h
...
15 out of 20 hunks FAILED -- rejects in file src/drivers/nl80211_copy.h
Patch 0009-Sync-with-mac80211-next.git-include-uapi-linux-nl802.patch does not apply (enforce with -f)
ERROR: wpa-supplicant-git-r0 do_patch: Function failed: patch_do_patch
I'm new to yocto, and from the looks of it, it seems the patch 0009-Sync-with-mac80211-next.git-include-uapi-linux-nl802.patch didn't apply, but does that mean the issue is with the patch file or the way it's referenced.
This patch file resides in the meta-fsl-bsp-release layer under wpa-supplicant sub directory, which I DID NOT add manually. This sub-directory has a .bbappend file that refers to these patch files via SRC_URI variable, but it doesn't contain any .bb file.
One of the meta layers that I added has wpa-supplicant sub-directory as well but it only has .bb file and no .bbappend.
I'm confused as to how are these two subdirectories different or could they conflict in anyway? Also, shouldn't the subdirectory have both the .bbappend & a corresponding .bb file?
The SRC_URI variable is used to locate the applicable patch files and do_patch isn't needed in the respective .bb file of wpa-supplicant, right?
the respective bb file wpa-supplicant has the following:
SRC_URI = "file://wlan-opensource/wpa_supplicant_8/"
SRC_URI += "file://hostapdconf \
file://supplicantconf \
shouldn't patch files be defined with .patch at the end?
Also, I see in the yocto documentation that the path defined in file:// is relative to the FILESPATH variable, which in the bb file is defined to be "${BSPDIR}/sources:" - not certain of BSPDIR itself but I think it's referring to <top_dir>/sources, but does that mean hostapdconf is supposed to be at <top_dir>/sources? I don't see it there but in other sub directory
To me it looks like you have added a .bbappend for the wpa-supplicant recipe in a version that does not match the recipe. Likely the .bbappend is from one of the meta layers you copied into your source tree manually (meta-qti-connectivity or wlan-opensource).
I'm new to yocto, and from the looks of it, it seems the patch
0009-Sync-with-mac80211-next.git-include-uapi-linux-nl802.patch didn't
apply, but does that mean the issue is with the patch file or the way
it's referenced?
Likely the patch is targetet at a different version of the source file.
The SRC_URI variable is used to locate the applicable patch files and
do_patch isn't needed in the respective .bb file of wpa-supplicant,
right?
Right, if you don't see it explicitly ly in the .bb. The default do_patch task will be used.
the respective bb file wpa-supplicant has the following:
SRC_URI = "file://wlan-opensource/wpa_supplicant_8/" SRC_URI +=
"file://hostapdconf
file://supplicantconf \ shouldn't patch files be defined
with .patch at the end?
The .patch file is probably referenced by name in a .bbappend if you dont see it in the .bb file.
First some context with my problem:
I am trying to add some patches to modify some device trees from the source code used in linux-msm-4.4_git.bb recipe (which can be found in the meta-qti-bsp layer).
My linux-msm-4.4_git.bbappend looks like this:
FILESEXTRAPATHS_append := "${THISDIR}/files:"
SRC_URI += " file://0001-patching-dts-stuff_1.patch"
SRC_URI += " file://0002-patching-dts-stuff_2.patch"
SRC_URI += " file://0003-patching-dts-stuff_3.patch"
SRC_URI += " file://0004-patching-dts-stuff_4.patch"
SRC_URI += " file://0005-patching-dts-stuff_5.patch"
SRC_URI += " file://0006-patching-dts-stuff_6.patch"
SRC_URI += " file://0007-patching-dts-stuff_7.patch"
SRC_URI += " file://0008-patching-dts-stuff_8.patch"
SRC_URI += " file://0009-patching-dts-stuff_9.patch"
But when I add my layer to the build/conf/bblayers.conf the recipe fails during the task do_shared_workdir because it doesn't find the certs/signing_key.pem file.
Trying to solve that error I found the following information:
meta-qti-bsp is slightly modified from the one that can be found in it's repo (I received the code in a zip file, so I don't know how many changes to externally maintained layers are made).
I followed all includes, inheritances and requires from the recipe in order to know what was happening:
Here is an image of that.
And I discovered that do_shared_workdir is overridden from kernel.bbclass.
When my layer is not included and I launch bitbake linux-msm-4.4, the execution order of the tasks is:
fetch
unpack
prepare_recipe_sysroot
unpack
patch
configure
populate_lic
compile
shared_workdir
kernel_link_images
When my layer is included shared_workir and kernel_link_images are always swapped in execution order.
So I tried if doing "addtask shared_workdir after do_compile before kernel_link_images" in my .bbappend overrides the "addtask shared_workdir after do_compile before do_compile_kernelmodules" from kernel.bbclass, to enforce the task order that doesn't end in error, which did not.
Modifying it in kernel.bbclass did solve the error, but I would rather not have to make changes in layers that are not maintained by me.
My main question:
Is there a way to enforce the correct task order from my layer?
Another question which I would like to know the response in order to further understand the yocto framework:
If I created the layer using the command bitbake-layers add-layer meta-mylayer. I just added the same structure of recipes-*/recipe-name/recipe.bbappend that in the original layer, and this bbappend and it's files/patches are the only thing added by me. This patches and recipe do not define changes to task execution order.
Why adding my layer causes the change of order in which this tasks are executed?
My project's root folder is PROJECT, and there is only one script in PROJECT/scripts/abc.sh, which I want to install it into the directory /usr/share/xxx/abc.sh.
Because it is not install into /usr/bin/abc.sh, so bin_SCRIPTS = abc.sh is incorrect.
Could you please tell me how to write the Makefile.am?
You'll need to define the install directory:
xxxdir = $(datarootdir)/xxx
xxx_SCRIPTS = scripts/abc.sh
More typically as something like:
pkgdata_SCRIPTS = scripts/abc.sh
where automake has already setup pkgdatadir.
I'm starting out with Autotools, and I'm trying to package a library (a generic stack implementation for learning purposes) along with some usage examples.
The library source lives in src and the example in examples.
I have the following Makefile.am:
lib_LTLIBRARIES = libstack.la
libstack_la_SOURCES = src/stack.c
check_PROGRAMS = example/stack
example_stack_SOURCES = example/stack.c
example_stack_LDADD = libstack.la
As long as my understanding goes, I need to specify a header for libstack.la, and include that from my example, but I get the following error when running autoreconf after adding libstack_la_HEADERS = src/stack.h to Makefile.am:
$ autoreconf -iv
... (omiting irrelevant parts)
Makefile.am:3: error: 'libstack_la_HEADERS' is used but 'libstack_ladir' is undefined
autoreconf: automake failed with exit status: 1
I couldn't find any information related to the dir prefix.
What am I missing here?
To handle header of library you should write something like this:
libstackincludedir = $(includedir)/my_mega_stack
libstackinclude_HEADERS = stack.h
Let's say I have a project like that:
(dev dir)
- README
- INSTALL
/ src
- blah.cpp
- blah.hpp
/ conf
- blah_one.xml
- blah_two.xml
I made out a configure.ac and Makefile.am to install binaries under (/usr/local)/bin . configure.ac is something like:
AC_INIT([blah], [0.1])
AC_PREREQ([2.67])
AM_INIT_AUTOMAKE([1.11])
AC_CONFIG_SRCDIR([src/blah.cpp])
AC_PROG_CXX
AC_LANG([C++])
AC_HEADER_STDC
AC_CONFIG_FILES([Makefile])
AC_CONFIG_FILES([src/Makefile])
AC_OUTPUT
... Makefile is something like
SUBDIRS = src
...and src/Makefile.am is something like
bin_PROGRAMS = blah
blah_SOURCES = blah.cpp blah.hpp
It all works, and "make install" correctly install the binary under (/usr/local)/bin.
Now:
I want extend these to make the command "make install" (after configure, build and whatsoever) to install configuration files blah_one.xml and blah_two.xml under /etc/blah, and to "prepare" a log directory under /var/log/blah/
What is the correct way to do it?
Well, I'd do this:
blahconfdir=$(sysconfdir)/blah
blahconf_DATA = blah_one.xml blah_two.xml
blahlogdir = $(localstatedir)/log/blah
then when you configure:
./configure --sysconfdir=/etc --localstatedir=/var
Without knowing details of your "prepare" step, it's hard to know what needs to happen, and how to get it to happen.