[yocto] Definition of native toolchain, support for -m32?
Hi,
I'm having some trouble building chromium which I think is due to a
definition in chromium.inc which uses the host compiler rather than the
Yocto native compile toolchain
CC_host=${BUILD_CC} export CC_host
CXX_host=${BUILD_CXX} export CXX_host
This seems to map to the gcc/g++ on my host system which is surely
incorrect?
Am I right in thinking that the correct way to define the Yocto native
toolchain is using something more like this from native.bbclass?
CC_host=${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH} export CC_host
CXX_host=${CCACHE}${HOST_PREFIX}g++ ${HOST_CC_ARCH} export CXX_host
If I do this to eliminate the external dependency I run into a problem
that -m32 is not accepted by the Yocto compiler toolchain (which is
built/running on an x64 Ubuntu 14.04).
Could anybody advise on what steps I might take to have the Yocto native
compile toolchain accepting -m32?
Thanks,
Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
Have you tried setting linux-dummy as the preferred provider for the kernel ? That would skip the build processing doing anything more than satisfying the various kernel dependencies. Ah, that's a good hint, I'll try that. After your build has failed, if you look in STAGING_KERNEL_BUILDDIR do you see the abiversion file ? There are three instances of the file: ~/yocto-build-fido$ find . -name kernel-abiversion ./tmp/work/beaglebone-poky-linux-gnueabi/linux- yocto/3.14.36+gitAUTOIN C+162dfe3bb0_dbe5b52e93-r0/pkgdata/kernel-depmod/kernel-abiversion ./tmp/sysroots/beaglebone/pkgdata/kernel-depmod/kernel-abiversion ./tmp/work-shared/beaglebone/kernel-build-artifacts/kernel-abiversion Those are where I'd expect them for 1.8, so they should be found and used by the various parts of the build process. Something different is happening in your build .. hmm. It looks like those were from another run, built from scratch in a new directory I now see the following result: NOTE: Executing RunQueue Tasks ERROR: No kernel-abiversion file found (/home/astro/yocto-build-reproduce/tmp/sysroots/u159/pkgdata/kernel-depmod/kernel-abiversion), cannot run depmod, aborting ERROR: Function failed: do_rootfs ERROR: Logfile of failure stored in: /home/astro/yocto-build-reproduce/tmp/work/u159-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.7440 ERROR: Task 7 (/home/astro/git/poky/meta/recipes-core/images/core-image-minimal.bb, do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 1776 tasks of which 93 didn't need to be rerun and 1 failed. No currently running tasks (1775 of 1777) Summary: 1 task failed: /home/astro/git/poky/meta/recipes-core/images/core-image-minimal.bb, do_rootfs Summary: There were 2 ERROR messages shown, returning a non-zero exit code. astro@eldk-vm:~/yocto-build-reproduce$ find . -name kernel-abiversion astro@eldk-vm:~/yocto-build-reproduce$ bitbake -e core-image-minimal | grep STAGING_KERNEL_BUILDDIR # $STAGING_KERNEL_BUILDDIR STAGING_KERNEL_BUILDDIR=/home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts astro@eldk-vm:~/yocto-build-reproduce$ ls -la /home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts ls: cannot access /home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts: No such file or directory astro@eldk-vm:~/yocto-build-reproduce$ It looks like the entire STAGING_KERNEL_BUILDDIR is missing. I'll try some more variatons of my setup to try and narrow down why that happens. Jan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] initramfs-framework ERROR: There's no '/dev' on rootfs.
I'm trying to use initramfs-framework to mount an overlayfs, and I've got it working mostly. However, I found that when it boots, I get an error: ERROR: There's no '/dev' on rootfs. That comes from initramfs-framework's 'finish' script. I got around it by creating the /dev directory on my writable partition. I also created /proc and /sys since it looks as though those would be needed too. Would it be better to change the 'finish' script to just create the required directory(s)? E.g.: - if [ ! -d $ROOTFS_DIR/dev ]; then - fatal ERROR: There's no '/dev' on rootfs. - fi + mkdir -p $ROOTFS_DIR/dev + mkdir -p $ROOTFS_DIR/proc + mkdir -p $ROOTFS_DIR/sys -- Craig McQueen -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto linux-kernel
i am using beagleboard-xm like board for my custom use. for my development i am using yocto-dora-1.5 as bsp and kernel-2.6.32(i downgraded). while bitbaking kernel, i got error as follows: Log data follows: | DEBUG: Executing shell function do_kernel_checkout | Reinitialized existing Git repository in /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/linux-2.6.32/.git/ | On branch standard/base | nothing to commit, working directory clean | ERROR. The branch 'meta' is required and was not | found. Ensure that the SRC_URI points to a valid linux-yocto | kernel repository | WARNING: /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/run.do_kernel_checkout.32588:1 exit 1 from | exit 1 | ERROR: Function failed: do_kernel_checkout (log file is located at /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/log.do_kernel_checkout.32588) due to this error i thought error can be cleared if kernel fetched from yocto git repository, but i cat get from there, so how do i get kernel-2.6.32 for yocto project. -- thanks and regards, parthiban +919790329795 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto linux-kernel
On 2015-04-29 06:38, Parthiban Kandasamy wrote: i am using beagleboard-xm like board for my custom use. for my development i am using yocto-dora-1.5 as bsp and kernel-2.6.32(i downgraded). while bitbaking kernel, i got error as follows: Log data follows: | DEBUG: Executing shell function do_kernel_checkout | Reinitialized existing Git repository in /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/linux-2.6.32/.git/ | On branch standard/base | nothing to commit, working directory clean | ERROR. The branch 'meta' is required and was not | found. Ensure that the SRC_URI points to a valid linux-yocto | kernel repository | WARNING: /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/run.do_kernel_checkout.32588:1 exit 1 from | exit 1 | ERROR: Function failed: do_kernel_checkout (log file is located at /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/log.do_kernel_checkout.32588) due to this error i thought error can be cleared if kernel fetched from yocto git repository, but i cat get from there, so how do i get kernel-2.6.32 for yocto project. Why would you want such an old kernel for that board? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel git repo fetch issue
Thanks Khem.
The git repo can accessed by public key, so user/passwd are not need.
After changing the URL to this:
SRC_URI =
git://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH};protocol=ssh
Then “bitbake linux-lsk –c fetch” return no error, but the source folder in
working directory is empty.
In log.do_fetch
DEBUG: Fetcher failure: Fetch command failed with exit code 8, output:
http://downloads.yoctoproject.org/mirror/sources/git2_git-ccxsw.rtp.
inhouse.com. linux-lsk.tar.gz:
2015-04-29 12:49:36 ERROR 404: Not Found.
Thanks,
Joel
From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Wednesday, April 29, 2015 11:30 AM
To: Joel (Xi Zhou) Zhou
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Kernel git repo fetch issue
On Apr 29, 2015, at 8:21 AM, Joel (Xi Zhou) Zhou
joel.z...@broadcom.commailto:joel.z...@broadcom.com wrote:
So in linux-lsk_3.14.29.bb file, we define:
SRC_URI =
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH}ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=$%7bKBRANCH%7d
create a .netrc in your home folder like
machine git-ccxsw.inhouse.comhttp://git-ssxsw.inhouse.com login svcswgit
password passwd
then change the SRC_URI to something
SRC_URI =
“git://git-ccxsw.inhouse.com/linux.lsk;bareclone=1;branch=branchgit://git-ccxsw.inhouse.com/linux.lsk;bareclone=1;branch=%3Cbranch%3E;protocol=ssh
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Eclipse build of existing cmake project
Hello Ruben, What I did: I built an image and support for eclipse (meta-ide-support) for beagle bone black (BBB). I am able to create a new project in eclipse and build and run this new project on my hardware. I have an existing CMAKE project which should run on BBB. I know how to write an recipe for my project and build this existing project with bitbake. What I want to do: I want to build my existing cmake project with eclipse. Is there any possibility to import existing cmake projects to eclipse and do a build using yocto toolchain? The easiest way to do this is to create a Hello World C CMake Project with the template provided by the Yocto plugin and import your source and CMakeLists.txt file in place of the default main.c and CMakeLists.txt. Regards, Todor -- Ruben Schwarz | SOTEC | r.schw...@sotec.eu | T +49 7033 5458 34 | F +49 7033 5458 95 www.sotec.eu | www.cloudwuerdig.com -- SOTEC Software Entwicklungs GmbH + Co Mikrocomputertechnik KG Calwer Straße 11, D-75395 Ostelsheim Sitz Ostelsheim, Amtsgericht Stuttgart HRA 330821/HRB 330664, Geschäftsführer: Florian Holz Cloudwürdig® ist eine eingetragene Marke der SOTEC Software Entwicklungs GmbH + Co Mikrocomputertechnik KG Der Inhalt dieser e-Mail ist ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser e-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser e-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der e-Mail in Verbindung zu setzen. The content of this e-mail is meant exclusively for the person to whom it is addressed. If you are not the person to whom this e-mail is addressed or his/her representative, please be informed, that any form of knowledge, publication, duplication or distribution of the content of this e-mail is inadmissible. We ask you, therefore, in such a case to please contact the sender of this e-mail. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto smime.p7s Description: S/MIME cryptographic signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel customized do_fetch issue
Thanks Bruce! You really aren't seeing anything land in the build/downloads/git2/ directory structure ? ssh fetches seem to work here. I do see something in build/downloads/git2/git-ccxsw.xxx.com.linux-lsk, but it looks like an empty git. HEAD branches config description hooks info objects packed-refs refs I bring up this issue to IT department, what they said is, the Yocto expects the url contains host/repo, while gitolit requires host:repo. This is interesting since the Yocto documentation explicitly mentions gitolite in the SCM section: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#best-practices-source-control-management Thanks, Joel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Kernel customized do_fetch issue
Hi all,
I created a do_fetch() for checkout in-house git repo, which is working fine
with OE.
do_fetch() {
cd ${WORKDIR}
rm -rf ${PN}-${PV}
git clone ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk ${PN}-${PV}
cd ${PN}-${PV}
git checkout ${KBRANCH}
}
With Yocto, the do_fetch() does its job, but do_configure create an issue.
do_configure_prepend() {
cp ${WORKDIR}/${KERNEL_CONFIG_FILE} ${S}/.config
oe_runmake oldconfig
}
The do_configure error message:
| make: *** No rule to make target `oldconfig'. Stop.
Basically, the kernel source checkout by do_fetch() is delete/erase while
running do_configure().
I suspect some tasks between do_fetch and do_configure are doing some magic
work of moving the kernel source around.
Any suggestion?
Thanks,
Joel
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel customized do_fetch issue
On 2015-04-29 02:08 PM, Joel (Xi Zhou) Zhou wrote:
But the question has to be asked. Why exactly are you manually fetching
the kernel ? The fetcher can take care of most everything.
The whole story is starting at the url of our git repo. We have a git URL like:
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk
So the SRC_URI like this, but the fetcher try to apply scp over it.
KBRANCH= 3.14_common_dev
SRC_URI =
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH}
Error:
ERROR: Fetcher failure: Fetch command failed with exit code 1, output:
FATAL: unknown git/gitolite command: 'scp -r -f linux-lsk'
Then I change it according the suggestion in this mailing list:
SRC_URI =
git://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH};protocol=ssh
This time bitbake linux-lsk -c fetch return no error, but the source folder
in working directory is empty.
In log.do_fetch
DEBUG: Fetcher failure: Fetch command failed with exit code 8, output:
http://downloads.yoctoproject.org/mirror/sources/git2_git-ccxsw.rtp.
inhouse.com. linux-lsk.tar.gz:
2015-04-29 12:49:36 ERROR 404: Not Found.
I'd expect that it part of the log, since obviously the mirrors aren't
going to have a copy of your kernel.
You really aren't seeing anything land in the build/downloads/git2/
directory structure ? ssh fetches seem to work here.
You'd be better of working through the issues and getting the right
SRC_URI specification for the fetcher, since taking the fetch into a
custom routine is going to short circuit parts of the build .. and you'll
have to take care of them yourself.
Cheers,
Bruce
Thanks,
Joel
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to create a gz file with compiled files from other recipes
Hello, I have created some recipes which using an external mingw toolchain are able to compile some libraries for windows (e.g. clutter, mx, ) Now I would like to create a compressed file with all the compiled dlls (and if possible header files). How can I do that? (I have tried to create an image but when I do that also some other packages, e.g., kernel, that I do not need/want are included). Thanks, Francis. CONFIDENTIALITY: The contents of this e-mail are confidential and intended only for the above addressee(s). If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, copying or delivering it to anyone else or using it in any unauthorized manner is prohibited and may be unlawful. If you receive this e-mail by mistake, please notify the sender and the systems administrator at straym...@tttech.com immediately. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel customized do_fetch issue
On 2015-04-29 01:39 PM, Joel (Xi Zhou) Zhou wrote:
Hi all,
I created a do_fetch() for checkout in-house git repo, which is working
fine with OE.
do_fetch() {
cd ${WORKDIR}
rm -rf ${PN}-${PV}
git clone ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk ${PN}-${PV}
cd ${PN}-${PV}
git checkout ${KBRANCH}
}
With Yocto, the do_fetch() does its job, but do_configure create an issue.
do_configure_prepend() {
cp ${WORKDIR}/${KERNEL_CONFIG_FILE} ${S}/.config
oe_runmake oldconfig
}
The do_configure error message:
| make: *** No rule to make target `oldconfig'. Stop.
Basically, the kernel source checkout by do_fetch() is delete/erase
while running do_configure().
I suspect some tasks between do_fetch and do_configure are doing some
magic work of moving the kernel source around.
It's better if you can post your entire kernel recipe, and what
branch/release you are using.
There are steps that move the kernel source into work-shared, so that
may be impacting your flow.
But the question has to be asked. Why exactly are you manually fetching
the kernel ? The fetcher can take care of most everything.
If you need to modify the source directory later, have a look at the
steps that I'm taking in kernel-yocto.bbclass, since that works properly
within the fetcher and build infrastructure.
Bruce
Any suggestion?
Thanks,
Joel
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel customized do_fetch issue
But the question has to be asked. Why exactly are you manually fetching
the kernel ? The fetcher can take care of most everything.
The whole story is starting at the url of our git repo. We have a git URL like:
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk
So the SRC_URI like this, but the fetcher try to apply scp over it.
KBRANCH= 3.14_common_dev
SRC_URI =
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH}
Error:
ERROR: Fetcher failure: Fetch command failed with exit code 1, output:
FATAL: unknown git/gitolite command: 'scp -r -f linux-lsk'
Then I change it according the suggestion in this mailing list:
SRC_URI =
git://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH};protocol=ssh
This time bitbake linux-lsk -c fetch return no error, but the source folder
in working directory is empty.
In log.do_fetch
DEBUG: Fetcher failure: Fetch command failed with exit code 8, output:
http://downloads.yoctoproject.org/mirror/sources/git2_git-ccxsw.rtp.
inhouse.com. linux-lsk.tar.gz:
2015-04-29 12:49:36 ERROR 404: Not Found.
Thanks,
Joel
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] YP 1.8 Release Survey/Retrospective - REMINDER
All, Yocto Project 1.8 released last week! YP provides a major release every six months, and as an open source project we are always working to improve our processes. This survey is for the Yocto Project community to provide feedback into the development process. We would greatly appreciate your participation, especially if you have participated in the development process for 1.8 by writing code, submitting bugs, patches, documentation, contributing to the wiki, or actively participating on the mailing lists or IRC channels. https://www.surveymonkey.com/r/SFV7VPH Thanks for being an important part of the Yocto Project community! Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone: (503) 712-0534 *Cell:(208) 244-4460 * Email: stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto linux-kernel
On 2015-04-29 07:11, Parthiban Kandasamy wrote: our previous development was in kernel-2.6.32, so we do not like change the kernel level specification for new project because i/o interfaces is like previous project and we are upgrading only processor card only, so we like to go on same kernel. Please keep your replies on the mailing list so that all may benefit. It's understandable that you would want to keep with familiar versions but 2.6.32 dates from 2009, many years before the BeagleBoard was even created. It is unlikely that a kernel from that period would run on that board. Also, much of the Yocto infrastructure (e.g. udev) relies on much newer kernels to function properly. If you want to use newer hardware, you are inevitably going to need the newer software that goes with it. On 29 April 2015 at 18:13, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2015-04-29 06:38, Parthiban Kandasamy wrote: i am using beagleboard-xm like board for my custom use. for my development i am using yocto-dora-1.5 as bsp and kernel-2.6.32(i downgraded). while bitbaking kernel, i got error as follows: Log data follows: | DEBUG: Executing shell function do_kernel_checkout | Reinitialized existing Git repository in /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/linux-2.6.32/.git/ | On branch standard/base | nothing to commit, working directory clean | ERROR. The branch 'meta' is required and was not | found. Ensure that the SRC_URI points to a valid linux-yocto | kernel repository | WARNING: /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/run.do_kernel_checkout.32588:1 exit 1 from | exit 1 | ERROR: Function failed: do_kernel_checkout (log file is located at /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/log.do_kernel_checkout.32588) due to this error i thought error can be cleared if kernel fetched from yocto git repository, but i cat get from there, so how do i get kernel-2.6.32 for yocto project. Why would you want such an old kernel for that board? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org mailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- thanks and regards, parthiban +919790329795 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
I've just encountered the exact same issue upgrading. Have you tried setting linux-dummy as the preferred provider for the kernel ? That would skip the build processing doing anything more than satisfying the various kernel dependencies. We do explicitly set preferred provider to linux-dummy, in our layer. STAGING_KERNEL_builddir=./armv7/kernel-build-artifacts-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto linux-kernel
On 04/29/2015 08:38 AM, Parthiban Kandasamy wrote: i am using beagleboard-xm like board for my custom use. for my development i am using yocto-dora-1.5 as bsp and kernel-2.6.32(i downgraded). while bitbaking kernel, i got error as follows: Log data follows: | DEBUG: Executing shell function do_kernel_checkout | Reinitialized existing Git repository in /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/linux-2.6.32/.git/ | On branch standard/base | nothing to commit, working directory clean | ERROR. The branch 'meta' is required and was not | found. Ensure that the SRC_URI points to a valid linux-yocto | kernel repository | WARNING: /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/run.do_kernel_checkout.32588:1 exit 1 from | exit 1 | ERROR: Function failed: do_kernel_checkout (log file is located at /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/log.do_kernel_checkout.32588) due to this error i thought error can be cleared if kernel fetched from yocto git repository, but i cat get from there, so how do i get kernel-2.6.32 for yocto project. There isn't a released 2.6.32 linux-yocto version, so if you really want that old version, you'd need to create a linux-yocto-custom recipe for the version (unless that is what you already did). Bruce -- thanks and regards, parthiban +919790329795 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto linux-kernel
On 2015-04-29 09:20 AM, Bruce Ashfield wrote: On 04/29/2015 08:38 AM, Parthiban Kandasamy wrote: i am using beagleboard-xm like board for my custom use. for my development i am using yocto-dora-1.5 as bsp and kernel-2.6.32(i downgraded). while bitbaking kernel, i got error as follows: Log data follows: | DEBUG: Executing shell function do_kernel_checkout | Reinitialized existing Git repository in /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/linux-2.6.32/.git/ | On branch standard/base | nothing to commit, working directory clean | ERROR. The branch 'meta' is required and was not | found. Ensure that the SRC_URI points to a valid linux-yocto | kernel repository | WARNING: /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/run.do_kernel_checkout.32588:1 exit 1 from | exit 1 | ERROR: Function failed: do_kernel_checkout (log file is located at /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/log.do_kernel_checkout.32588) due to this error i thought error can be cleared if kernel fetched from yocto git repository, but i cat get from there, so how do i get kernel-2.6.32 for yocto project. There isn't a released 2.6.32 linux-yocto version, so if you really want that old version, you'd need to create a linux-yocto-custom recipe for the version (unless that is what you already did). Bruce -- thanks and regards, parthiban +919790329795 The only reason to use such a old kernel is for one of two reasons in my experience either it's on custom hardware and written by a vendor supporting that hardware or people want to run a long term supported kernel. I am wondering of the two which one are you under Parthiban. Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] meta-ivi meta-raspberrypi
On 29/04/2015 15:30, Oliver wrote: Hello I have been working building together the meta-raspberrypi the meta-ivi layers. I have been stuck with configuration/compilation of weston(from mata-ivi layer): 1) You can check the intial thread http://lists.genivi.org/pipermail/genivi-meta-ivi/2015-April/000508.html egl provided by userlad is not detected as the *.pc files are not deployed Someone has faced similar problems: http://git.buildroot.net/buildroot/commit/?id=2282b93f4248a32de84805456efa352f69b28624 2) With this I am able to reach the do_compile stage but there are errors related to the undefined type PFNEGLQUERYWAYLANDBUFFERWL Hacked this one forcing the inclusion of weston-egl-ext.h :-S 3) At linking time the next trouble is: /home/oliver/raspberry/build-rpi-ivi/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld: cannot find -lwayland-egl IIRC this lib is provided by mesa-gl, but in my build, mesa is configured(--disable-egl (is this ok being provided by userlad?)) which might be the reason why libwayland-egl is not getting deployed in the image? Any correction to my statements or hint to go further would be appreciated Best Regards thanks for your time Oliver Hi Oliver, I was looking at wayland/weston last year. I can't remember exactly where I was at with it I am afraid, but I think I had it building and have pushed some of the code I was playing with to GitHub I think this was related to the .pc issue https://github.com/DynamicDevices/meta-raspberrypi/commit/491dd14585efdb52378a57fa6ddacb1f15065257 And this was what I was doing with weston. Looks like I was disabling EGL. https://github.com/DynamicDevices/meta-raspberrypi/commit/c657f69deb57035fc43319dd7d41745c17d7d6e1 Sorry I can't be more help but perhaps there's something in there that might be of use. Regards, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On 04/29/2015 03:38 AM, Schaumlöffel, Jan wrote: Have you tried setting linux-dummy as the preferred provider for the kernel ? That would skip the build processing doing anything more than satisfying the various kernel dependencies. Ah, that's a good hint, I'll try that. After your build has failed, if you look in STAGING_KERNEL_BUILDDIR do you see the abiversion file ? There are three instances of the file: ~/yocto-build-fido$ find . -name kernel-abiversion ./tmp/work/beaglebone-poky-linux-gnueabi/linux- yocto/3.14.36+gitAUTOIN C+162dfe3bb0_dbe5b52e93-r0/pkgdata/kernel-depmod/kernel-abiversion ./tmp/sysroots/beaglebone/pkgdata/kernel-depmod/kernel-abiversion ./tmp/work-shared/beaglebone/kernel-build-artifacts/kernel-abiversion Those are where I'd expect them for 1.8, so they should be found and used by the various parts of the build process. Something different is happening in your build .. hmm. It looks like those were from another run, built from scratch in a new directory I now see the following result: NOTE: Executing RunQueue Tasks ERROR: No kernel-abiversion file found (/home/astro/yocto-build-reproduce/tmp/sysroots/u159/pkgdata/kernel-depmod/kernel-abiversion), cannot run depmod, aborting ERROR: Function failed: do_rootfs ERROR: Logfile of failure stored in: /home/astro/yocto-build-reproduce/tmp/work/u159-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.7440 ERROR: Task 7 (/home/astro/git/poky/meta/recipes-core/images/core-image-minimal.bb, do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 1776 tasks of which 93 didn't need to be rerun and 1 failed. No currently running tasks (1775 of 1777) Summary: 1 task failed: /home/astro/git/poky/meta/recipes-core/images/core-image-minimal.bb, do_rootfs Summary: There were 2 ERROR messages shown, returning a non-zero exit code. astro@eldk-vm:~/yocto-build-reproduce$ find . -name kernel-abiversion astro@eldk-vm:~/yocto-build-reproduce$ bitbake -e core-image-minimal | grep STAGING_KERNEL_BUILDDIR # $STAGING_KERNEL_BUILDDIR STAGING_KERNEL_BUILDDIR=/home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts astro@eldk-vm:~/yocto-build-reproduce$ ls -la /home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts ls: cannot access /home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts: No such file or directory astro@eldk-vm:~/yocto-build-reproduce$ It looks like the entire STAGING_KERNEL_BUILDDIR is missing. I'll try some more variatons of my setup to try and narrow down why that happens. That is really odd. I'll be interested to hear how that happened. I just did a test and it points to where I expect: [/home/bruc...poky/build] bitbake -e core-image-minimal | grep STAGING_KERNEL_BUILDDIR # $STAGING_KERNEL_BUILDDIR STAGING_KERNEL_BUILDDIR=/home/bruce/poky/build/tmp/work-shared/qemux86-64/kernel-build-artifacts Bruce Jan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] meta-ivi meta-raspberrypi
Hello I have been working building together the meta-raspberrypi the meta-ivi layers. I have been stuck with configuration/compilation of weston(from mata-ivi layer): 1) You can check the intial thread http://lists.genivi.org/pipermail/genivi-meta-ivi/2015-April/000508.html egl provided by userlad is not detected as the *.pc files are not deployed Someone has faced similar problems: http://git.buildroot.net/buildroot/commit/?id=2282b93f4248a32de84805456efa352f69b28624 2) With this I am able to reach the do_compile stage but there are errors related to the undefined type PFNEGLQUERYWAYLANDBUFFERWL Hacked this one forcing the inclusion of weston-egl-ext.h :-S 3) At linking time the next trouble is: /home/oliver/raspberry/build-rpi-ivi/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld: cannot find -lwayland-egl IIRC this lib is provided by mesa-gl, but in my build, mesa is configured(--disable-egl (is this ok being provided by userlad?)) which might be the reason why libwayland-egl is not getting deployed in the image? Any correction to my statements or hint to go further would be appreciated Best Regards thanks for your time Oliver -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Heads up
This is just a note that the recent upgrade of util-linux to version 2.26.1 (from 2.25.2) was much more major than the version change implies. The 'sfdisk' tool changed a lot and will no longer be compatible with many scripts out there that still use it. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Eclipse build of existing cmake project
Hi everybody, What I did: I built an image and support for eclipse (meta-ide-support) for beagle bone black (BBB). I am able to create a new project in eclipse and build and run this new project on my hardware. I have an existing CMAKE project which should run on BBB. I know how to write an recipe for my project and build this existing project with bitbake. What I want to do: I want to build my existing cmake project with eclipse. Is there any possibility to import existing cmake projects to eclipse and do a build using yocto toolchain? Best regards Ruben -- Ruben Schwarz | SOTEC | r.schw...@sotec.eu | T +49 7033 5458 34 | F +49 7033 5458 95 -- www.sotec.eu | www.cloudwuerdig.com -- SOTEC Software Entwicklungs GmbH + Co Mikrocomputertechnik KG Calwer Straße 11, D-75395 Ostelsheim Sitz Ostelsheim, Amtsgericht Stuttgart HRA 330821/HRB 330664, Geschäftsführer: Florian Holz Cloudwürdig® ist eine eingetragene Marke der SOTEC Software Entwicklungs GmbH + Co Mikrocomputertechnik KG Der Inhalt dieser e-Mail ist ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser e-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser e-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der e-Mail in Verbindung zu setzen. The content of this e-mail is meant exclusively for the person to whom it is addressed. If you are not the person to whom this e-mail is addressed or his/her representative, please be informed, that any form of knowledge, publication, duplication or distribution of the content of this e-mail is inadmissible. We ask you, therefore, in such a case to please contact the sender of this e-mail. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Heads up
On Wed, 29 Apr 2015, Gary Thomas wrote: This is just a note that the recent upgrade of util-linux to version 2.26.1 (from 2.25.2) was much more major than the version change implies. The 'sfdisk' tool changed a lot and will no longer be compatible with many scripts out there that still use it. i remember mentioning this on the beagleboard ML back in january: https://www.mail-archive.com/beagleboard@googlegroups.com/msg23943.html rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Kernel git repo fetch issue
Hi all,
We have an in-house git repo for Linux kernel:
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk
So in linux-lsk_3.14.29.bb file, we define:
SRC_URI =
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH}
Then 'bitbake linux-lsk' can't fetch the URL:
ERROR: Fetcher failure: Fetch command failed with exit code 1, output:
FATAL: unknown git/gitolite command: 'scp -r -f linux-linaro-stable'
ERROR: Function failed: Fetcher failure for URL: '
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=3.14_common_dev'.
Unable to fetch URL from any source.
Any idea how to fix this issue?
Thanks,
Joel
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel git repo fetch issue
On Apr 29, 2015, at 8:21 AM, Joel (Xi Zhou) Zhou joel.z...@broadcom.com
wrote:
So in linux-lsk_3.14.29.bb file, we define:
SRC_URI =
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH}
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH}
create a .netrc in your home folder like
machine git-ccxsw.inhouse.com http://git-ssxsw.inhouse.com/ login svcswgit
password passwd
then change the SRC_URI to something
SRC_URI = “git://git-ccxsw.inhouse.com/linux.lsk;bareclone=1;branch=branch
git://git-ccxsw.inhouse.com/linux.lsk;bareclone=1;branch=%3Cbranch%3E;protocol=ssh--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Deploying linux-ti-staging initramfs kernel into /boot
I'm using linux-ti-staging kernel 3.14.x with Yocto dizzy, for a build for BeagleBone Black based system. I'd like to use initramfs in my kernel. So I've set INITRAMFS_IMAGE in my linux-ti-staging_3.14.bbappend, and INITRAMFS_IMAGE_BUNDLE = 1 in local.conf. Now in build dir tmp/deploy/images/boardname I'm getting zImage-initramfs-boardname.bin being built fine. However, I'm not getting an initramfs image being deployed to /boot, but just a plain zImage without an initramfs. Looking in the build directory tmp/work/boardname-poky-linux-gnueabi/linux-ti-staging/3.14.39-r22b+gitrAUTOINC+ba552b4bc7/packages-split/kernel-image/boot I see there is: zImage-3.14.39 zImage-initramfs-boardname.bin --however the zImage-initramfs-boardname.bin file isn't being included in deploy-rpms/boardname/kernel-image-3.14.39-3.14.39-r22b+gitrAUTOINC+ba552b4bc7.boardname.rpm for some reason. But, if I change my linux-ti-staging_3.14.bbappend to include any one of the following lines, then the kernel-image .rpm file _does_ include both zImage files: RDEPENDS_kernel-base = RDEPENDS_kernel-base = kernel-devicetree RDEPENDS_kernel-base = kernel-image But if I put: RDEPENDS_kernel-base = kernel-image kernel-devicetree --then there is no zImage-initramfs-boardname.bin in the kernel-image .rpm. This seems very confusing. Why would zImage-initramfs-boardname.bin disappear from the kernel-image package when the linux-ti-staging RDEPENDS_kernel-base specifies both kernel-image and kernel-devicetree, but not other cases? -- Craig McQueen -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libgomp inclusion
Thanks for the info.. Yes, that does the trick..
Thanks
Suresh
On Mon, Apr 27, 2015 at 11:40 AM, Khem Raj raj.k...@gmail.com wrote:
On Apr 27, 2015, at 11:32 AM, Suresh Nagarajan sureshnagar...@gmail.com
wrote:
Hi,
I'm trying to look to see if OpenMP library is included in my yocto build.
I could not find libgomp library in /usr/lib
However, when I look at gcc-runtime.inc, I do notice that
RUNTIMETARGET = libssp libstdc++-v3 libgomp
PACKAGES = \
${PN}-dbg \
libstdc++ \
libstdc++-precompile-dev \
libstdc++-dev \
libstdc++-staticdev \
libg2c \
libg2c-dev \
libssp \
libssp-dev \
libssp-staticdev \
libgfortran \
libgfortran-dev \
libgfortran-staticdev \
libmudflap \
libmudflap-dev \
libmudflap-staticdev \
libquadmath \
libquadmath-dev \
libquadmath-staticdev \
libgomp \
libgomp-dev \
libgomp-staticdev \
Also, I noticed that in gmane and other web-pages that it is OK to have
INTIAL/INTERMEDIATE EXTRA_OECONF to have --disable-libgomp
However, it is not disabled in BASE which reads
EXTRA_OECONF_BASE = --enable-lto \
--enable-libssp \
--disable-bootstrap \
--disable-libmudflap \
--with-system-zlib \
--with-linker-hash-style=${LINKER_HASH_STYLE} \
--enable-linker-build-id \
--with-ppl=no \
--with-cloog=no \
--enable-checking=release \
--enable-cheaders=c_global
Also, it is mentioned that see below
Autoconf will not detect OpenMP after this change, because it will
build and run a target binary on the build system. In order to use
OpenMP, the variable ac_cv_prog_c_openmp=-fopenmp must be set.
Where exactly are we supposed to set this variable
ac_cv_prog_c_openmp=-fopenmp?
You might have to add it to your image via IMAGE_INSTALL or some such
Thanks
Suresh
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] meta-ivi meta-raspberrypi
On 29/04/2015 16:34, Mauro Carvalho Chehab wrote: Em Wed, 29 Apr 2015 16:05:58 +0200 Alex J Lennon ajlen...@dynamicdevices.co.uk escreveu: On 29/04/2015 15:30, Oliver wrote: Hello I have been working building together the meta-raspberrypi the meta-ivi layers. I have been stuck with configuration/compilation of weston(from mata-ivi layer): 1) You can check the intial thread http://lists.genivi.org/pipermail/genivi-meta-ivi/2015-April/000508.html egl provided by userlad is not detected as the *.pc files are not deployed Someone has faced similar problems: http://git.buildroot.net/buildroot/commit/?id=2282b93f4248a32de84805456efa352f69b28624 2) With this I am able to reach the do_compile stage but there are errors related to the undefined type PFNEGLQUERYWAYLANDBUFFERWL Hacked this one forcing the inclusion of weston-egl-ext.h :-S 3) At linking time the next trouble is: /home/oliver/raspberry/build-rpi-ivi/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld: cannot find -lwayland-egl IIRC this lib is provided by mesa-gl, but in my build, mesa is configured(--disable-egl (is this ok being provided by userlad?)) which might be the reason why libwayland-egl is not getting deployed in the image? Any correction to my statements or hint to go further would be appreciated Best Regards thanks for your time Oliver Hi Oliver, I was looking at wayland/weston last year. I can't remember exactly where I was at with it I am afraid, but I think I had it building and have pushed some of the code I was playing with to GitHub I think this was related to the .pc issue https://github.com/DynamicDevices/meta-raspberrypi/commit/491dd14585efdb52378a57fa6ddacb1f15065257 And this was what I was doing with weston. Looks like I was disabling EGL. https://github.com/DynamicDevices/meta-raspberrypi/commit/c657f69deb57035fc43319dd7d41745c17d7d6e1 Sorry I can't be more help but perhaps there's something in there that might be of use. I was able to build weston/wayland with meta-raspberrypi, for the Tizen distro: http://blogs.s-osg.org/bringing-tizen-to-a-raspberry-pi-2-near-you/ I had to apply a few patches to make it work on both Tizen and meta-raspberrypi. The forks are at: http://git.s-osg.org/ The current version there is actually disabling EGL. Enabling it seems to be possible, but we're still trying to make it work (it compiles fine, though, so I think we're close). Once done, my plan is to work on porting the patches back to meta-raspberrypi (and tizen-distro). Great news Mauro. If you need anybody to test out your patches, when ready, please give me a shout. Cheers, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] libgomp inclusion
Hi,
I'm trying to look to see if OpenMP library is included in my yocto build.
I could not find libgomp library in /usr/lib
However, when I look at gcc-runtime.inc, I do notice that
RUNTIMETARGET = libssp libstdc++-v3 libgomp
PACKAGES = \
${PN}-dbg \
libstdc++ \
libstdc++-precompile-dev \
libstdc++-dev \
libstdc++-staticdev \
libg2c \
libg2c-dev \
libssp \
libssp-dev \
libssp-staticdev \
libgfortran \
libgfortran-dev \
libgfortran-staticdev \
libmudflap \
libmudflap-dev \
libmudflap-staticdev \
libquadmath \
libquadmath-dev \
libquadmath-staticdev \
libgomp \
libgomp-dev \
libgomp-staticdev \
Also, I noticed that in gmane and other web-pages that it is OK to have
INTIAL/INTERMEDIATE EXTRA_OECONF to have --disable-libgomp
However, it is not disabled in BASE which reads
EXTRA_OECONF_BASE = --enable-lto \
--enable-libssp \
--disable-bootstrap \
--disable-libmudflap \
--with-system-zlib \
--with-linker-hash-style=${LINKER_HASH_STYLE} \
--enable-linker-build-id \
--with-ppl=no \
--with-cloog=no \
--enable-checking=release \
--enable-cheaders=c_global
Also, it is mentioned that see below
Autoconf will not detect OpenMP after this change, because it will
build and run a target binary on the build system. In order to use
OpenMP, the variable ac_cv_prog_c_openmp=-fopenmp must be set.
Where exactly are we supposed to set this variable ac_cv_prog_c_openmp=-fopenmp?
Thanks
Suresh
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
I've just encountered the exact same issue upgrading. Have you tried setting linux-dummy as the preferred provider for the kernel ? That would skip the build processing doing anything more than satisfying the various kernel dependencies. We do explicitly set preferred provider to linux-dummy, in our layer. STAGING_KERNEL_builddir=./armv7/kernel-build-artifacts-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] meta-ivi meta-raspberrypi
Em Wed, 29 Apr 2015 16:05:58 +0200 Alex J Lennon ajlen...@dynamicdevices.co.uk escreveu: On 29/04/2015 15:30, Oliver wrote: Hello I have been working building together the meta-raspberrypi the meta-ivi layers. I have been stuck with configuration/compilation of weston(from mata-ivi layer): 1) You can check the intial thread http://lists.genivi.org/pipermail/genivi-meta-ivi/2015-April/000508.html egl provided by userlad is not detected as the *.pc files are not deployed Someone has faced similar problems: http://git.buildroot.net/buildroot/commit/?id=2282b93f4248a32de84805456efa352f69b28624 2) With this I am able to reach the do_compile stage but there are errors related to the undefined type PFNEGLQUERYWAYLANDBUFFERWL Hacked this one forcing the inclusion of weston-egl-ext.h :-S 3) At linking time the next trouble is: /home/oliver/raspberry/build-rpi-ivi/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld: cannot find -lwayland-egl IIRC this lib is provided by mesa-gl, but in my build, mesa is configured(--disable-egl (is this ok being provided by userlad?)) which might be the reason why libwayland-egl is not getting deployed in the image? Any correction to my statements or hint to go further would be appreciated Best Regards thanks for your time Oliver Hi Oliver, I was looking at wayland/weston last year. I can't remember exactly where I was at with it I am afraid, but I think I had it building and have pushed some of the code I was playing with to GitHub I think this was related to the .pc issue https://github.com/DynamicDevices/meta-raspberrypi/commit/491dd14585efdb52378a57fa6ddacb1f15065257 And this was what I was doing with weston. Looks like I was disabling EGL. https://github.com/DynamicDevices/meta-raspberrypi/commit/c657f69deb57035fc43319dd7d41745c17d7d6e1 Sorry I can't be more help but perhaps there's something in there that might be of use. I was able to build weston/wayland with meta-raspberrypi, for the Tizen distro: http://blogs.s-osg.org/bringing-tizen-to-a-raspberry-pi-2-near-you/ I had to apply a few patches to make it work on both Tizen and meta-raspberrypi. The forks are at: http://git.s-osg.org/ The current version there is actually disabling EGL. Enabling it seems to be possible, but we're still trying to make it work (it compiles fine, though, so I think we're close). Once done, my plan is to work on porting the patches back to meta-raspberrypi (and tizen-distro). The egl-enabled version (with doesn't run, currently), is at the devel branch at both git trees. I hope that helps. Regards, Mauro -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
