* Yocto and Google protobuffer @ 2016-08-31 16:44 Pietro 2016-09-01 7:50 ` Maciej Borzęcki 0 siblings, 1 reply; 21+ messages in thread From: Pietro @ 2016-08-31 16:44 UTC (permalink / raw) To: yocto Hi all, I am new to the Yocto building system and I could be talking nonsense. I used to work with buildroot time ago and I remember there is an area where compiled software/packages/tools previously built are "staged" and used when building other packages. Is there something like that available with Yocto ? Specifically I would like to add a package which uses the Google Protocol Buffer, I do not have administrator rights on the machine and I can't install the packages I need system wise. Is it possible to add recipes and use them at building time without including them in the image being generated ? A good example for that would be the protoc, the protocol buffer description file compiler. Thanks in advance, Pietro. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-08-31 16:44 Yocto and Google protobuffer Pietro @ 2016-09-01 7:50 ` Maciej Borzęcki 2016-09-01 8:40 ` Pietro 0 siblings, 1 reply; 21+ messages in thread From: Maciej Borzęcki @ 2016-09-01 7:50 UTC (permalink / raw) To: Pietro; +Cc: yocto On Wed, Aug 31, 2016 at 6:44 PM, Pietro <pulsarpietro@posteo.net> wrote: > Hi all, > > I am new to the Yocto building system and I could be talking nonsense. I > used to work with buildroot time ago and I remember there is an area > where compiled software/packages/tools previously built are "staged" and > used when building other packages. > > Is there something like that available with Yocto ? Specifically I would > like to add a package which uses the Google Protocol Buffer, I do not have > administrator rights on the machine and I can't install the packages I > need system wise. > > Is it possible to add recipes and use them at building time without > including them in the image being generated ? > > A good example for that would be the protoc, the protocol buffer description > file compiler. > There is a recipe for protobuf in meta-oe (2.6.1). All you need to do, is include meta-oe in your layers (bblayers.conf) and have protobuf-native listed in DEPENDS inside your package recipe. The protoc compiler will be available in the PATH when package is being built, so autotools checks like AC_CHECK_PROG/AC_PATH_PROG should be able to find it. Cheers, -- Maciej Borzecki RnDity ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 7:50 ` Maciej Borzęcki @ 2016-09-01 8:40 ` Pietro 2016-09-01 9:02 ` Maciej Borzęcki 0 siblings, 1 reply; 21+ messages in thread From: Pietro @ 2016-09-01 8:40 UTC (permalink / raw) To: yocto Maciej Borzęcki <maciej.borzecki@rndity.com> writes: > On Wed, Aug 31, 2016 at 6:44 PM, Pietro <pulsarpietro@posteo.net> wrote: >> Hi all, >> >> I am new to the Yocto building system and I could be talking nonsense. I >> used to work with buildroot time ago and I remember there is an area >> where compiled software/packages/tools previously built are "staged" and >> used when building other packages. >> >> Is there something like that available with Yocto ? Specifically I would >> like to add a package which uses the Google Protocol Buffer, I do not have >> administrator rights on the machine and I can't install the packages I >> need system wise. >> >> Is it possible to add recipes and use them at building time without >> including them in the image being generated ? >> >> A good example for that would be the protoc, the protocol buffer description >> file compiler. >> > > There is a recipe for protobuf in meta-oe (2.6.1). All you need to do, > is include meta-oe in your layers (bblayers.conf) and have > protobuf-native listed in DEPENDS inside your package recipe. > > The protoc compiler will be available in the PATH when package is > being built, so autotools checks like AC_CHECK_PROG/AC_PATH_PROG > should be able to find it. > > Cheers, > -- > Maciej Borzecki > RnDity Thanks a lot. I have added the DEPENDS line and it indeed downloads and build the some protobuf related stuff, where did you get the dependency name from ? I can't see the protobuf-native as a recipe in the meta-oe website : https://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/ I have just realised that GRPC (http://www.grpc.io/) is needed for my project, it is a library which uses the protobuffers, is there a recipe/package which provides them around or do I need to create my own recipe ? I would like to check the root filesystem being generated as part of the build process, where is it ? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 8:40 ` Pietro @ 2016-09-01 9:02 ` Maciej Borzęcki 2016-09-01 9:34 ` Pietro 0 siblings, 1 reply; 21+ messages in thread From: Maciej Borzęcki @ 2016-09-01 9:02 UTC (permalink / raw) To: Pietro; +Cc: yocto On Thu, Sep 1, 2016 at 10:40 AM, Pietro <pulsarpietro@posteo.net> wrote: > Maciej Borzęcki > <maciej.borzecki@rndity.com> writes: > >> On Wed, Aug 31, 2016 at 6:44 PM, Pietro <pulsarpietro@posteo.net> wrote: >>> Hi all, >>> >>> I am new to the Yocto building system and I could be talking nonsense. I >>> used to work with buildroot time ago and I remember there is an area >>> where compiled software/packages/tools previously built are "staged" and >>> used when building other packages. >>> >>> Is there something like that available with Yocto ? Specifically I would >>> like to add a package which uses the Google Protocol Buffer, I do not have >>> administrator rights on the machine and I can't install the packages I >>> need system wise. >>> >>> Is it possible to add recipes and use them at building time without >>> including them in the image being generated ? >>> >>> A good example for that would be the protoc, the protocol buffer description >>> file compiler. >>> >> >> There is a recipe for protobuf in meta-oe (2.6.1). All you need to do, >> is include meta-oe in your layers (bblayers.conf) and have >> protobuf-native listed in DEPENDS inside your package recipe. >> >> The protoc compiler will be available in the PATH when package is >> being built, so autotools checks like AC_CHECK_PROG/AC_PATH_PROG >> should be able to find it. >> >> Cheers, >> -- >> Maciej Borzecki >> RnDity > Thanks a lot. > > I have added the DEPENDS line and it indeed downloads and build the some > protobuf related stuff, where did you get the dependency name from ? > I can't see the protobuf-native as a recipe in the meta-oe website : > > https://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/ It's just a mechanism that allows for building the native (i.e. for the host) packages, and these are autmatically named ${PN}-native. There should a BBCLASSEXTEND = "..native.." stanza inside the protobuf recipe that enables this feature. > > I have just realised that GRPC (http://www.grpc.io/) is needed for my > project, it is a library which uses the protobuffers, is there a > recipe/package which provides them around or do I need to create my own > recipe ? You can try searching for a recipe at http://layers.openembedded.org If there's none, try to write your own. This might be a good changes to get yourself acquainted with `devtool` tool that will help you in the process. > > I would like to check the root filesystem being generated as part of the > build process, where is it ? > ${TMPDIR}/<machine>_<distro?>/<imagename>/../rootfs for instance, for my current build: tmp/work/vexpress_qemu-poky-linux-gnueabi/core-image-minimal/1.0-r0/rootfs -- Maciej Borzecki RnDity ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 9:02 ` Maciej Borzęcki @ 2016-09-01 9:34 ` Pietro 2016-09-01 10:21 ` Herman van Hazendonk 2016-09-01 10:43 ` Jussi Kukkonen 0 siblings, 2 replies; 21+ messages in thread From: Pietro @ 2016-09-01 9:34 UTC (permalink / raw) To: yocto Maciej Borzęcki <maciej.borzecki@rndity.com> writes: > On Thu, Sep 1, 2016 at 10:40 AM, Pietro <pulsarpietro@posteo.net> wrote: >> Maciej Borzęcki >> <maciej.borzecki@rndity.com> writes: >> >>> On Wed, Aug 31, 2016 at 6:44 PM, Pietro <pulsarpietro@posteo.net> wrote: >>>> Hi all, >>>> >>>> I am new to the Yocto building system and I could be talking nonsense. I >>>> used to work with buildroot time ago and I remember there is an area >>>> where compiled software/packages/tools previously built are "staged" and >>>> used when building other packages. >>>> >>>> Is there something like that available with Yocto ? Specifically I would >>>> like to add a package which uses the Google Protocol Buffer, I do not have >>>> administrator rights on the machine and I can't install the packages I >>>> need system wise. >>>> >>>> Is it possible to add recipes and use them at building time without >>>> including them in the image being generated ? >>>> >>>> A good example for that would be the protoc, the protocol buffer description >>>> file compiler. >>>> >>> >>> There is a recipe for protobuf in meta-oe (2.6.1). All you need to do, >>> is include meta-oe in your layers (bblayers.conf) and have >>> protobuf-native listed in DEPENDS inside your package recipe. >>> >>> The protoc compiler will be available in the PATH when package is >>> being built, so autotools checks like AC_CHECK_PROG/AC_PATH_PROG >>> should be able to find it. >>> >>> Cheers, >>> -- >>> Maciej Borzecki >>> RnDity >> Thanks a lot. >> >> I have added the DEPENDS line and it indeed downloads and build the some >> protobuf related stuff, where did you get the dependency name from ? >> I can't see the protobuf-native as a recipe in the meta-oe website : >> >> https://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/ > > It's just a mechanism that allows for building the native (i.e. for > the host) packages, and these are autmatically named ${PN}-native. > There should a BBCLASSEXTEND = "..native.." stanza inside the protobuf > recipe that enables this feature. > >> >> I have just realised that GRPC (http://www.grpc.io/) is needed for my >> project, it is a library which uses the protobuffers, is there a >> recipe/package which provides them around or do I need to create my own >> recipe ? > > You can try searching for a recipe at http://layers.openembedded.org > If there's none, try to write your own. This might be a good changes > to get yourself acquainted with `devtool` tool that will help you in > the process. > >> >> I would like to check the root filesystem being generated as part of the >> build process, where is it ? >> > > ${TMPDIR}/<machine>_<distro?>/<imagename>/../rootfs > > for instance, for my current build: > > tmp/work/vexpress_qemu-poky-linux-gnueabi/core-image-minimal/1.0-r0/rootfs > > -- > Maciej Borzecki > RnDity Thanks, much appreciated. Do you know where the software which is not included in the image - such us protoc - is it stored ? It turns out the recipe for the protobuffer uses version 2.6 while I would need version 3.0.0 to be used, is there a way to partially "override" a recipe ? http://cgit.openembedded.org/cgit.cgi/meta-openembedded/tree/meta-oe/recipes-devtools/protobuf/protobuf_2.6.1.bb?h=master Thanks a lot. P. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 9:34 ` Pietro @ 2016-09-01 10:21 ` Herman van Hazendonk 2016-09-01 10:34 ` Jussi Kukkonen 2016-09-01 10:43 ` Jussi Kukkonen 1 sibling, 1 reply; 21+ messages in thread From: Herman van Hazendonk @ 2016-09-01 10:21 UTC (permalink / raw) To: Pietro; +Cc: yocto Hi Pietro, You can override the recipe by adding a recipe for version 3.0.0+ in your own layer and making sure your layer has a higher priority in bblayers.conf. See for example what we do in our project: https://github.com/webOS-ports/webos-ports-setup/blob/testing/conf/bblayers.conf openembedded-core provides ofono 1.1.7 for example with https://github.com/openembedded/openembedded-core/tree/krogoth/meta/recipes-connectivity/ofono However we want to use ANOTHER version of ofono (1.1.7 based, but from a different repo/project). So we have our own .bbappend at https://github.com/webOS-ports/meta-webos-ports/blob/krogoth/meta-luneos/recipes-connectivity/ofono/ofono_git.bbappend where we specify the different repo etc to use. This doesn't apply 1:1 in your case, but you could simply add a protobuf_3.0.0.bb in your own layer and it should build that instead. Just make sure you have your layer at a higher position compared to meta-openembedded in your bblayers.conf Herrie On 2016-09-01 11:34, Pietro wrote: > Maciej Borzęcki > <maciej.borzecki@rndity.com> writes: > >> On Thu, Sep 1, 2016 at 10:40 AM, Pietro <pulsarpietro@posteo.net> >> wrote: >>> Maciej Borzęcki >>> <maciej.borzecki@rndity.com> writes: >>> >>>> On Wed, Aug 31, 2016 at 6:44 PM, Pietro <pulsarpietro@posteo.net> >>>> wrote: >>>>> Hi all, >>>>> >>>>> I am new to the Yocto building system and I could be talking >>>>> nonsense. I >>>>> used to work with buildroot time ago and I remember there is an >>>>> area >>>>> where compiled software/packages/tools previously built are >>>>> "staged" and >>>>> used when building other packages. >>>>> >>>>> Is there something like that available with Yocto ? Specifically I >>>>> would >>>>> like to add a package which uses the Google Protocol Buffer, I do >>>>> not have >>>>> administrator rights on the machine and I can't install the >>>>> packages I >>>>> need system wise. >>>>> >>>>> Is it possible to add recipes and use them at building time without >>>>> including them in the image being generated ? >>>>> >>>>> A good example for that would be the protoc, the protocol buffer >>>>> description >>>>> file compiler. >>>>> >>>> >>>> There is a recipe for protobuf in meta-oe (2.6.1). All you need to >>>> do, >>>> is include meta-oe in your layers (bblayers.conf) and have >>>> protobuf-native listed in DEPENDS inside your package recipe. >>>> >>>> The protoc compiler will be available in the PATH when package is >>>> being built, so autotools checks like AC_CHECK_PROG/AC_PATH_PROG >>>> should be able to find it. >>>> >>>> Cheers, >>>> -- >>>> Maciej Borzecki >>>> RnDity >>> Thanks a lot. >>> >>> I have added the DEPENDS line and it indeed downloads and build the >>> some >>> protobuf related stuff, where did you get the dependency name from ? >>> I can't see the protobuf-native as a recipe in the meta-oe website : >>> >>> https://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/ >> >> It's just a mechanism that allows for building the native (i.e. for >> the host) packages, and these are autmatically named ${PN}-native. >> There should a BBCLASSEXTEND = "..native.." stanza inside the protobuf >> recipe that enables this feature. >> >>> >>> I have just realised that GRPC (http://www.grpc.io/) is needed for my >>> project, it is a library which uses the protobuffers, is there a >>> recipe/package which provides them around or do I need to create my >>> own >>> recipe ? >> >> You can try searching for a recipe at http://layers.openembedded.org >> If there's none, try to write your own. This might be a good changes >> to get yourself acquainted with `devtool` tool that will help you in >> the process. >> >>> >>> I would like to check the root filesystem being generated as part of >>> the >>> build process, where is it ? >>> >> >> ${TMPDIR}/<machine>_<distro?>/<imagename>/../rootfs >> >> for instance, for my current build: >> >> tmp/work/vexpress_qemu-poky-linux-gnueabi/core-image-minimal/1.0-r0/rootfs >> >> -- >> Maciej Borzecki >> RnDity > > Thanks, much appreciated. > > Do you know where the software which is not included in the image - > such > us protoc - is it stored ? > > It turns out the recipe for the protobuffer uses version 2.6 while I > would need version 3.0.0 to be used, is there a way to partially > "override" a recipe ? > > http://cgit.openembedded.org/cgit.cgi/meta-openembedded/tree/meta-oe/recipes-devtools/protobuf/protobuf_2.6.1.bb?h=master > > Thanks a lot. > P. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 10:21 ` Herman van Hazendonk @ 2016-09-01 10:34 ` Jussi Kukkonen 2016-09-01 10:57 ` Samuel Stirtzel 2016-09-01 13:10 ` Pietro 0 siblings, 2 replies; 21+ messages in thread From: Jussi Kukkonen @ 2016-09-01 10:34 UTC (permalink / raw) To: yoctoproject.org; +Cc: Yocto Project, Pietro [-- Attachment #1: Type: text/plain, Size: 1344 bytes --] On 1 September 2016 at 13:21, Herman van Hazendonk <me@herrie.org> wrote: > Hi Pietro, > > You can override the recipe by adding a recipe for version 3.0.0+ in your > own layer and making sure your layer has a higher priority in > bblayers.conf. See for example what we do in our project: > > https://github.com/webOS-ports/webos-ports-setup/blob/testin > g/conf/bblayers.conf > > openembedded-core provides ofono 1.1.7 for example with > https://github.com/openembedded/openembedded-core/tree/ > krogoth/meta/recipes-connectivity/ofono > > However we want to use ANOTHER version of ofono (1.1.7 based, but from a > different repo/project). > > So we have our own .bbappend at https://github.com/webOS-ports > /meta-webos-ports/blob/krogoth/meta-luneos/recipes-connectiv > ity/ofono/ofono_git.bbappend where we specify the different repo etc to > use. > > This doesn't apply 1:1 in your case, but you could simply add a > protobuf_3.0.0.bb in your own layer and it should build that instead. > Just make sure you have your layer at a higher position compared to > meta-openembedded in your bblayers.conf > In the normal case (a simple upgrade to the newest version) the best choice would be to send a upgrade patch to openembedded-devel list: that way you never have to maintain it in your own layer. Jussi [-- Attachment #2: Type: text/html, Size: 2278 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 10:34 ` Jussi Kukkonen @ 2016-09-01 10:57 ` Samuel Stirtzel 2016-09-06 18:11 ` Khem Raj 2016-09-01 13:10 ` Pietro 1 sibling, 1 reply; 21+ messages in thread From: Samuel Stirtzel @ 2016-09-01 10:57 UTC (permalink / raw) To: Jussi Kukkonen; +Cc: Yocto Project, Pietro 2016-09-01 12:34 GMT+02:00 Jussi Kukkonen <jussi.kukkonen@intel.com>: > On 1 September 2016 at 13:21, Herman van Hazendonk <me@herrie.org> wrote: >> >> Hi Pietro, >> >> You can override the recipe by adding a recipe for version 3.0.0+ in your >> own layer and making sure your layer has a higher priority in bblayers.conf. >> See for example what we do in our project: >> >> >> https://github.com/webOS-ports/webos-ports-setup/blob/testing/conf/bblayers.conf >> >> openembedded-core provides ofono 1.1.7 for example with >> https://github.com/openembedded/openembedded-core/tree/krogoth/meta/recipes-connectivity/ofono >> >> However we want to use ANOTHER version of ofono (1.1.7 based, but from a >> different repo/project). >> >> So we have our own .bbappend at >> https://github.com/webOS-ports/meta-webos-ports/blob/krogoth/meta-luneos/recipes-connectivity/ofono/ofono_git.bbappend >> where we specify the different repo etc to use. >> >> This doesn't apply 1:1 in your case, but you could simply add a >> protobuf_3.0.0.bb in your own layer and it should build that instead. Just >> make sure you have your layer at a higher position compared to >> meta-openembedded in your bblayers.conf > > > In the normal case (a simple upgrade to the newest version) the best choice > would be to send a upgrade patch to openembedded-devel list: that way you > never have to maintain it in your own layer. > Hi, protobuf 2.x and 3.x are incompatible, there is also a protobuf3 recipe in meta-maker. -- Regards Samuel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 10:57 ` Samuel Stirtzel @ 2016-09-06 18:11 ` Khem Raj 2016-09-08 12:42 ` Samuel Stirtzel 0 siblings, 1 reply; 21+ messages in thread From: Khem Raj @ 2016-09-06 18:11 UTC (permalink / raw) To: Samuel Stirtzel; +Cc: Pietro, Yocto Project [-- Attachment #1: Type: text/plain, Size: 1914 bytes --] > On Sep 1, 2016, at 3:57 AM, Samuel Stirtzel <s.stirtzel@googlemail.com> wrote: > > 2016-09-01 12:34 GMT+02:00 Jussi Kukkonen <jussi.kukkonen@intel.com>: >> On 1 September 2016 at 13:21, Herman van Hazendonk <me@herrie.org> wrote: >>> >>> Hi Pietro, >>> >>> You can override the recipe by adding a recipe for version 3.0.0+ in your >>> own layer and making sure your layer has a higher priority in bblayers.conf. >>> See for example what we do in our project: >>> >>> >>> https://github.com/webOS-ports/webos-ports-setup/blob/testing/conf/bblayers.conf >>> >>> openembedded-core provides ofono 1.1.7 for example with >>> https://github.com/openembedded/openembedded-core/tree/krogoth/meta/recipes-connectivity/ofono >>> >>> However we want to use ANOTHER version of ofono (1.1.7 based, but from a >>> different repo/project). >>> >>> So we have our own .bbappend at >>> https://github.com/webOS-ports/meta-webos-ports/blob/krogoth/meta-luneos/recipes-connectivity/ofono/ofono_git.bbappend >>> where we specify the different repo etc to use. >>> >>> This doesn't apply 1:1 in your case, but you could simply add a >>> protobuf_3.0.0.bb in your own layer and it should build that instead. Just >>> make sure you have your layer at a higher position compared to >>> meta-openembedded in your bblayers.conf >> >> >> In the normal case (a simple upgrade to the newest version) the best choice >> would be to send a upgrade patch to openembedded-devel list: that way you >> never have to maintain it in your own layer. >> > > Hi, > > protobuf 2.x and 3.x are incompatible, there is also a protobuf3 > recipe in meta-maker. > why is it in meta-maker and not in meta-oe ? > > -- > Regards > Samuel > -- > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 211 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-06 18:11 ` Khem Raj @ 2016-09-08 12:42 ` Samuel Stirtzel 0 siblings, 0 replies; 21+ messages in thread From: Samuel Stirtzel @ 2016-09-08 12:42 UTC (permalink / raw) To: Khem Raj; +Cc: Yocto Project 2016-09-06 20:11 GMT+02:00 Khem Raj <raj.khem@gmail.com>: > >> On Sep 1, 2016, at 3:57 AM, Samuel Stirtzel <s.stirtzel@googlemail.com> wrote: >> >> Hi, >> >> protobuf 2.x and 3.x are incompatible, there is also a protobuf3 >> recipe in meta-maker. >> > > why is it in meta-maker and not in meta-oe ? > No idea, it would be easier to ask the author (Koen). -- Regards Samuel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 10:34 ` Jussi Kukkonen 2016-09-01 10:57 ` Samuel Stirtzel @ 2016-09-01 13:10 ` Pietro 2016-09-01 13:40 ` Pietro 1 sibling, 1 reply; 21+ messages in thread From: Pietro @ 2016-09-01 13:10 UTC (permalink / raw) To: yocto Jussi Kukkonen <jussi.kukkonen@intel.com> writes: > On 1 September 2016 at 13:21, Herman van Hazendonk > <me@herrie.org> wrote: > > Hi Pietro, > > You can override the recipe by adding a recipe for version 3.0.0+ > in your own layer and making sure your layer has a higher priority > in bblayers.conf. See for example what we do in our project: > > https://github.com/webOS-ports/webos-ports-setup/blob/testing/conf/bblayers.conf > > > openembedded-core provides ofono 1.1.7 for example with > https://github.com/openembedded/openembedded-core/tree/krogoth/meta/recipes- > connectivity/ofono > > However we want to use ANOTHER version of ofono (1.1.7 based, but > from a different repo/project). > > So we have our own .bbappend at > https://github.com/webOS-ports/meta-webos-ports/blob/krogoth/meta-luneos/recipes-connectiv > ity/ofono/ofono_git.bbappend where we specify the different repo > etc to use. > > This doesn't apply 1:1 in your case, but you could simply add a > protobuf_3.0.0.bb in your own layer and it should build that > instead. Just make sure you have your layer at a higher position > compared to meta-openembedded in your bblayers.conf Thanks a lot. I have written my own repice and added it into my own layer, it does not compile though : | | autoreconf: configure.ac: tracing | | autoreconf: configure.ac: subdirectory gmock not present | autoreconf: configure.ac: not using Libtool | autoreconf: running: | /export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/autoconf | --include=/export/arm/pietro/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/proto buf/3.0.0-r0/git/m4/ --force | | configure.ac:93: error: possibly undefined macro: AC_PROG_LIBTOOL | | If this token and others are legitimate, please use | m4_pattern_allow. | See the Autoconf documentation. | | autoreconf: | /export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/autoconf | failed with exit status: 1 | | + bbfatal autoreconf execution failed. I understand this is a completely different matter now, but has anybody else seen this before ? I have tried to compile the same revision on my local machine "natively" and it's built fine. That library should be a dependency for another package/recipe I am working on, is it allowed to specify a version inside the DEPENDS recipe's clause ? I have tried to google the problem but I haven't found a working example as yet. Cheers, P. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 13:10 ` Pietro @ 2016-09-01 13:40 ` Pietro 2016-09-01 13:44 ` Herman van Hazendonk 0 siblings, 1 reply; 21+ messages in thread From: Pietro @ 2016-09-01 13:40 UTC (permalink / raw) To: yocto Pietro <pulsarpietro@posteo.net> writes: > Jussi Kukkonen <jussi.kukkonen@intel.com> > writes: > >> On 1 September 2016 at 13:21, Herman van Hazendonk >> <me@herrie.org> wrote: >> >> Hi Pietro, >> >> You can override the recipe by adding a recipe for version 3.0.0+ >> in your own layer and making sure your layer has a higher priority >> in bblayers.conf. See for example what we do in our project: >> >> https://github.com/webOS-ports/webos-ports-setup/blob/testing/conf/bblayers.conf >> >> >> openembedded-core provides ofono 1.1.7 for example with >> https://github.com/openembedded/openembedded-core/tree/krogoth/meta/recipes- >> connectivity/ofono >> >> However we want to use ANOTHER version of ofono (1.1.7 based, but >> from a different repo/project). >> >> So we have our own .bbappend at >> https://github.com/webOS-ports/meta-webos-ports/blob/krogoth/meta-luneos/recipes-connectiv >> ity/ofono/ofono_git.bbappend where we specify the different repo >> etc to use. >> >> This doesn't apply 1:1 in your case, but you could simply add a >> protobuf_3.0.0.bb in your own layer and it should build that >> instead. Just make sure you have your layer at a higher position >> compared to meta-openembedded in your bblayers.conf > > Thanks a lot. > I have written my own repice and added it into my own layer, it > does not compile though : > > | > | autoreconf: configure.ac: tracing > | > | autoreconf: configure.ac: subdirectory gmock not present > | autoreconf: configure.ac: not using Libtool > | autoreconf: running: > | /export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/autoconf > | --include=/export/arm/pietro/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/proto > buf/3.0.0-r0/git/m4/ --force > | > | configure.ac:93: error: possibly undefined macro: AC_PROG_LIBTOOL > | > | If this token and others are legitimate, please use > | m4_pattern_allow. > | See the Autoconf documentation. > | > | autoreconf: > | /export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/autoconf > | failed with exit status: 1 > | > | + bbfatal autoreconf execution failed. > > I understand this is a completely different matter now, but has > anybody else seen this before ? I have tried to compile the same > revision on my local machine "natively" and it's built fine. > > That library should be a dependency for another package/recipe I am > working on, is it allowed to specify a version inside the DEPENDS > recipe's clause ? I have tried to google the problem but I haven't found > a working example as yet. > > Cheers, > P. Forget about it, I was pointing to a broken commit it. My recipe name is protobuf_3.0.0.bb, how do I make it a dependency of another package ? I have tried many solution but none of them is working : DEPENDS = "protobuf > 3.0.0" ... "protobuf_3.0.0" ... etc etc Any thoughts ? P. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 13:40 ` Pietro @ 2016-09-01 13:44 ` Herman van Hazendonk 2016-09-01 14:34 ` Pietro 0 siblings, 1 reply; 21+ messages in thread From: Herman van Hazendonk @ 2016-09-01 13:44 UTC (permalink / raw) To: Pietro; +Cc: yocto Hi Pietro, You shouldn't need to specify a version. DEPENDS = "protobuf" or DEPENDS = "protobuf-native" should do :) Herrie On 2016-09-01 15:40, Pietro wrote: > Pietro <pulsarpietro@posteo.net> writes: > >> Jussi Kukkonen <jussi.kukkonen@intel.com> >> writes: >> >>> On 1 September 2016 at 13:21, Herman van Hazendonk >>> <me@herrie.org> wrote: >>> >>> Hi Pietro, >>> >>> You can override the recipe by adding a recipe for version 3.0.0+ >>> in your own layer and making sure your layer has a higher >>> priority >>> in bblayers.conf. See for example what we do in our project: >>> >>> >>> https://github.com/webOS-ports/webos-ports-setup/blob/testing/conf/bblayers.conf >>> >>> >>> openembedded-core provides ofono 1.1.7 for example with >>> >>> https://github.com/openembedded/openembedded-core/tree/krogoth/meta/recipes- >>> connectivity/ofono >>> >>> However we want to use ANOTHER version of ofono (1.1.7 based, but >>> from a different repo/project). >>> >>> So we have our own .bbappend at >>> >>> https://github.com/webOS-ports/meta-webos-ports/blob/krogoth/meta-luneos/recipes-connectiv >>> ity/ofono/ofono_git.bbappend where we specify the different repo >>> etc to use. >>> >>> This doesn't apply 1:1 in your case, but you could simply add a >>> protobuf_3.0.0.bb in your own layer and it should build that >>> instead. Just make sure you have your layer at a higher position >>> compared to meta-openembedded in your bblayers.conf >> >> Thanks a lot. >> I have written my own repice and added it into my own layer, it >> does not compile though : >> >> | >> | autoreconf: configure.ac: tracing >> | >> | autoreconf: configure.ac: subdirectory gmock not present >> | autoreconf: configure.ac: not using Libtool >> | autoreconf: running: >> | >> /export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/autoconf >> | >> --include=/export/arm/pietro/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/proto >> buf/3.0.0-r0/git/m4/ --force >> | >> | configure.ac:93: error: possibly undefined macro: AC_PROG_LIBTOOL >> | >> | If this token and others are legitimate, please use >> | m4_pattern_allow. >> | See the Autoconf documentation. >> | >> | autoreconf: >> | >> /export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/autoconf >> | failed with exit status: 1 >> | >> | + bbfatal autoreconf execution failed. >> >> I understand this is a completely different matter now, but has >> anybody else seen this before ? I have tried to compile the same >> revision on my local machine "natively" and it's built fine. >> >> That library should be a dependency for another package/recipe I am >> working on, is it allowed to specify a version inside the DEPENDS >> recipe's clause ? I have tried to google the problem but I haven't >> found >> a working example as yet. >> >> Cheers, >> P. > Forget about it, I was pointing to a broken commit it. > My recipe name is protobuf_3.0.0.bb, how do I make it a dependency of > another package ? > > I have tried many solution but none of them is working : > DEPENDS = "protobuf > 3.0.0" ... "protobuf_3.0.0" ... etc etc > > Any thoughts ? > > P. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 13:44 ` Herman van Hazendonk @ 2016-09-01 14:34 ` Pietro 2016-09-01 14:40 ` Herman van Hazendonk 0 siblings, 1 reply; 21+ messages in thread From: Pietro @ 2016-09-01 14:34 UTC (permalink / raw) To: yocto Herman van Hazendonk <me@herrie.org> writes: > Hi Pietro, > > You shouldn't need to specify a version. DEPENDS = "protobuf" or > DEPENDS = "protobuf-native" should do :) > > Herrie > > > Indeed my recipe gets built first and I can see do_protobuf_3.0.0[..](), nonetheless when my package, which depends on libprotobuf compiles it fails since it does not find the right version of the library. It still finds the older version You don't have protoc 3.0.0 installed in your path. | Please install Google protocol buffers 3.0.0 and its compiler. | You can find it here: | | https://github.com/google/protobuf/releases/tag/v3.0.0 | | Here is what I get when trying to evaluate your version of protoc: | | protoc --version | libprotoc 2.4.1 | make: [system-check] Error 1 (ignored) | The version should be 3.0.0. What am I doing wrong ? > On 2016-09-01 15:40, Pietro wrote: >> Pietro <pulsarpietro@posteo.net> writes: >> >>> Jussi Kukkonen <jussi.kukkonen@intel.com> >>> writes: >>> >>>> On 1 September 2016 at 13:21, Herman van Hazendonk >>>> <me@herrie.org> wrote: >>>> >>>> Hi Pietro, >>>> >>>> You can override the recipe by adding a recipe for version 3.0.0+ >>>> in your own layer and making sure your layer has a higher >>>> priority >>>> in bblayers.conf. See for example what we do in our project: >>>> >>>> https://github.com/webOS-ports/webos-ports-setup/blob/testing/conf/bblayers.conf >>>> >>>> >>>> openembedded-core provides ofono 1.1.7 for example with >>>> https://github.com/openembedded/openembedded-core/tree/krogoth/meta/recipes- >>>> connectivity/ofono >>>> >>>> However we want to use ANOTHER version of ofono (1.1.7 based, but >>>> from a different repo/project). >>>> >>>> So we have our own .bbappend at >>>> https://github.com/webOS-ports/meta-webos-ports/blob/krogoth/meta-luneos/recipes-connectiv >>>> ity/ofono/ofono_git.bbappend where we specify the different repo >>>> etc to use. >>>> >>>> This doesn't apply 1:1 in your case, but you could simply add a >>>> protobuf_3.0.0.bb in your own layer and it should build that >>>> instead. Just make sure you have your layer at a higher position >>>> compared to meta-openembedded in your bblayers.conf >>> >>> Thanks a lot. >>> I have written my own repice and added it into my own layer, it >>> does not compile though : >>> >>> | >>> | autoreconf: configure.ac: tracing >>> | >>> | autoreconf: configure.ac: subdirectory gmock not present >>> | autoreconf: configure.ac: not using Libtool >>> | autoreconf: running: >>> | >>> /export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/autoconf >>> | >>> --include=/export/arm/pietro/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/proto >>> buf/3.0.0-r0/git/m4/ --force >>> | >>> | configure.ac:93: error: possibly undefined macro: AC_PROG_LIBTOOL >>> | >>> | If this token and others are legitimate, please use >>> | m4_pattern_allow. >>> | See the Autoconf documentation. >>> | >>> | autoreconf: >>> | >>> /export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/autoconf >>> | failed with exit status: 1 >>> | >>> | + bbfatal autoreconf execution failed. >>> >>> I understand this is a completely different matter now, but has >>> anybody else seen this before ? I have tried to compile the same >>> revision on my local machine "natively" and it's built fine. >>> >>> That library should be a dependency for another package/recipe I am >>> working on, is it allowed to specify a version inside the DEPENDS >>> recipe's clause ? I have tried to google the problem but I haven't >>> found >>> a working example as yet. >>> >>> Cheers, >>> P. >> Forget about it, I was pointing to a broken commit it. >> My recipe name is protobuf_3.0.0.bb, how do I make it a dependency of >> another package ? >> >> I have tried many solution but none of them is working : >> DEPENDS = "protobuf > 3.0.0" ... "protobuf_3.0.0" ... etc etc >> >> Any thoughts ? >> >> P. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 14:34 ` Pietro @ 2016-09-01 14:40 ` Herman van Hazendonk 2016-09-01 15:45 ` Pietro 0 siblings, 1 reply; 21+ messages in thread From: Herman van Hazendonk @ 2016-09-01 14:40 UTC (permalink / raw) To: Pietro; +Cc: yocto If it takes the wrong version, it could be your layers aren't in the right order. That's the first thing to check. You might want to try to run bitbake with -f protobuf -c cleanall or -f protobuf-native -c cleanall This will remove all locally ;) Then rebuild it... I haven't played much with the -native bits, so not sure how those work. On 2016-09-01 16:34, Pietro wrote: > Herman van Hazendonk <me@herrie.org> > writes: > >> Hi Pietro, >> >> You shouldn't need to specify a version. DEPENDS = "protobuf" or >> DEPENDS = "protobuf-native" should do :) >> >> Herrie >> >> >> > > Indeed my recipe gets built first and I can see > do_protobuf_3.0.0[..](), > nonetheless when my package, which depends on libprotobuf compiles it > fails since it does not find the right version of the library. > > It still finds the older version > > You don't have protoc 3.0.0 installed in your path. > | Please install Google protocol buffers 3.0.0 and its compiler. > | You can find it here: > | > | https://github.com/google/protobuf/releases/tag/v3.0.0 > | > | Here is what I get when trying to evaluate your version of protoc: > | > | protoc --version > | libprotoc 2.4.1 > | make: [system-check] Error 1 (ignored) > | > > The version should be 3.0.0. What am I doing wrong ? > > > > > >> On 2016-09-01 15:40, Pietro wrote: >>> Pietro <pulsarpietro@posteo.net> writes: >>> >>>> Jussi Kukkonen <jussi.kukkonen@intel.com> >>>> writes: >>>> >>>>> On 1 September 2016 at 13:21, Herman van Hazendonk >>>>> <me@herrie.org> wrote: >>>>> >>>>> Hi Pietro, >>>>> >>>>> You can override the recipe by adding a recipe for version >>>>> 3.0.0+ >>>>> in your own layer and making sure your layer has a higher >>>>> priority >>>>> in bblayers.conf. See for example what we do in our project: >>>>> >>>>> >>>>> https://github.com/webOS-ports/webos-ports-setup/blob/testing/conf/bblayers.conf >>>>> >>>>> >>>>> openembedded-core provides ofono 1.1.7 for example with >>>>> >>>>> https://github.com/openembedded/openembedded-core/tree/krogoth/meta/recipes- >>>>> connectivity/ofono >>>>> >>>>> However we want to use ANOTHER version of ofono (1.1.7 based, >>>>> but >>>>> from a different repo/project). >>>>> >>>>> So we have our own .bbappend at >>>>> >>>>> https://github.com/webOS-ports/meta-webos-ports/blob/krogoth/meta-luneos/recipes-connectiv >>>>> ity/ofono/ofono_git.bbappend where we specify the different repo >>>>> etc to use. >>>>> >>>>> This doesn't apply 1:1 in your case, but you could simply add a >>>>> protobuf_3.0.0.bb in your own layer and it should build that >>>>> instead. Just make sure you have your layer at a higher >>>>> position >>>>> compared to meta-openembedded in your bblayers.conf >>>> >>>> Thanks a lot. >>>> I have written my own repice and added it into my own layer, it >>>> does not compile though : >>>> >>>> | >>>> | autoreconf: configure.ac: tracing >>>> | >>>> | autoreconf: configure.ac: subdirectory gmock not present >>>> | autoreconf: configure.ac: not using Libtool >>>> | autoreconf: running: >>>> | >>>> /export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/autoconf >>>> | >>>> --include=/export/arm/pietro/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/proto >>>> buf/3.0.0-r0/git/m4/ --force >>>> | >>>> | configure.ac:93: error: possibly undefined macro: AC_PROG_LIBTOOL >>>> | >>>> | If this token and others are legitimate, please use >>>> | m4_pattern_allow. >>>> | See the Autoconf documentation. >>>> | >>>> | autoreconf: >>>> | >>>> /export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/autoconf >>>> | failed with exit status: 1 >>>> | >>>> | + bbfatal autoreconf execution failed. >>>> >>>> I understand this is a completely different matter now, but has >>>> anybody else seen this before ? I have tried to compile the same >>>> revision on my local machine "natively" and it's built fine. >>>> >>>> That library should be a dependency for another package/recipe I am >>>> working on, is it allowed to specify a version inside the DEPENDS >>>> recipe's clause ? I have tried to google the problem but I haven't >>>> found >>>> a working example as yet. >>>> >>>> Cheers, >>>> P. >>> Forget about it, I was pointing to a broken commit it. >>> My recipe name is protobuf_3.0.0.bb, how do I make it a dependency of >>> another package ? >>> >>> I have tried many solution but none of them is working : >>> DEPENDS = "protobuf > 3.0.0" ... "protobuf_3.0.0" ... etc etc >>> >>> Any thoughts ? >>> >>> P. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 14:40 ` Herman van Hazendonk @ 2016-09-01 15:45 ` Pietro 2016-09-01 15:56 ` Maciej Borzęcki 0 siblings, 1 reply; 21+ messages in thread From: Pietro @ 2016-09-01 15:45 UTC (permalink / raw) To: yocto Herman van Hazendonk <me@herrie.org> writes: > If it takes the wrong version, it could be your layers aren't in the > right order. That's the first thing to check. > > You might want to try to run bitbake with > > -f protobuf -c cleanall or -f protobuf-native -c cleanall > > This will remove all locally ;) > > Then rebuild it... I haven't played much with the -native bits, so not > sure how those work. > I needed to specify DEPENDS = "protobuf-native" to get it working, I would be really interested to understand exactly what that does, but I must admit to myself I can't understand everything in a single shot. So never mind. I still have another question :-) I am about to create another recipe for the gprc library for C++, to build it on my local machine has been pretty simple: $ git clone -b $(curl -L http://grpc.io/release) https://github.com/grpc/grpc $ cd grpc $ git submodule update --init $ make $ [sudo] make install The recipe I have created so far would clone/checkout the source code from a GIT repo or something similar and then the build process could start straight away. In my case I have an additional step: git submodule update --init Is there a function/hook I can override in the recipe ? Thanks, P. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 15:45 ` Pietro @ 2016-09-01 15:56 ` Maciej Borzęcki 2016-09-02 8:08 ` Pietro 2016-09-02 9:44 ` Pietro 0 siblings, 2 replies; 21+ messages in thread From: Maciej Borzęcki @ 2016-09-01 15:56 UTC (permalink / raw) To: Pietro; +Cc: yocto On Thu, Sep 1, 2016 at 5:45 PM, Pietro <pulsarpietro@posteo.net> wrote: > Herman van Hazendonk <me@herrie.org> > writes: > >> If it takes the wrong version, it could be your layers aren't in the >> right order. That's the first thing to check. >> >> You might want to try to run bitbake with >> >> -f protobuf -c cleanall or -f protobuf-native -c cleanall >> >> This will remove all locally ;) >> >> Then rebuild it... I haven't played much with the -native bits, so not >> sure how those work. >> > I needed to specify DEPENDS = "protobuf-native" to get it working, I > would be really interested to understand exactly what that does, but I > must admit to myself I can't understand everything in a single shot. Quoting my first email: >> All you need to do, >>is include meta-oe in your layers (bblayers.conf) and have >> protobuf-native listed in DEPENDS inside your package recipe. DEPENDS lists build time dependencies, like libraries, tools etc. protobuf-native, by convention, means that the package was built for your build host. This enables you to run protoc during the build to generate proper language bindings. > > So never mind. > > I still have another question :-) > > I am about to create another recipe for the gprc library for C++, to > build it on my local machine has been pretty simple: > > $ git clone -b $(curl -L http://grpc.io/release) > https://github.com/grpc/grpc > $ cd grpc > $ git submodule update --init > $ make > $ [sudo] make install > > The recipe I have created so far would clone/checkout the source code > from a GIT repo or something similar and then the build process could > start straight away. > > In my case I have an additional step: > > git submodule update --init > There's a submodule fetcher, when setting SRC_URI use `gitsm://` instead of `git://` see https://www.yoctoproject.org/docs/2.1/bitbake-user-manual/bitbake-user-manual.html#gitsm-fetcher for details. Cheers, -- Maciej Borzecki RnDity ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 15:56 ` Maciej Borzęcki @ 2016-09-02 8:08 ` Pietro 2016-09-02 8:37 ` Maciej Borzęcki 2016-09-02 9:44 ` Pietro 1 sibling, 1 reply; 21+ messages in thread From: Pietro @ 2016-09-02 8:08 UTC (permalink / raw) To: yocto Maciej Borzęcki <maciej.borzecki@rndity.com> writes: > On Thu, Sep 1, 2016 at 5:45 PM, Pietro <pulsarpietro@posteo.net> wrote: >> Herman van Hazendonk <me@herrie.org> >> writes: >> >>> If it takes the wrong version, it could be your layers aren't in the >>> right order. That's the first thing to check. >>> >>> You might want to try to run bitbake with >>> >>> -f protobuf -c cleanall or -f protobuf-native -c cleanall >>> >>> This will remove all locally ;) >>> >>> Then rebuild it... I haven't played much with the -native bits, so not >>> sure how those work. >>> >> I needed to specify DEPENDS = "protobuf-native" to get it working, I >> would be really interested to understand exactly what that does, but I >> must admit to myself I can't understand everything in a single shot. > > Quoting my first email: >>> All you need to do, >>>is include meta-oe in your layers (bblayers.conf) and have >>> protobuf-native listed in DEPENDS inside your package recipe. > > DEPENDS lists build time dependencies, like libraries, tools etc. > protobuf-native, by convention, means that the package was built for > your build host. This enables you to run protoc during the build to > generate proper language bindings. > Where are all these "native" binaries stored ? Is it "sysroot" ? How can I declare run-time dependencies ? Such library should be cross-compiled in order to successfully link my package's binaries against it, on the other hand when building the "protoc" the target should be the host machine as such tool will be run on the host machine when required. I wonder if is the "native" keyword in the DEPENDS statement to draw the line, so in a recipe A: i) DEPENDS = "protobuf" tells that the recipe depends on the protobuf at run-time - namely during the linking and when the binary resulting from A is executed. So protobuf is cross-compiled. ii) DEPENDS = "protobuf-native" tells that the recipe depends on the prottobuf at build-time and a result of that protobuf is NOT cross compiled. >> >> So never mind. >> >> I still have another question :-) >> >> I am about to create another recipe for the gprc library for C++, to >> build it on my local machine has been pretty simple: >> >> $ git clone -b $(curl -L http://grpc.io/release) >> https://github.com/grpc/grpc >> $ cd grpc >> $ git submodule update --init >> $ make >> $ [sudo] make install >> >> The recipe I have created so far would clone/checkout the source code >> from a GIT repo or something similar and then the build process could >> start straight away. >> >> In my case I have an additional step: >> >> git submodule update --init >> > > There's a submodule fetcher, when setting SRC_URI use `gitsm://` > instead of `git://` see > https://www.yoctoproject.org/docs/2.1/bitbake-user-manual/bitbake-user-manual.html#gitsm-fetcher > for details. > > Cheers, > -- > Maciej Borzecki > RnDity Thanks, I'll give to it a go. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-02 8:08 ` Pietro @ 2016-09-02 8:37 ` Maciej Borzęcki 0 siblings, 0 replies; 21+ messages in thread From: Maciej Borzęcki @ 2016-09-02 8:37 UTC (permalink / raw) To: Pietro; +Cc: yocto On Fri, Sep 2, 2016 at 10:08 AM, Pietro <pulsarpietro@posteo.net> wrote: > Maciej Borzęcki > <maciej.borzecki@rndity.com> writes: > >> On Thu, Sep 1, 2016 at 5:45 PM, Pietro <pulsarpietro@posteo.net> wrote: >>> Herman van Hazendonk <me@herrie.org> >>> writes: >>> >>>> If it takes the wrong version, it could be your layers aren't in the >>>> right order. That's the first thing to check. >>>> >>>> You might want to try to run bitbake with >>>> >>>> -f protobuf -c cleanall or -f protobuf-native -c cleanall >>>> >>>> This will remove all locally ;) >>>> >>>> Then rebuild it... I haven't played much with the -native bits, so not >>>> sure how those work. >>>> >>> I needed to specify DEPENDS = "protobuf-native" to get it working, I >>> would be really interested to understand exactly what that does, but I >>> must admit to myself I can't understand everything in a single shot. >> >> Quoting my first email: >>>> All you need to do, >>>>is include meta-oe in your layers (bblayers.conf) and have >>>> protobuf-native listed in DEPENDS inside your package recipe. >> >> DEPENDS lists build time dependencies, like libraries, tools etc. >> protobuf-native, by convention, means that the package was built for >> your build host. This enables you to run protoc during the build to >> generate proper language bindings. >> > Where are all these "native" binaries stored ? Is it "sysroot" ? > > How can I declare run-time dependencies ? RDEPENDS, see https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-RDEPENDS Libraries should be taken care of automatically (at least for ELF binaries), so you will only need to list other services or packages that are needed during runtime. > > Such library should be cross-compiled in order to successfully > link my package's binaries against it, on the other hand when building > the "protoc" the target should be the host machine as such tool will be > run on the host machine when required. > > I wonder if is the "native" keyword in the DEPENDS statement to draw the > line, so in a recipe A: > > i) DEPENDS = "protobuf" > tells that the recipe depends on the protobuf at run-time - namely during > the linking and when the binary resulting from A is executed. > So protobuf is cross-compiled. So the protobuf recipe (meta-oe one) splits the package into 2 parts, protobuf (libraries that are used by generated bindings) and protobuf-compiler (one that generates bindings). The build system will figure out that your package RDEPENDS on protobuf (not protobuf-compiler). The other package, protobuf-compiler, is not really needed in your target filesystem, unless you want to generate bindings on the target (as in on your ARM board or similar). It is generally a good practice to spllt your packages so that the user does not have to pay the cost for things they don't need. > > ii) DEPENDS = "protobuf-native" > tells that the recipe depends on the prottobuf at build-time and a > result of that protobuf is NOT cross compiled. Yes. You need protoc to generate bindings at build time, hence you need a version of protobuf that can be run by your native host (hence -native). -- Maciej Borzecki RnDity ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 15:56 ` Maciej Borzęcki 2016-09-02 8:08 ` Pietro @ 2016-09-02 9:44 ` Pietro 1 sibling, 0 replies; 21+ messages in thread From: Pietro @ 2016-09-02 9:44 UTC (permalink / raw) To: yocto Maciej Borzęcki <maciej.borzecki@rndity.com> writes: > On Thu, Sep 1, 2016 at 5:45 PM, Pietro <pulsarpietro@posteo.net> wrote: >> Herman van Hazendonk <me@herrie.org> >> writes: >> >>> If it takes the wrong version, it could be your layers aren't in the >>> right order. That's the first thing to check. >>> >>> You might want to try to run bitbake with >>> >>> -f protobuf -c cleanall or -f protobuf-native -c cleanall >>> >>> This will remove all locally ;) >>> >>> Then rebuild it... I haven't played much with the -native bits, so not >>> sure how those work. >>> >> I needed to specify DEPENDS = "protobuf-native" to get it working, I >> would be really interested to understand exactly what that does, but I >> must admit to myself I can't understand everything in a single shot. > > Quoting my first email: >>> All you need to do, >>>is include meta-oe in your layers (bblayers.conf) and have >>> protobuf-native listed in DEPENDS inside your package recipe. > > DEPENDS lists build time dependencies, like libraries, tools etc. > protobuf-native, by convention, means that the package was built for > your build host. This enables you to run protoc during the build to > generate proper language bindings. > >> >> So never mind. >> >> I still have another question :-) >> >> I am about to create another recipe for the gprc library for C++, to >> build it on my local machine has been pretty simple: >> >> $ git clone -b $(curl -L http://grpc.io/release) >> https://github.com/grpc/grpc >> $ cd grpc >> $ git submodule update --init >> $ make >> $ [sudo] make install >> >> The recipe I have created so far would clone/checkout the source code >> from a GIT repo or something similar and then the build process could >> start straight away. >> >> In my case I have an additional step: >> >> git submodule update --init >> > > There's a submodule fetcher, when setting SRC_URI use `gitsm://` > instead of `git://` see > https://www.yoctoproject.org/docs/2.1/bitbake-user-manual/bitbake-user-manual.html#gitsm-fetcher > for details. > > Cheers, > -- > Maciej Borzecki > RnDity Thanks a lot. It looks like the project I am trying to clone does not follow the convention the gitsm module expects. ERROR: Function failed: Fetcher failure: Fetch command failed with exit code 1, output: cp: cannot stat '/.../build/downloads/git2/github.com.grpc.grpc/modules': No such file or directory Is there a way to get around it ? I have also noticed that the tag parameter does not work properly - it might be me making a mistake though. SRC_URI = "git://github.com/grpc/grpc;protocol=http;rev=3df9bdf88013e4c9cb5b5f092ac7cd1aad11fa96 Works fine, but: ERROR: Function failed: Fetcher failure for URL: 'git://github.com/grpc/grpc;protocol=http;tag=v1.0.0'. The command git -c core.fsyncobjectfiles=0 ls-remote http://github.com/grpc/grpc refs/heads/v1.0.0 refs/t ags/v1.0.0^{} gave empty output unexpectedly And indeed the command git -c core.fsyncobjectfiles=0 ls-remote http://github.com/grpc/grpc refs/heads/v1.0.0 refs/tags/v1.0.0^{} Does not result in any output while the command : git -c core.fsyncobjectfiles=0 ls-remote http://github.com/grpc/grpc refs/heads/v1.0.0 refs/tags/v1.0.0 Results in : 2a69139aa7f609e439c24a46754252a5f9d37500 refs/tags/v1.0.0 What's the use of '^{}' ? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Yocto and Google protobuffer 2016-09-01 9:34 ` Pietro 2016-09-01 10:21 ` Herman van Hazendonk @ 2016-09-01 10:43 ` Jussi Kukkonen 1 sibling, 0 replies; 21+ messages in thread From: Jussi Kukkonen @ 2016-09-01 10:43 UTC (permalink / raw) To: Pietro; +Cc: Yocto Project [-- Attachment #1: Type: text/plain, Size: 3763 bytes --] On 1 September 2016 at 12:34, Pietro <pulsarpietro@posteo.net> wrote: > Maciej Borzęcki > <maciej.borzecki@rndity.com> writes: > > > On Thu, Sep 1, 2016 at 10:40 AM, Pietro <pulsarpietro@posteo.net> wrote: > >> Maciej Borzęcki > >> <maciej.borzecki@rndity.com> writes: > >> > >>> On Wed, Aug 31, 2016 at 6:44 PM, Pietro <pulsarpietro@posteo.net> > wrote: > >>>> Hi all, > >>>> > >>>> I am new to the Yocto building system and I could be talking > nonsense. I > >>>> used to work with buildroot time ago and I remember there is an area > >>>> where compiled software/packages/tools previously built are "staged" > and > >>>> used when building other packages. > >>>> > >>>> Is there something like that available with Yocto ? Specifically I > would > >>>> like to add a package which uses the Google Protocol Buffer, I do not > have > >>>> administrator rights on the machine and I can't install the packages I > >>>> need system wise. > >>>> > >>>> Is it possible to add recipes and use them at building time without > >>>> including them in the image being generated ? > >>>> > >>>> A good example for that would be the protoc, the protocol buffer > description > >>>> file compiler. > >>>> > >>> > >>> There is a recipe for protobuf in meta-oe (2.6.1). All you need to do, > >>> is include meta-oe in your layers (bblayers.conf) and have > >>> protobuf-native listed in DEPENDS inside your package recipe. > >>> > >>> The protoc compiler will be available in the PATH when package is > >>> being built, so autotools checks like AC_CHECK_PROG/AC_PATH_PROG > >>> should be able to find it. > >>> > >>> Cheers, > >>> -- > >>> Maciej Borzecki > >>> RnDity > >> Thanks a lot. > >> > >> I have added the DEPENDS line and it indeed downloads and build the some > >> protobuf related stuff, where did you get the dependency name from ? > >> I can't see the protobuf-native as a recipe in the meta-oe website : > >> > >> https://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/ > > > > It's just a mechanism that allows for building the native (i.e. for > > the host) packages, and these are autmatically named ${PN}-native. > > There should a BBCLASSEXTEND = "..native.." stanza inside the protobuf > > recipe that enables this feature. > > > >> > >> I have just realised that GRPC (http://www.grpc.io/) is needed for my > >> project, it is a library which uses the protobuffers, is there a > >> recipe/package which provides them around or do I need to create my own > >> recipe ? > > > > You can try searching for a recipe at http://layers.openembedded.org > > If there's none, try to write your own. This might be a good changes > > to get yourself acquainted with `devtool` tool that will help you in > > the process. > > > >> > >> I would like to check the root filesystem being generated as part of the > >> build process, where is it ? > >> > > > > ${TMPDIR}/<machine>_<distro?>/<imagename>/../rootfs > > > > for instance, for my current build: > > > > tmp/work/vexpress_qemu-poky-linux-gnueabi/core-image- > minimal/1.0-r0/rootfs > > > > -- > > Maciej Borzecki > > RnDity > > Thanks, much appreciated. > > Do you know where the software which is not included in the image - such > us protoc - is it stored ? > The sysroots are in ${TMPDIR}/sysroots/: The native sysroot (probably x86_64-linux) will be one of those. The corresponding protobuf work directory will be in ${TMPDIR}/work/<target_system>/protobuf See the Yocto dev manual and reference manual for more details about these. http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html HTH, Jussi [-- Attachment #2: Type: text/html, Size: 5650 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2016-09-08 12:43 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-08-31 16:44 Yocto and Google protobuffer Pietro 2016-09-01 7:50 ` Maciej Borzęcki 2016-09-01 8:40 ` Pietro 2016-09-01 9:02 ` Maciej Borzęcki 2016-09-01 9:34 ` Pietro 2016-09-01 10:21 ` Herman van Hazendonk 2016-09-01 10:34 ` Jussi Kukkonen 2016-09-01 10:57 ` Samuel Stirtzel 2016-09-06 18:11 ` Khem Raj 2016-09-08 12:42 ` Samuel Stirtzel 2016-09-01 13:10 ` Pietro 2016-09-01 13:40 ` Pietro 2016-09-01 13:44 ` Herman van Hazendonk 2016-09-01 14:34 ` Pietro 2016-09-01 14:40 ` Herman van Hazendonk 2016-09-01 15:45 ` Pietro 2016-09-01 15:56 ` Maciej Borzęcki 2016-09-02 8:08 ` Pietro 2016-09-02 8:37 ` Maciej Borzęcki 2016-09-02 9:44 ` Pietro 2016-09-01 10:43 ` Jussi Kukkonen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.