[yocto] Yocto and Google protobuffer
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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto and Google protobuffer
Maciej Borzęcki writes: > On Wed, Aug 31, 2016 at 6:44 PM, Pietro 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 ? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto and Google protobuffer
Maciej Borzęcki
writes:
> On Thu, Sep 1, 2016 at 10:40 AM, Pietro wrote:
>> Maciej Borzęcki
>> writes:
>>
>>> On Wed, Aug 31, 2016 at 6:44 PM, Pietro 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}/_//../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.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto and Google protobuffer
Jussi Kukkonen writes: > On 1 September 2016 at 13:21, Herman van Hazendonk > 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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto and Google protobuffer
Pietro writes: > Jussi Kukkonen > writes: > >> On 1 September 2016 at 13:21, Herman van Hazendonk >> 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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto and Google protobuffer
Herman van Hazendonk 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 writes: >> >>> Jussi Kukkonen >>> writes: >>> >>>> On 1 September 2016 at 13:21, Herman van Hazendonk >>>> 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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto and Google protobuffer
Herman van Hazendonk 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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto and Google protobuffer
Maciej Borzęcki writes: > On Thu, Sep 1, 2016 at 5:45 PM, Pietro wrote: >> Herman van Hazendonk >> 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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto and Google protobuffer
Maciej Borzęcki
writes:
> On Thu, Sep 1, 2016 at 5:45 PM, Pietro wrote:
>> Herman van Hazendonk
>> 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 :
2a69139aa7f609e439c24a46754252a5f9d37500refs/tags/v1.0.0
What's the use of '^{}' ?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] arm-*-linux-gnueabi : unrecognized option -Wl, -soname
Hi all, I want to cross compile the gRPC library for ARM and I am using the Yocto build system. The build fails for the following error, which I am suspicious has something to do with the compiler being used: [LD] Linking /export/arm/xxx/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/libgrpc/1.0.0-r0/git/libs/opt/libgpr.so.1.0.0-pre1 arm-phytec-linux-gnueabi-ld : unrecognized option ' -Wl,-soname,libgpr.so.1 arm-phytec-linux-gnueabi-ld : use the --help option for usage information -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] arm-*-linux-gnueabi : unrecognized option -Wl, -soname
Well, I am cross-compiling the gRPC using the Yocto build system, I have created a recipe for a new package which generates the gRPC library(ies). The error comes from here *guess* : ifeq ($(SYSTEM),Darwin) $(Q) $(LD) $(LDFLAGS) -L$(LIBDIR)/$(CONFIG) -install_name $(SHARED_PREFIX)gpr$(SHARED_VERSION).$(SHARED_EXT) -dynamiclib -o $(LIBDIR)/$(CONFIG)/libgpr$(SHARED_VERSION).$(SHARED_EXT) $(LIBGPR_OBJS) $(LDLIBS) $(ZLIB_MERGE_LIBS) else $(Q) $(LD) $(LDFLAGS) -L$(LIBDIR)/$(CONFIG) -shared -Wl,-soname,libgpr.so.1 -o $(LIBDIR)/$(CONFIG)/libgpr$(SHARED_VERSION).$(SHARED_EXT) $(LIBGPR_OBJS) $(LDLIBS) $(ZLIB_MERGE_LIBS) $(Q) ln -sf $(SHARED_PREFIX)gpr$(SHARED_VERSION).$(SHARED_EXT) $(LIBDIR)/$(CONFIG)/libgpr$(SHARED_VERSION).so.1 $(Q) ln -sf $(SHARED_PREFIX)gpr$(SHARED_VERSION).$(SHARED_EXT) $(LIBDIR)/$(CONFIG)/libgpr$(SHARED_VERSION).so endif What's puzzles me is that the same source code builds without problem on my machine (not cross compiled). It might be a question for gRPC developers though "Daniel." writes: > I *guess* that it should be -Wl,-soname=libgpr.so.1 intead of > -Wl,-soname,libgpr.so.1. Now from where this flags are comming is a > good question.. > > 2016-09-05 9:17 GMT-03:00 Pietro : >> >> Hi all, >> >> I want to cross compile the gRPC library for ARM and I am using the >> Yocto build system. >> >> The build fails for the following error, which I am suspicious has >> something to do with the compiler being used: >> >> >> [LD] Linking >> /export/arm/xxx/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/libgrpc/1.0.0-r0/git/libs/opt/libgpr.so.1.0.0-pre1 >> >> arm-phytec-linux-gnueabi-ld >> : unrecognized option ' >> -Wl,-soname,libgpr.so.1 >> >> >> arm-phytec-linux-gnueabi-ld >> : use the --help option for usage information >> >> >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > > > -- > "Do or do not. There is no try" > Yoda Master -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] arm-*-linux-gnueabi : unrecognized option -Wl, -soname
"Daniel." writes: > I *guess* that it should be -Wl,-soname=libgpr.so.1 intead of > -Wl,-soname,libgpr.so.1. Now from where this flags are comming is a > good question.. No that is correct, I double checked. I would love to build the library "by hand" - namely without using bitbake - from the build directory, the build log tells : + bbnote make -j 4 CC=arm-phytec-linux-gnueabi-gcc -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 --sysroot=/export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/phycore-am335x-1 LDFLAGS="" -I/export/arm/pietro/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/libgrpc/1.0.0-r0/git/include BUILDDIR=/export/arm/pietro/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/libgrpc/1.0.0-r0/git + echo NOTE: make -j 4 CC=arm-phytec-linux-gnueabi-gcc -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 --sysroot=/export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/phycore-am335x-1 LDFLAGS="" -I/export/arm/pietro/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/libgrpc/1.0.0-r0/git/include BUILDDIR=/export/arm/pietro/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/libgrpc/1.0.0-r0/git Of course jumping in the build directory and issuing the command does not work as the make tool does not recognize options such as -marm and companions as they are gcc's options. I have manually added the cross compiler folder to my local PATH but and I have quoted all the gcc's options under the CC variable: CC='arm-phytec-linux-gnueabi-gcc -march=armv7-a -marm -mthumb-interwork ...' Is there a standard/better way to do it ? That results in an error as some header files could not be found [C] Compiling src/core/lib/profiling/basic_timers.c In file included from /export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/phycore-am335x-1/usr/include/features.h:389:0, from include/grpc/impl/codegen/port_platform.h:193, from include/grpc/support/port_platform.h:37, from src/core/lib/profiling/basic_timers.c:34: /export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/phycore-am335x-1/usr/include/gnu/stubs.h:7:29: fatal error: gnu/stubs-soft.h: No such file or directory # include I am not getting this error when building using bitbake therefore I am pretty sure I am missing some include paths or .. what ? > > 2016-09-05 9:17 GMT-03:00 Pietro : >> >> Hi all, >> >> I want to cross compile the gRPC library for ARM and I am using the >> Yocto build system. >> >> The build fails for the following error, which I am suspicious has >> something to do with the compiler being used: >> >> >> [LD] Linking >> /export/arm/xxx/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/libgrpc/1.0.0-r0/git/libs/opt/libgpr.so.1.0.0-pre1 >> >> arm-phytec-linux-gnueabi-ld >> : unrecognized option ' >> -Wl,-soname,libgpr.so.1 >> >> >> arm-phytec-linux-gnueabi-ld >> : use the --help option for usage information >> >> >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > > > -- > "Do or do not. There is no try" > Yoda Master -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] arm-*-linux-gnueabi : unrecognized option -Wl, -soname
Maciej Borzęcki writes: > On Tue, Sep 6, 2016 at 12:05 PM, Pietro wrote: >> >> >> >> "Daniel." writes: >> >>> I *guess* that it should be -Wl,-soname=libgpr.so.1 intead of >>> -Wl,-soname,libgpr.so.1. Now from where this flags are comming is a >>> good question.. >> >> No that is correct, I double checked. >> >> I would love to build the library "by hand" - namely without using >> bitbake - from the build directory, the build log tells : >> >> + bbnote make -j 4 >> CC=arm-phytec-linux-gnueabi-gcc -march=armv7-a -marm -mthumb-interwork >> -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 >> >> --sysroot=/export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/phycore-am335x-1 >> LDFLAGS="" >> >> -I/export/arm/pietro/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/libgrpc/1.0.0-r0/git/include >> >> BUILDDIR=/export/arm/pietro/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/libgrpc/1.0.0-r0/git >> + echo NOTE: make -j 4 CC=arm-phytec-linux-gnueabi-gcc -march=armv7-a >> -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 >> >> --sysroot=/export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/phycore-am335x-1 >> LDFLAGS="" >> >> -I/export/arm/pietro/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/libgrpc/1.0.0-r0/git/include >> >> BUILDDIR=/export/arm/pietro/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/libgrpc/1.0.0-r0/git >> >> Of course jumping in the build directory and issuing the command does >> not work as the make tool does not recognize options such as -marm and >> companions as they are gcc's options. >> >> I have manually added the cross compiler folder to my local PATH but and >> I have quoted all the gcc's options under the CC variable: >> >> >> CC='arm-phytec-linux-gnueabi-gcc -march=armv7-a -marm -mthumb-interwork >> ...' >> >> Is there a standard/better way to do it ? That results in an error as >> some header files could not be found >> >> [C] Compiling src/core/lib/profiling/basic_timers.c >> In file included from >> /export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/phycore-am335x-1/usr/include/features.h:389:0, >> from include/grpc/impl/codegen/port_platform.h:193, >> from >> include/grpc/support/port_platform.h:37, >> from >> src/core/lib/profiling/basic_timers.c:34: >> /export/arm/pietro/PD15.1/build/tmp-glibc/sysroots/phycore-am335x-1/usr/include/gnu/stubs.h:7:29: >> fatal error: >> gnu/stubs-soft.h: No >> such file or >> directory >> # include >> >> I am not getting this error when building using bitbake therefore I am >> pretty sure I am missing some include paths or .. what ? >> > > Maybe the Makefile they have is just not up to the task of cross > compilation. I see that gRPC comes with a cmake setup as well, why not > use that? You'll need `inherit cmake` in your recipe and try with > default build scripts first. > > Cheers, > -- > Maciej Borzecki > RnDity I did try but I am getting errors, cmake results in error when compiling from my machine as well and in fact the gRPC webpage tells CMake is in experimental state: https://github.com/grpc/grpc/blob/master/INSTALL.md -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-java] openjdk-7-jre was skipped: missing required distro feature ['x11'] (not in DISTRO_FEATURES)
Hi Folks, I'm trying to compile java without x11 and unfortunately also without success.. I've added in my local.conf: DISTRO_FEATURES_remove = "x11" # Java build settings PREFERRED_PROVIDER_virtual/java-native = "jamvm-native" PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native" PREFERRED_VERSION_openjdk-7-jre = "85b01-2.6.1" PREFERRED_VERSION_icedtea7-native = "2.1.3" PREFERRED_PROVIDER_openjdk-7-jre = "openjdk-7-jre" but I get this error ERROR: Nothing RPROVIDES 'openjdk-7-jre' (but /home/f34389b/yocto/PCM/R5.0/sources/meta-fede/recipes-images/images/ fede-java-test.bb RDEPENDS on or otherwise requires it) ERROR: openjdk-7-jre was skipped: missing required distro feature ['x11'] (not in DISTRO_FEATURES) Patching those files: meta-java/recipes-core/classpath/classpath.inc meta-java/recipes-core/jamvm/jamvm.inc meta-java/recipes-core/jamvm/jamvm_git.bb meta-java/recipes-core/openjdk/openjdk-common.inc poky/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc like this: -REQUIRED_DISTRO_FEATURES = "x11" +#REQUIRED_DISTRO_FEATURES = "x11" seems to be a temporary workaround regards federico -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-java] can zero shark be enabled again?
Hi again, I saw that some JIT optimization for arm32 has been announcement in icedtea the announcement is available at http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2015-January/030392.html So I'm just wondering if anyone know if shark can be enabled again also in yocto recipes and can suggest me some tip to use it. thanks and regards Federico -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-java] openjdk-7-jre was skipped: missing required distro feature ['x11'] (not in DISTRO_FEATURES)
2015-10-16 16:09 GMT+01:00, Jens Rehsack : > >> Am 16.10.2015 um 15:35 schrieb Federico Pietro Briata >> : >> >> Hi Folks, >> I'm trying to compile java without x11 and unfortunately also without >> success.. >> >> I've added in my local.conf: >> >> DISTRO_FEATURES_remove = "x11" >> # Java build settings >> PREFERRED_PROVIDER_virtual/java-native = "jamvm-native" >> PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native" >> PREFERRED_VERSION_openjdk-7-jre = "85b01-2.6.1" >> PREFERRED_VERSION_icedtea7-native = "2.1.3" >> PREFERRED_PROVIDER_openjdk-7-jre = "openjdk-7-jre" >> >> but I get this error >> >> ERROR: Nothing RPROVIDES 'openjdk-7-jre' (but >> /home/f34389b/yocto/PCM/R5.0/sources/meta-fede/recipes-images/images/fede-java-test.bb >> RDEPENDS on or otherwise requires it) >> ERROR: openjdk-7-jre was skipped: missing required distro feature ['x11'] >> (not in DISTRO_FEATURES) >> >> Patching those files: >> meta-java/recipes-core/classpath/classpath.inc >> meta-java/recipes-core/jamvm/jamvm.inc >> meta-java/recipes-core/jamvm/jamvm_git.bb >> meta-java/recipes-core/openjdk/openjdk-common.inc >> poky/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc >> >> like this: >> -REQUIRED_DISTRO_FEATURES = "x11" >> +#REQUIRED_DISTRO_FEATURES = "x11" >> >> seems to be a temporary workaround > > Hi Federico, > > unfortunately I missed > https://github.com/rehsack/meta-java/commit/11e30f2bf198bcad91c0d14104fcd8b91255ad69 > when submitting my patchset. > > I'm working on some jdk7 native fixes and layer cleanup and will send a new > patchset later today. > > I do not intend to provide jdk7 for cross-compiling support without x11 - > when you want no-x11, from my point of view, go to jdk8. > > Cheers > -- > Jens Rehsack - rehs...@gmail.com > > Hi Jens, my machine it's a arm7 Imx6 display less. I choose jdk7 because I thought was the best for my target, so for you should I go to jdk8? Anyway I've compiled jdk7 now, but I'm not sure if I've to use some specific configuration set for build with no-x11. thanks federico -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-java] can zero shark be enabled again?
2015-10-16 16:14 GMT+01:00, Jens Rehsack : > > I fear you mix between ARMJIT provided by IceadTea and ZeroShark provided by > OpenJDK. Ops > While IcedTea maintains the ARMJIT within hotspot ported from OpenJDK6, > ZeroShark uses LLVM's JIT. I thought ARMJIT was part of Shark and provided with hotspot Zero, thanks for clarification! > Since ARM support in LLVM's JIT was utterly broken, MCJIT support is > required for ZeroShark. > I was working on that but my ARMv7 and my ARMv5 are still crashing - even > when I can realize some progress (how quick does it crash ^^). > > Dunno if - and if, when - I find some tuits to continue the crash detection > and fixing... Can I help you with testing and debugging? If you give me some tip, I've lot of time to spend for it! :) > > Cheers Ciao federico -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-java] can zero shark be enabled again?
2015-10-16 17:14 GMT+02:00 Jens Rehsack : > > While IcedTea maintains the ARMJIT within hotspot ported from OpenJDK6, > ZeroShark uses LLVM's JIT. > > Since ARM support in LLVM's JIT was utterly broken, MCJIT support is > required for ZeroShark. > I was working on that but my ARMv7 and my ARMv5 are still crashing - even > when I can realize some progress (how quick does it crash ^^). > > Hi I'm trying to compare performance of openjdk 7 with Oracle ejdk 8 # java -version java version "1.7.0_85" OpenJDK Runtime Environment (IcedTea 2.6.1) (85b01-2.6.1) OpenJDK Zero VM (build 24.85-b03, mixed mode) # java Linpack Mflops/s: 13.205 Time: 0.05 secs Norm Res: 1.43 Precision: 2.220446049250313E-16 # /usr/local/java.oracle/bin/java -version java version "1.8.0_06" Java(TM) SE Embedded Runtime Environment (build 1.8.0_06-b23) Java HotSpot(TM) Embedded Client VM (build 25.6-b23, mixed mode) # /usr/local/java.oracle/bin/java Linpack Mflops/s: 22.151 Time: 0.03 secs Norm Res: 1.43 Precision: 2.220446049250313E-16 As I prefer stay free and avoid commercial solution, anyone can confirm me that I didn't forgot some optimization in my OpenJDK or something it's still improved? thanks and regards federico -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-java] [PATCH] gnumail: Fix race condition in makefile fail to apply
Hi Maxin, thanks a lot, after a pull it's working but now I got a different issue.. :/ I'll send a separate email about the current trouble.. Thanks again Federico 2015-12-11 14:23 GMT+01:00 Maxin B. John : > Hi Federico, > > On Fri, Dec 11, 2015 at 12:45:18PM +0100, Federico Pietro Briata wrote: > >Hi > > > >I just pull to build openjdk-8 and I get this error: > > > >ERROR: Command Error: exit status: 1 Output: > >Applying patch fix_makefile_race_condition.patch > >patching file Makefile.am > >Hunk #1 FAILED at 295. > >1 out of 3 hunks FAILED -- rejects in file Makefile.am > >Patch fix_makefile_race_condition.patch does not apply (enforce with -f) > >ERROR: Function failed: patch_do_patch > >ERROR: Logfile of failure stored in: > /home/federico/yocto/imx6/R5.0/build-pcm-mx6quad/tmp-eglibc/work/x86_64-linux/gnumail-native/1.1.2-r1/temp/log.do_patch.7775 > >ERROR: Task 613 > (virtual:native:/home/federico/yocto/imx6/R5.0/sources/meta-java/recipes-core/classpathx/ > gnumail_1.1.2.bb, do_patch) failed with exit code '1' > > > > This was due to a nasty encoding related corruption in the patch (most > likely mangled by > mail agent). It is fixed in master by a force push (apologies for doing > that). > > Please clone the repo and try again. > > >best regards > >federico > > Best Regards, > Maxin > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-java] openjdk-8 fail to build
Hi All, I'm trying to build openjdk-8 but I'm stuck. my current setup does not define anything for: #PREFERRED_PROVIDER_virtual/java-native #PREFERRED_PROVIDER_virtual/javac-native follow the log error ERROR: Function failed: do_configure (log file is located at /home/federico/yocto/imx6/R6.0/build-imx6-mx6quad/tmp/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_configure.27024) ERROR: Logfile of failure stored in: /home/federico/yocto/imx6/R6.0/build-imx6-mx6quad/tmp/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_configure.27024 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Python function sysroot_cleansstate finished | DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 'bit-64', 'x86_64-linux', 'common'] | DEBUG: Executing shell function autotools_preconfigure | DEBUG: Shell function autotools_preconfigure finished | DEBUG: Executing python function autotools_copy_aclocals | DEBUG: Python function autotools_copy_aclocals finished | DEBUG: Executing shell function do_configure | ERROR: no configure script found at /home/federico/yocto/imx6/R6.0/build-imx6-mx6quad/tmp/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u-e8bed1496ff2/configure | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_configure (log file is located at /home/federico/yocto/imx6/R6.0/build-imx6-mx6quad/tmp/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_configure.27024) ERROR: Task 146 (/home/federico/yocto/imx6/R6.0/sources/meta-java/recipes-core/openjdk/ openjdk-8-native_72b05.bb, do_configure) failed with exit code '1' NOTE: Tasks Summary: Attempted 1139 tasks of which 15 didn't need to be rerun and 1 failed. No currently running tasks (1139 of 1150) Summary: 1 task failed: /home/federico/yocto/imx6/R6.0/sources/meta-java/recipes-core/openjdk/ openjdk-8-native_72b05.bb, do_configure thanks and regards Federico -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-java] openjdk-8 fail to build
Hi Jens 2015-12-13 10:03 GMT+01:00 Jens Rehsack : > > > Am 11.12.2015 um 18:16 schrieb Federico Pietro Briata < > federicobri...@gmail.com>: > > > | ERROR: no configure script found at > /home/federico/yocto/imx6/R6.0/build-imx6-mx6quad/tmp/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u-e8bed1496ff2/configure > > Are you on poky/master or cherry-picked fe506edd? I'm on poky/master Tag: daisy-11.0.2 Hash: e3dd621197548b4cf64988e757e9bc926082db73 regards Federico -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-java] openjdk-8 fail to build
Hi Stef, Thanks, I've tried to apply that patch and also http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=527b28c10955daf0387597020d69593ce24bcaa4 and now I'm getting this: ERROR: Function failed: do_compile (log file is located at /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_compile.15889) ERROR: Logfile of failure stored in: /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_compile.15889 Log data follows: | DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 'bit-64', 'x86_64-linux', 'common'] | DEBUG: Executing shell function do_compile | NOTE: make OE_CFLAGS=-isystem/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/include -O2 -pipe -DHEADLESS=true OE_CPPFLAGS=-isystem/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/include -DHEADLESS=true OE_CXXFLAGS=-isystem/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/include -O2 -pipe -DHEADLESS=true OE_LDFLAGS=-L/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/lib -L/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/lib -Wl,-rpath-link,/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/lib -Wl,-rpath-link,/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/lib -Wl,-rpath,/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/lib -Wl,-rpath,/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/lib -Wl,-O1 BUILD_HEADLESS_ONLY=1 BUILD_HEADLESS=true BUILD_SOUNDLESS_ONLY=1 X11_NOT_NEEDED=1 CUPS_NOT_NEEDED=1 ALSA_NOT_NEEDED=1 PULSE_NOT_NEEDED=1 MAKE_VERBOSE=y VERBOSE=-s LOG_LEVEL=trace QUIETLY= images | /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u-e8bed1496ff2/Makefile:27: *** Too many open files. Stop. | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_compile (log file is located at /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_compile.15889) ERROR: Task 207 (/home/federico/yocto/imx6/R6.0/sources/meta-java/recipes-core/openjdk/ openjdk-8-native_72b05.bb, do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 1469 tasks of which 1237 didn't need to be rerun and 1 failed. No currently running tasks (1469 of 1483) Summary: 1 task failed: /home/federico/yocto/imx6/R6.0/sources/meta-java/recipes-core/openjdk/ openjdk-8-native_72b05.bb, do_compile Summary: There was 1 ERROR message shown, returning a non-zero exit code. thanks and regards federico 2015-12-19 10:38 GMT+01:00 Stef : > Federico Pietro Briata writes: > > > > > > > > > Hi All, > > I'm trying to build openjdk-8 but I'm stuck.my current setup does not > define anything for:#PREFERRED_PROVIDER_virtual/java- > native#PREFERRED_PROVIDER_virtual/javac-native > > > > follow the log error > > > > > > > > ERROR: Function failed: do_configure (log file is located at > /home/federico/yocto/imx6/R6.0/build-imx6-mx6quad/tmp/work/x86_64- > linux/openjdk-8-native/72b05-r0/temp/log.do_configure.27024)ERROR: > Logfile of failure stored in: /home/federico/yocto/imx6/R6.0/build-imx6- > mx6quad/tmp/work/x86_64-linux/openjdk-8-native/72b05- > r0/temp/log.do_configure.27024Log data follows:| DEBUG: Executing python > function sysroot_cleansstate| DEBUG: Python function sysroot_cleansstate > finished| DEBUG: SITE files ['endian-little', 'common-linux', 'common- > glibc', 'bit-64', 'x86_64-linux', 'common']| DEBUG: Executing shell > function autotools_preconfigure| DEBUG: Shell function > autotools_preconfigure finished| DEBUG: Executing python function > autotools_copy_aclocals| DEBUG: Python function autotools_copy_aclocals > finished| DEBUG: Executing shell function do_configure| ERROR: no > configure script found at /home/federico/yocto/imx6/R6.0/build-imx6- > mx6quad/tmp/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u- > e8bed1496ff2/configure| WARNING: exit code 1 from a shell command.| > ERROR: Function failed: do_configure (log file is located at > /home/federico/yocto/imx6/R6.0/build-imx6-mx6quad/tmp/work/x86_64- > linux/openjdk-8-native/72b05-r0/temp/log.do_configure.27024)ERROR: Task > 146 (/home/federico/yocto/imx6/R6.0/sources/meta-java/recipes- >
Re: [yocto] [meta-java] openjdk-8 fail to build
Hi again, looking to the above error on Makefile, seems there is still something wrong with autotools cat /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u-e8bed1496ff2/Makefile # This Makefile was generated by configure Tue Jan 12 22:44:00 CET 2016 # GENERATED FILE, DO NOT EDIT SPEC:=/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u-e8bed1496ff2/build/linux-x86_64-normal-server-release/spec.gmk include /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u-e8bed1496ff2/Makefile so the build stuck here in this loop I think. regards Federico 2016-01-12 17:41 GMT+01:00 Federico Pietro Briata : > Hi Stef, > Thanks, I've tried to apply that patch and also > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=527b28c10955daf0387597020d69593ce24bcaa4 > > and now I'm getting this: > > ERROR: Function failed: do_compile (log file is located at > /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_compile.15889) > ERROR: Logfile of failure stored in: > /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_compile.15889 > Log data follows: > | DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', > 'bit-64', 'x86_64-linux', 'common'] > | DEBUG: Executing shell function do_compile > | NOTE: make > OE_CFLAGS=-isystem/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/include > -O2 -pipe -DHEADLESS=true > OE_CPPFLAGS=-isystem/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/include > -DHEADLESS=true > OE_CXXFLAGS=-isystem/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/include > -O2 -pipe -DHEADLESS=true > OE_LDFLAGS=-L/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/lib > -L/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/lib > -Wl,-rpath-link,/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/lib > -Wl,-rpath-link,/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/lib > -Wl,-rpath,/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/lib > -Wl,-rpath,/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/lib > -Wl,-O1 BUILD_HEADLESS_ONLY=1 BUILD_HEADLESS=true BUILD_SOUNDLESS_ONLY=1 > X11_NOT_NEEDED=1 CUPS_NOT_NEEDED=1 ALSA_NOT_NEEDED=1 PULSE_NOT_NEEDED=1 > MAKE_VERBOSE=y VERBOSE=-s LOG_LEVEL=trace QUIETLY= images > | > /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u-e8bed1496ff2/Makefile:27: > *** Too many open files. Stop. > | ERROR: oe_runmake failed > | WARNING: exit code 1 from a shell command. > | ERROR: Function failed: do_compile (log file is located at > /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_compile.15889) > ERROR: Task 207 > (/home/federico/yocto/imx6/R6.0/sources/meta-java/recipes-core/openjdk/ > openjdk-8-native_72b05.bb, do_compile) failed with exit code '1' > NOTE: Tasks Summary: Attempted 1469 tasks of which 1237 didn't need to be > rerun and 1 failed. > No currently running tasks (1469 of 1483) > > Summary: 1 task failed: > /home/federico/yocto/imx6/R6.0/sources/meta-java/recipes-core/openjdk/ > openjdk-8-native_72b05.bb, do_compile > Summary: There was 1 ERROR message shown, returning a non-zero exit code. > > thanks and regards > federico > > 2015-12-19 10:38 GMT+01:00 Stef : > >> Federico Pietro Briata writes: >> >> > >> > >> > >> > Hi All, >> > I'm trying to build openjdk-8 but I'm stuck.my current setup does not >> define anything for:#PREFERRED_PROVIDER_virtual/java- >> native#PREFERRED_PROVIDER_virtual/javac-native >> > >> > follow the log error >> > >> > >> > >> > ERROR: Function failed: do_configure (log file is located at >> /home/federico/yocto/imx6/R6.0/build-imx6-mx6quad/tmp/work/x86_64- >> linux/openjdk-8-native/72b05-r0/temp/log.do_configure.27024)ERROR: >> Logfile of failure stored in: /home/federico/yocto/imx6/R6.0/build-imx6- >> mx6quad/tmp/work/x86_64-linux/openjdk-8-nat
Re: [yocto] [meta-java] openjdk-8 fail to build
Hi, I'm on 1.6.2 (daisy Branch), so probably I've to cherry-pick something more on poky. With poky-daisy-11.0.2 (Hash: e3dd621197548b4cf64988e757e9bc926082db73) I confirm that openjdk 7 was working for sure with this commit d7d4f64a32d26fc8a92e4c89b47c78956f20a14d Regards, Federico Hi, What version of Yocto are you using? I'm using 1.7.1 version with only the patch i described in my previous answer. When using it on the master of meta-java i got it working without any issues.. You mentioned you use another patch as well? Regards 2016-01-13 18:46 GMT+01:00 Federico Pietro Briata : > Hi again, > looking to the above error on Makefile, seems there is still something > wrong with autotools > > > cat > /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u-e8bed1496ff2/Makefile > # This Makefile was generated by configure Tue Jan 12 22:44:00 CET 2016 > # GENERATED FILE, DO NOT EDIT > > SPEC:=/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u-e8bed1496ff2/build/linux-x86_64-normal-server-release/spec.gmk > include > /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u-e8bed1496ff2/Makefile > > so the build stuck here in this loop I think. > > regards > Federico > > 2016-01-12 17:41 GMT+01:00 Federico Pietro Briata : > >> Hi Stef, >> Thanks, I've tried to apply that patch and also >> >> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=527b28c10955daf0387597020d69593ce24bcaa4 >> >> and now I'm getting this: >> >> ERROR: Function failed: do_compile (log file is located at >> /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_compile.15889) >> ERROR: Logfile of failure stored in: >> /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_compile.15889 >> Log data follows: >> | DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', >> 'bit-64', 'x86_64-linux', 'common'] >> | DEBUG: Executing shell function do_compile >> | NOTE: make >> OE_CFLAGS=-isystem/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/include >> -O2 -pipe -DHEADLESS=true >> OE_CPPFLAGS=-isystem/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/include >> -DHEADLESS=true >> OE_CXXFLAGS=-isystem/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/include >> -O2 -pipe -DHEADLESS=true >> OE_LDFLAGS=-L/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/lib >> -L/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/lib >> -Wl,-rpath-link,/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/lib >> -Wl,-rpath-link,/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/lib >> -Wl,-rpath,/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/usr/lib >> -Wl,-rpath,/home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/sysroots/x86_64-linux/lib >> -Wl,-O1 BUILD_HEADLESS_ONLY=1 BUILD_HEADLESS=true BUILD_SOUNDLESS_ONLY=1 >> X11_NOT_NEEDED=1 CUPS_NOT_NEEDED=1 ALSA_NOT_NEEDED=1 PULSE_NOT_NEEDED=1 >> MAKE_VERBOSE=y VERBOSE=-s LOG_LEVEL=trace QUIETLY= images >> | >> /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u-e8bed1496ff2/Makefile:27: >> *** Too many open files. Stop. >> | ERROR: oe_runmake failed >> | WARNING: exit code 1 from a shell command. >> | ERROR: Function failed: do_compile (log file is located at >> /home/federico/yocto/imx6/R6.0/build-OpenJDK8-imx6-mx6quad/tmp-eglibc/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_compile.15889) >> ERROR: Task 207 >> (/home/federico/yocto/imx6/R6.0/sources/meta-java/recipes-core/openjdk/ >> openjdk-8-native_72b05.bb, do_compile) failed with exit code '1' >> NOTE: Tasks Summary: Attempted 1469 tasks of which 1237 didn't need to be >> rerun and 1 failed. >> No currently running tasks (1469 of 1483) >> >> Summary: 1 task failed: >> /home/federico/yocto/imx6/R6.0/sources/meta-java/recipes-core/openjdk/ >> openjdk-8-native_72b05.bb, do_compile >> Summary: There was 1 ERROR messag
[yocto] [meta-virtualization] [recipes-containers] criu version 2.12.1
Hi All, in attach my recipes for Criu 2.12.1. Best regards, Federico Briata --- recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0002-criu-Skip-documentation-install.patch | 28 +++ recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch | 94 +++ recipes-containers/criu/criu_2.12.1.bb | 79 +++ recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch | 24 ++ 4 files changed, 225 insertions(+), 0 deletions(-) diff --git a/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch new file mode 100644 index 000..88efba3 --- /dev/null +++ b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch @@ -0,0 +1,24 @@ +diff --git a/Makefile.install b/Makefile.install +index 7f867cf..15b6065 100644 +--- a/Makefile.install b/Makefile.install +@@ -8,19 +8,6 @@ LIBDIR:= $(PREFIX)/lib + INCLUDEDIR:= $(PREFIX)/include + LIBEXECDIR:= $(PREFIX)/libexec + +-# +-# For recent Debian/Ubuntu with multiarch support. +-DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH 2>/dev/null) +-ifneq "$(DEB_HOST_MULTIARCH)" "" +-LIBDIR:= $(PREFIX)/lib/$(DEB_HOST_MULTIARCH) +-else +-# +-# For most other systems +-ifeq "$(shell uname -m)" "x86_64" +-LIBDIR:= $(PREFIX)/lib64 +-endif +-endif +- + export PREFIX BINDIR SBINDIR MANDIR + export LIBDIR INCLUDEDIR LIBEXECDIR + diff --git a/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch new file mode 100644 index 000..1e1437d --- /dev/null +++ b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch @@ -0,0 +1,94 @@ +diff --git a/Makefile b/Makefile +index 79490d0..1e421b1 100644 +--- a/Makefile b/Makefile +@@ -54,7 +54,7 @@ LDARCH ?= $(SRCARCH) + + export SRCARCH LDARCH VDSO + +-UNAME-M := $(shell uname -m) ++UNAME-M ?= $(shell uname -m) + export UNAME-M + + ifeq ($(ARCH),arm) +diff --git a/criu/pie/Makefile b/criu/pie/Makefile +index 141c018..09dbdc6 100644 +--- a/criu/pie/Makefile b/criu/pie/Makefile +@@ -17,7 +17,7 @@ restorer-obj-e += ./$(ARCH_DIR)/syscalls.built-in.o + # + CFLAGS:= $(filter-out -pg $(CFLAGS-GCOV),$(CFLAGS)) + CFLAGS+= -iquote $(SRC_DIR)/criu/pie/piegen +-CFLAGS+= -iquote $(SRC_DIR)/criu/arch/$(ARCH)/include ++CFLAGS+= -iquote $(SRC_DIR)/criu/arch/$(SRCARCH)/include + CFLAGS+= -iquote $(SRC_DIR)/criu/include + CFLAGS+= -iquote $(SRC_DIR)/include + CFLAGS+= -iquote $(SRC_DIR) +diff --git a/scripts/nmk/scripts/include.mk b/scripts/nmk/scripts/include.mk +index 711b9da..3d44624 100644 +--- a/scripts/nmk/scripts/include.mk b/scripts/nmk/scripts/include.mk +@@ -20,7 +20,7 @@ SUBARCH := $(shell uname -m | sed \ + -e s/aarch64.*/arm64/) + + ARCH ?= $(SUBARCH) +-SRCARCH := $(ARCH) ++SRCARCH ?= $(ARCH) + + export SUBARCH ARCH SRCARCH + +diff --git a/scripts/nmk/scripts/tools.mk b/scripts/nmk/scripts/tools.mk +index 56dba84..1698821 100644 +--- a/scripts/nmk/scripts/tools.mk b/scripts/nmk/scripts/tools.mk +@@ -2,30 +2,30 @@ ifndef nmk_defined__tools + + # + # System tools shorthands +-RM:= rm -f ++RM?= rm -f + HOSTLD?= ld +-LD:= $(CROSS_COMPILE)$(HOSTLD) ++LD?= $(CROSS_COMPILE)$(HOSTLD) + HOSTCC?= gcc +-CC:= $(CROSS_COMPILE)$(HOSTCC) +-CPP := $(CC) -E +-AS:= $(CROSS_COMPILE)as +-AR:= $(CROSS_COMPILE)ar +-STRIP := $(CROSS_COMPILE)strip +-OBJCOPY := $(CROSS_COMPILE)objcopy +-OBJDUMP := $(CROSS_COMPILE)objdump +-NM:= $(CROSS_COMPILE)nm +-MAKE := make +-MKDIR := mkdir -p +-AWK := awk +-PERL := perl +-PYTHON:= python +-FIND := find +-SH:= $(shell if [ -x "$$BASH" ]; then echo $$BASH;\ ++CC?= $(CROSS_COMPILE)$(HOSTCC) ++CPP ?= $(CC) -E ++AS?= $(CROSS_COMPILE)as ++AR?= $(CROSS_COMPILE)ar ++STRIP ?= $(CROSS_COMPILE)strip ++OBJCOPY ?= $(CROSS_COMPILE)objcopy ++OBJDUMP ?= $(CROSS_COMPILE)objdump ++NM?= $(CROSS_COMPILE)n
