[yocto] Which Toolchain is being used to build Yocto ?
Hi, Building jethro on a Ubuntu14.04 system. I want to ensure that each person in the team is using the same tool-chain version. I notice there is a meta/recipes-devtools - I assume this pulls in from build/downloads - so gcc-5.2.0.tar.bz2 for example. Does the tool-chain comprised of these recipes get built by /usr/bin/gcc before being used to compile Yocto ? If this is the case then assuming we configure for off-line builds and used the same build/downloads content as well as the oe-env ( from oe-init-build-env ) then we'll all be on the same tool-chain version. Or have I missed something ? Thanks, Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Which Toolchain is being used to build Yocto ?
Thanks. That makes sense; all the cross compile tools are built using the Host machines native toolchain on the host then the cross-toolchain used to cross compile yocto for the target. On 3 February 2016 at 17:13, Burton, Ross wrote: > > On 3 February 2016 at 15:07, Mark T wrote: > >> I notice there is a meta/recipes-devtools - I assume this pulls in from >> build/downloads - so gcc-5.2.0.tar.bz2 for example. Does the tool-chain >> comprised of these recipes get built by /usr/bin/gcc before being used to >> compile Yocto ? >> > > The host's gcc (typically /usr/bin/gcc) is used to build gcc-cross, which > is then used to compile everything that needs to be cross-compiled. We > don't build our own native compiler to replace the host compiler. > > Ross > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Conditional compile for package in layer.conf for Qemu
Hi, Is it possible to omit packages when building for Qemu ? I have a layer.conf file with various packages added via IMAGE_INSTALL_append += "package_a" IMAGE_INSTALL_append += "package_b" I'd like to be able to do the following IMAGE_INSTALL_append += "package_a" if ( not qemu ) IMAGE_INSTALL_append += "package_b" endif How can I do this? can I insert python here ? what environment variables should i be checking and what are thier values. Thanks, Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Conditional compile for package in layer.conf for Qemu
Ross,
Thanks, that " IMAGE_INSTALL_append_intel-corei7-64 = "package_b" " worked
a treat.
If I want to exclude a recipe from a layer for qemu builds - is there a
similar method for that ?
Thanks,
Mark
On 17 March 2016 at 09:10, Andre McCurdy wrote:
> On Wed, Mar 16, 2016 at 2:01 AM, Burton, Ross
> wrote:
> >
> > On 16 March 2016 at 08:56, Mark T wrote:
> >>
> >> I'd like to be able to do the following
> >>
> >> IMAGE_INSTALL_append += "package_a"
>
> It's not typical usage to combine += with _append, pick one or the other.
>
> Using _append is generally more reliable if you're not sure how the
> variable you're appending to was originally initialised, however with
> _append you need to manually include a leading space character, ie:
>
> IMAGE_INSTALL_append = " package_a"
>
> >> if ( not qemu )
> >> IMAGE_INSTALL_append += "package_b"
> >> endif
> >
> >
> > The neater way would be if you can easily identify what "not qemu" is,
> for
> > example:
> >
> > IMAGE_INSTALL_append_intel-corei7-64 = "package_b"
> >
> > Would install package_b only for intel-corei7-64 machines.
> >
> > If you want to support arbitrary machines but not qemu then something
> like
> > this might work:
> >
> > MOREDEPS = "package_b"
> > MOREDEPS_qemuall = ""
> > IMAGE_INSTALL_append = " ${MOREDEPS}"
> >
> > (qemuall is an override that is enabled by all qemu machines)
>
> Another alternative would be something like:
>
> IMAGE_INSTALL_remove_qemuall = "package_b"
>
> > Ross
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] What version of Jethro do we get with - git clone -b jethro git://git.yoctoproject.org/poky.git ?
Hi, When we started working with Yocto we cloned via - git clone -b jethro git://git.yoctoproject.org/poky.git mydir/ cd mydir git clone git://git.yoctoproject.org/meta-intel -b jethro If we do the same a month or so later do we get the same version ? we suspect not the distro version has changed. Is there a way we can clone the same version all the time ? Secondly, what should be considered a stable version to clone ? Thanks, Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What version of Jethro do we get with - git clone -b jethro git://git.yoctoproject.org/poky.git ?
Hi Christopher, Thanks. What is the command option to specify the tag and is there a list or tags available ? Cheers, Mark On 3 May 2016 at 16:23, Christopher Larson wrote: > > > On Tue, May 3, 2016 at 3:18 PM, Mark T wrote: > >> Hi, >> >> When we started working with Yocto we cloned via - >> >> git clone -b jethro git://git.yoctoproject.org/poky.git mydir/ >> cd mydir >> git clone git://git.yoctoproject.org/meta-intel -b jethro >> >> If we do the same a month or so later do we get the same version ? we >> suspect not the distro version has changed. >> >> Is there a way we can clone the same version all the time ? >> >> Secondly, what should be considered a stable version to clone ? >> > > The release branch will get bug fixes and security updates after the > release. If you don't want it to change at all, use the tag or tarballs, > not the branch. > -- > Christopher Larson > clarson at kergoth dot com > Founder - BitBake, OpenEmbedded, OpenZaurus > Maintainer - Tslib > Senior Software Engineer, Mentor Graphics > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How do I select the kernel version in Dizzy ? ( 3.10 | 3.14 | 3.17 )
Hi, The Dizzy revision looks to support 3 kernel versions ( 3.10 | 3.14 | 3.17 ). If I chose Dizzy 1.7.3 - how do I ensure the 3.10 kernel is used for the build ? Thanks, Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I select the kernel version in Dizzy ? ( 3.10 | 3.14 | 3.17 )
Thanks - that's working. Mark On 6 July 2016 at 18:53, Khem Raj wrote: > On Wed, Jul 6, 2016 at 10:40 AM, Mark T wrote: > > Hi, > > > > The Dizzy revision looks to support 3 kernel versions ( 3.10 | 3.14 | > 3.17 > > ). > > > > If I chose Dizzy 1.7.3 - how do I ensure the 3.10 kernel is used for the > > build ? > > usually you would set that in your machine conf file. > > PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" > PREFERRED_VERSION_linux-yocto ?= "3.10%" > > > > > Thanks, > > > > Mark > > > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] bitbake parsing but not attempting to build recipes in layer.
Hi, I have several recipes in a layer. I have added the layer to build/conf/bblayers.conf. The layer.conf in that layer looks correct for the BBFILES+= etc. when I run "bitbake core-image-base" the recipes are bing parsed ( as it picked up errors for missing dependencies). With those fixed it runs clean and builds successfully - but its omitted the recipes from my layer - there is nothing in build/tmp/work etc If I build my_recipe from my layer via "bitbake my_recipe" it builds and I see products in build/tmp/work etc. Any idea why its not attempting to build my_recipe when using bitbake core-image-base ? Thanks Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake parsing but not attempting to build recipes in layer.
Thanks Nicolas, I nearly had it - I'd put IMAGE_INSTALL_APPEND in my layer.conf - once I changed to _append and had a space before the recipe name it sprang into life. On 15 July 2016 at 11:35, Nicolas Dechesne wrote: > On Fri, Jul 15, 2016 at 2:26 PM, Mark T wrote: > > I have several recipes in a layer. I have added the layer to > > build/conf/bblayers.conf. > > > > The layer.conf in that layer looks correct for the BBFILES+= etc. > > > > when I run "bitbake core-image-base" the recipes are bing parsed ( as it > > picked up errors for missing dependencies). With those fixed it runs > clean > > and builds successfully - but its omitted the recipes from my layer - > there > > is nothing in build/tmp/work etc > > > > If I build my_recipe from my layer via > > "bitbake my_recipe" it builds and I see products in build/tmp/work > etc. > > > > Any idea why its not attempting to build my_recipe when using bitbake > > core-image-base ? > > You need to add your custom packages into the image. By default, they > won't be there , nor would they be built (but as you noticed your > recipes are being parsed). > > see > http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#usingpoky-extend-customimage > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] TPM2-TSS-1.1.0.bb does not use local files when BB_NO_NETWORK = "1"
Hi, We have an issue doing an off-line build for TPM2-TSS-1.1.0.bb and related packages. Its fine when BB_NO_NETWORK is not set, build/downloads has the package files and the .done. We then hold the .done and associated package files locally and place them into downloads prior to building with BB_NO_NETWORK = "1" - but the fetch fails as it will not accept the local files. Any ideas on how to resolve this ? We're using Morty. All other packages we use work fine with the local files. Cheers, Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Modifying CFLAGS in .bbappend
Hi, If I add an include path to CFLAGS in a .bbappend is it only applied for that recipe or is it present in CFLAGS for all recipes built after that ? Cheers, Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Getting recipe variables into config.m4 files
Hi,
I'm building a PHP extension. In the config.m4 file for the extension I
can add include and library paths as follows -
PHP_ADD_INCLUDE(../../../../../../../sources/inc) - works
PHP_ADD_INCLUDE($PROJ_ROOT/sources/inc) ** does not work
PHP_ADD_INCLUDE(${PROJ_ROOT}/sources/inc) ** does not work
PHP_ADD_LIBRARY(stdc++, 1, MY_TEST_SHARED_LIBADD)
where $PROJ_ROOT is define in my .bbappend. for the php recipe.
Its the include path that is not working with the variable - I just get
"-I/sources/inc" in the compile line. The relative path works but I'd like
to be able to tie the path to a variable I have control over.
Any ideas on how to achieve this ?
Cheers,
Mark
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
