Re: [yocto] executable depends on the library that is built in the same recipe
Given it is looking for libMyTool.so and not a versioned library, my
guess is that the shared
library is not setting a proper soname when being built. All libraries
should be built with a soname,
and if done correctly should be versioned. The .so file generally
shouldn't be the runtime library
but a link back to the versioned library, so you get something that
looks like:
/usr/lib/libz.so -> libz.zo.1.2.11
/usr/lib/libz.so.1.2.11
/usr/lib/libz.so.1 -> libz.so.1
On 12/11/2017 11:45 AM, Rail Shafigulin wrote:
I have a recipe that builds a library and an executable. Executable
depends on the library which built int he same recipe. When I run
bitbake I get the following error:
WARNING: mytool-1.0+gitAUTOINC+3e2b76e330-r0 do_package_qa: QA Issue:
/bin/mytool contained in package mytool requires libMyTool.so, but no
providers found in RDEPENDS_mytool? [file-rdeps]
I tried the suggestion given by the bitbake putting mytool in
REDEPNDS_${PN}, but that didn't work. I also tried looking online for
the solution but didn't find one.
Can someone help out?
--
Jeremy A. Puhlman
jpuhl...@mvista.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release directory layout 2.3.2
Was the change to the directory structure release for 2.3.2 intentional. All the other releases are under: http://downloads.yoctoproject.org/releases/yocto/yocto- where as 2.3.2 is http://downloads.yoctoproject.org/releases/yocto/yocto-version>/yocto- -- Jeremy A. Puhlman jpuhl...@mvista.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BBMASK not working for me?
On 3/1/2017 12:06 PM, chris warth wrote: Can anyone suggest why my BBMASK is not working? Maybe I'm not putting it into the right file? Did I construct the regex incorrectly? In my conf/bblayers.conf I have, BBMASK .= "qemu" This basically concatenates qemu to what ever is already in BBMASK. It is a regex expression so you want to treat it as such. You want to likely do something like: BBMASK .= "|(qemu)" OTOH, qemu matches anythin with qemu in the path. You likely want to use the full filename: BBMASK .= "|(qemu_qoriq.bb <http://qemu_qoriq.bb>)" Then I wipe out the cache by deleting the "tmp/" directory. Now I would expect bitbake -n -c fetch qemu to give a 'Nothing PROVIDES' error. That is not what happens. Instead it still completes normally. I am trying to ignore recipes like meta-freescale/recipes-devtools/qemu/qemu_qoriq.bb <http://qemu_qoriq.bb> Thanks in advance for any help. - Chris -- Jeremy A. Puhlman jpuhl...@mvista.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Best practice for building a large amount of source files
On 12/10/2015 1:16 PM, Michael Habibi wrote:
If I have some source I want to bring into my layer, for example:
Recipe dir:
meta-mylayer/recipes-management/myapplication/myapplication_1.0/of source files>
What is the best option for adding all of these and compiling? As far
as I know, you have to do one of the following:
1) Use a fetch that fetches a tarball with all your source, or a repo
with all of your source
2) Use a million-line long SRC_URI assignment to include every file
that your application uses.
Is there a third (or fourth) option that I may have missed?
Not necessarily best practice, but it is something that bitbake has
supported.
If you create a directory under myapplication_1.0 that is unique and not
an override, you can specify the directory name
as the SRC_URI and bitbake will pull the directory and its contents in.
Something like
meta-mylayer/recipes-management/myapplication/myapplication_1.0/mysources/of source files>
and SRC_URI file://mysources
It should work.
Something like the following:
> find recipes/
recipes/
recipes/myapp
recipes/myapp/files
recipes/myapp/files/mysources
recipes/myapp/files/mysources/Makefile
recipes/myapp/myapp_1.0.bb
> cat recipes/myapp/myapp_1.0.bb
LICENSE="MIT"
LIC_FILES_CHKSUM =
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
SRC_URI = "file://mysources"
S="${WORKDIR}/mysources"
Michael
--
Jeremy A. Puhlman
jpuhl...@mvista.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Packaging an externally built library?
FILES_${PN} += " ${libdir}/*.so"
If I look through the packaging logs it looks like it attampts to
create a bunch of different packages (cdp-fsw, cdp-fsw-dbg,
cdp-fsw-dev, cdp-fsw-doc, cdp-fsw-locale) but most of them end up
being empty except cdp-fsw-dev. Then if I look through the RPMs there
is no cdp-fsw there is only a cdp-fsw-dev and cdp-fsw-dbg.
Then when do_rootfs is executed it fails because it can’t find a
package provider for cdp-fsw.
Why is it automatically creating a -dev package? Can I override
this?
Because the package list has PN at the end by default:
PACKAGES="${@bb.utils.contains('PTEST_ENABLED', '1', '${PN}-ptest', '',
d)} ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale
${PACKAGE_BEFORE_PN} ${PN}"
and
${PN}-dev lists ${libdir}/*.so
"${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la ${libdir}/*.o
${libdir}/pkgconfig ${datadir}/pkgconfig ${datadir}/aclocal
${base_libdir}/*.o ${libdir}/${BPN}/*.la ${base_libdir}/*.la"
As part of its files list.
When the packages-split directory is created, it processes the packages
list in order extracting the files for each package. When ${PN} is
processes "*.so" files have already been pulled
in to the ${PN}-dev package.
Normally in linux *.so files are symlinks to the actual versioned
libraries only used for linking. You can fix the binary libraries to
conform more correctly. If the library is using soname you will likely
need to do this
anyways to run applications linked against it. To get the soname you
would do:
-objdump -x libz.so.1 | grep SONAME
if it gives you something like:
SONAME libz.so.1
You would need to install the library with the name returned from
objdump, then create a .so symlink to that library. The versioned
library would get picked up in ${PN}.
If it is not using soname and the linked applications are really only
looking for lib.so, then you can redefine PACKAGES to include
just ${PN} or a subset of the normally defined
packages.
--
Jeremy A. Puhlman
jpuhl...@mvista.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
