yocto recipe gives error -dev package contains non-symlink .so - yocto

I am trying to copy some of the precompiled libraries to my core-image-minimal using a recipe.
I am getting error below
-dev package contains non-symlink .so:scripts-dev path '/work/armv7ahf-neon-poky-linux-gnueabi/scripts/1.0-r0/packages-split/scripts-dev/usr/lib/libasm-0.148.so'
I am having some libraries like libasm-0.148.so, few .so which are not having any softlink to respective versioned libraries.
SOLIBS = ".so"
SOLIBS += ".so.*"
FILES_SOLIBSDEV = ""
INSANE_SKIP_${PN} += "dev-so"
I tried many changes in the recipe like below still getting same error or different error like added to package but not shipped. Above flags I tried in the recipe.

When dealing with pre-compiled packages take a look at:
https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries
Usually the following configs fix this type of issue:
INSANE_SKIP_${PN} += " ldflags"
INHIBIT_PACKAGE_STRIP = "1"
INHIBIT_SYSROOT_STRIP = "1"
SOLIBS = ".so"
FILES_SOLIBSDEV = ""

Related

meson find_program() not finding python program in yocto environment

I have an external application that converted to an exe using pyinstaller. This needs to be added in yocto framework. But the application has a dependency on pylint & pyinstaller. pylint is already part of yocto framework. I used meson.build file in my application and have a recipe file in yocto that will source the entire application from git repo and builds using instructions in meson.build. In my application meson build file uses find_program() to find pylint program installation. It works currently on my laptop, but when I build my application recipe in yocto environment, it is unable to find pylint. Even though I added "python3-pylint" in IMAGE_INSTALL_append.
| Program python3 found: YES (.../usr/bin/python3-native/python3)
| Program python3 (pylint) found: NO
|
| ../git/src/meson.build:10:0: ERROR: python3 is missing modules: pylint
pyinst = find_program('pylint') // as per meson this is probably searching in /usr/local/bin. But this is not the case in yocto. How can I modify find_program() call to find this in the right location in yocto framework. Or is there any method to handle this?
meson.build under source file folder:
# get & run pylint to check for errors
prog = import('python').find_installation('python3', modules: ['pylint'])
if not prog.found()
message('pylint not found')
else
message(prog.path())
cmd = find_program('pylint', prog.path())
message('Running pylint on src files')
foreach each : src_files
run_command(cmd, '--confidence=HIGH', each)
endforeach
endif
project's meson.build
project('proj_name',
['cpp'],
version : '0.1',
license : 'MIT',
default_options: [
'cpp_std=c++11']
)
project_pretty_name = 'proj_name'
project_url = '<git repo of project>'
python = import('python')
python3 = python.find_installation('python3', required: false)
subdir('src')
subdir('tools') # cpp tools
subdir('build')
yocto recipe file:
inherit meson pkgconfig python3native
DEPENDS += "${PYTHON_PN}-distro-native"
DEPENDS += "zlib"
RDEPENDS:${PN} += "${PYTHON_PN}-requests \
${PYTHON_PN}-pylint"
SRC_URI += "<git branch>"
SRCREV = "<src-rev>"
S = "${WORKDIR}/git"
FILES:${PN}:append = " ${bindir}/mesonexe"
Your Meson build requires pylint to be available during compilation, therefore you need to add:
DEPENDS += "${PYTHON_PN}-pylint-native"
and then you will need to ensure the pylint recipe is available in one of your configured Yocto layers. It's in meta-openembedded/meta-python.
Finally, the python3-pylint recipe and one of its dependencies (python3-astroid) do not have native support enabled, so you'll need to create the followin .bbappends as well:
# python3-pylint_%.bbappend
BBCLASSEXTEND += "native"
# python3-astroid_%.bbappend
BBCLASSEXTEND += "native"
You should then see the following line in the Meson output:
Program pylint found: YES (.../recipe-sysroot-native/usr/bin/pylint)
As a suggestion - if this recipe is building your own source code, I'd suggest linting the code as it is pushed into the repository (via a CI job), rather than at compile-time. This will reduce the dependencies required to build your project.
Of course, there would still be an optional Meson target for developers to lint their code before they push new code. Perhaps something that is enabled for non-release builds by default.

Yocto build succeeds, but warning about missing RDEPENDS

I'm using Yocto to compile my application for my target hardware. The build succeeds, but I get a warning:
WARNING: myApplication-0.0.1-r0 do_package_qa: QA Issue: /usr/local/bin/myApplication contained in package myApplication requires libstdc++.so.6(CXXABI_1.3.3), but no providers found in RDEPENDS_myApplication? [file-rdeps]
I've added everything I can find to both the DEPENDS and RDEPENDS of my application's recipe, but I'm still getting that error.
DEPENDS += "gcc-runtime"
RDEPENDS_${PN} += "libstdc++ libstdc++-dev gcc-runtime"
Is there something I can add to my RDEPENDS to eliminate this warning?
I have also tried these other combinations, all of which resulted in a successful build, and of which give the same warning.
Both DEPENDS and RDEPENDS empty.
RDEPENDS_${PN} += "libstdc++"
RDEPENDS_${PN} += "libstdc++ libstdc++-dev
RDEPENDS_${PN} += "libstdc++ gcc-runtime DEPENDS += "gcc-runtime"
Please try to add
RDEPENDS_${PN} += "libstdc++6"
RDEPENDS needs the output package name which usually is the name of ipk or rpm and
not the recipe name which generated the given output package. Secondly packages containing only libraries also use debian library naming conventions so they get renamed like above.

How to package CMake Module in NativeSDK?

I am trying to install a set of CMake utilty functions under /usr/share/cmake-3.4/Modules/MYMODULES/useful.cmake within a Yocto build.
Here is my current (sanitized) recipe (call it my-useful-modules.bb)
SECTION = "devel"
LICENSE = "CLOSED"
inherit cmake
EXTERNALSRC := "path/to/source/code"
do_compile() {
:
}
FILES_${PN} += "${datadir}/cmake-3.4/Modules/MYMODULES/*"
BBCLASSEXTEND = "nativesdk"
The configure and install tasks work fine, and if I look under image in tmp/work/..., I see the full tree (including all my host directories as expected).
But I keep getting the following error
ERROR: nativesdk-my-useful-modules-1.0-r0 do_package: QA Issue:
nativesdk-my-useful-modules: Files/directories were installed but not
shipped in any package:
Followed by a long list of files which basically includes everything under image.
These modules need to be available both in the native sysroot during the build, and in the standard SDK built with populate_sdk.
Which package should I be specifying with FILES_${PN} to get them packaged?
I'd also appreciate knowing how to either avoid specifying the cmake version in the FILES statement, or get it from the build system.
Updating FILES_${PN} will resolve your error and also there is no need to provide cmake version in this case.
FILES_${PN} += "${datadir}/*"

bitbake recipe for copying folder, subfolders for yocto

I want copy folders and it's content to yocto during image build process. For this process I am using following recipe
SUMMARY = "Installation Recipe"
DESCRIPTION = "It installs folder"
HOMEPAGE = ""
LICENSE = "CLOSED"
MY_FILES1 = "/home/jane/d1fold"
MY_FILES2 = "/home/jane/d2fold"
inherit allarch
do_install() {
install -d ${D}/home/root
cp -R ${MY_FILES1}/* ${D}/home/root
cp -R ${MY_FILES2} ${D}/home/root
}
FILES_${PN} += " /home/root"
But I receive following error ERROR: QA Issue: weaved: Recipe inherits the allarch class, but has packaged architecture-specific binaries [arch]. How can I resolve this error?
This error means that you are trying to install architecture-specific binaries (compiled for x86, arm64 etc), while inheriting allarch class. From yocto reference manual:
The allarch class is inherited by recipes that do not produce architecture-specific output.
This is an obvious contradiction.
What are you trying to do? Creating of recipe that only installs some files seems like wrong architecture decision. And why do you want to inherit allarch?
You are just coping files to rootfs. So you no need use inherit allarch. remove that and compile.

Adding new recipe to Yocto fails during generate root fs

I have been using Yocto to create Linux builds for an ARM board.
I had been cross compiling add on applications manually. Now we are in a place where we would like a nice integrated build so I started adding custom recipes to yocto.
I have been struggling with the ARM build (a x86 build with the same code seems fine).
Even a basic 'hello world' pretty much cut and paste from the development manual does not work (http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe)
Here is the recipe:
SUMMARY = "Simple helloworld application"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
RPROVIDES_${PN} = "helloworld"
FILES_${PN} += "${bindir}"
SRC_URI = "file://helloworld.c"
S = "${WORKDIR}"
do_compile() {
${CC} helloworld.c -o helloworld ${LDFLAGS}
}
do_install() {
install -d ${D}${bindir}
install -m 0755 helloworld ${D}${bindir}
}
Here is the error:
ERROR: helloworld not found in the base feeds (smarc_samx6i cortexa9t2hf-vfp-neon-mx6qdl cortexa9hf-vfp-neon-mx6qdl cortexa9t2hf-vfp-neon cortexa9t2hf-vfp cortexa9hf-vfp-neon cortexa9hf-vfp armv7at2hf-vfp-neon armv7ahf-vfp-neon armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp armv5ehf-vfp armv5thf-vfp armv5hf-vfp noarch any all).
ERROR: Function failed: do_rootfs
Any suggestions as to what would be causing this error?
The package does build properly; the problem seems to be isolated to finding it for the rootfs.
Thanks!
EDIT:
I have a solution that seems to work, although it is not ideal long term.
Changing the package name under IMAGE_INSTALL from helloworld to helloworld-0.0.1 resolves the issue. Obviously I would rather not hard code the version of each package in the top level recipe and other packages do not require this, so hopefully there is another solution.
EDIT 2:
Renaming the recipe and removing the version string also resolves the issue. Once again, this does not seem ideal long term.
OK, after some further testing I discovered this was a naming issue with the recipe.
It was named helloworld-0.0.1.bb (the same format with the other recipes I had put together driving me to try this simple test).
If anyone else encounters this simply replacing the '-' with a '_' resolves this.
1.Rename your recipe name e.g hello-0.1.bb to hello_0.1.bb
2.Add below line at last only:
FILES_${PN} = "${bindir}/*"
Abvoe line helps you copy your binary to rootfs.