With the change of crosssdk to use SDK_SYS instead of SDK_ARCH, we need to
update
the recipe to match the changes in master.
[YOCTO #9281]
Signed-off-by: Juro Bystricky
---
recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_3.1.0.bb | 2 +-
1 file changed, 1
The current master deviated enough from krogoth that it needs new meta-mingw
patches (and a separate meta-mingw branch) in order to build (cross-compile)
anything.
Only the build itself was tested, not the actual functionality of the
resulting deployables. Nevertheless, correct functionality is
Default configuration for gcc-crosssddk is now to enable initfini-array.
However, this works only for Linux so we disable it for mingw32.
Otherwise we will eventually encounter build error such as:
multiple definition of `__do_global_dtors'
Signed-off-by: Juro Bystricky
Default configuration for gcc-crosssddk-initial is now to enable initfini-array.
However, this works only for Linux so we disable it for mingw32.
Otherwise, (with SDKMACHINE=x86_64-mingw32) we will eventually encounter errors
such as:
Assembler messages:
Error: invalid instruction suffix for
Using Jethro release and attempting to build either openjdk-7 or 8 fails
when fetching icedtea7-native/2.1.3-r1.0 due to checksum mismatches (on all
the SRC_URI entries).
openjdk-7 did successfully build about a month ago.
Is there a workaround, fix or other suggestions?
Thanks
--
> On Oct 5, 2016, at 4:45 PM, Randy Mortensen
> wrote:
>
>
>> On Oct 5, 2016, at 5:04 PM, Darcy Watkins
>> wrote:
>>
>> From what I gleaned from recent discussions of fetcher errors, this is
>> somehow connected with rollout of
> On Oct 5, 2016, at 5:04 PM, Darcy Watkins wrote:
>
> From what I gleaned from recent discussions of fetcher errors, this is
> somehow connected with rollout of Python related security fixes to various
> Linux distributions and/or some ...-native recipes.
>
>
From what I gleaned from recent discussions of fetcher errors, this is somehow
connected with rollout of Python related security fixes to various Linux
distributions and/or some ...-native recipes.
It was a bunch of tar balls that are named as mercurial hashes from within iced
tea rather than
> On Oct 5, 2016, at 3:49 PM, Juro Bystricky wrote:
>
> Default configuration for gcc-crosssddk is now to enable initfini-array.
> However, this works only for Linux so we disable it for mingw32.
> Otherwise we will eventually encounter build error such as:
>
>
> On Oct 5, 2016, at 4:52 PM, Khem Raj wrote:
>> On Oct 5, 2016, at 4:45 PM, Randy Mortensen
>> wrote:
>>> On Oct 5, 2016, at 5:04 PM, Darcy Watkins
>>> wrote:
>>>
>>> From what I gleaned from recent discussions
On Wed, 05 Oct 2016 05:12:27 Dinh Nguyen wrote:
> Thanks much Paul.
>
> PACKAGES = "${PN}" should work
>
> It solved the early error “ c-mlib listed in PACKAGES multiple times, this
> leads to packaging errors” — Thanks again.
>
>
> But running into other issue. Below is my do_install
>
This bbappend moves sysroot lib libpcre.so.x.x.x from /usr/lib to /lib
and symlinks /usr/lib/libpcre.so to ../../lib/libpcre.so.x.x.x, but this
causes certain recipes dependent on libpcre (like pango) to fail because
they also expect libpcre.so.1 to exist which this recipe omits to create.
(the
On 5 October 2016 at 13:58, Ioan-Adrian Ratiu wrote:
> (the reason why the lib is moved in the first place is to avoid a QA issue
> because there's a risk for /usr to be on another partition)
>
I'm not a meta-selinux maintainer but this is where I ask is there actually
a
On Wed, Oct 5, 2016 at 9:06 AM, Dinh Nguyen (dinhn) wrote:
> Many thanks Paul. Your help is greatly appreciated.
>
> 1. >>> Like the other responder I would suggest you not set PACKAGES
>
> Yes, I did not set the PACKAGES, so -dev, -dbg and main packages were built
> as shown
On Wed, Oct 5, 2016 at 7:20 AM, Nicolas Bigaouette
wrote:
> Hi all!
>
> I have an issue when trying to build two different images using conflicting
> packages.
>
> I need to package an application of mine (built using cmake) for our Yocto
> deployment. The recipe
>>> I wonder why do we want to override default PACKAGES here. If we can leave
>>> that alone things would work out on its own.
I did remove the PACKAGES setting in my .bb — so all default packages were
built. But still having some other issue as stated in other emails.
Thanks Khem.
—Dinh
On Wed, Oct 05, 2016 at 04:10:01PM +, Dinh Nguyen (dinhn) wrote:
> >>> I wonder why do we want to override default PACKAGES here. If we can
> >>> leave that alone things would work out on its own.
>
> I did remove the PACKAGES setting in my .bb — so all default packages were
> built. But
Many thanks Paul. Your help is greatly appreciated.
1. >>> Like the other responder I would suggest you not set PACKAGES
Yes, I did not set the PACKAGES, so -dev, -dbg and main packages were built as
shown below:
dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find
On Wed, Oct 05, 2016 at 04:06:25PM +, Dinh Nguyen (dinhn) wrote:
> Many thanks Paul. Your help is greatly appreciated.
>
> 1. >>> Like the other responder I would suggest you not set PACKAGES
>
> Yes, I did not set the PACKAGES, so -dev, -dbg and main packages were built
> as shown below:
>
When the host and the SDK architectures are incompatible the SDK
installer outputs an incomplete error message "Error: Installation
machine not supported!". This commit adds a more verbose error
message e.g "Error: Incompatible SDK installer! Your host is i686
and this SDK was built for x86_64
Hi all!
I have an issue when trying to build two different images using
conflicting packages.
I need to package an application of mine (built using cmake) for our
Yocto deployment. The recipe is already written and works well, except
that I now need to build two different versions of that
Using Jethro release and attempting to build either openjdk-7 or 8 fails when
fetching icedtea7-native/2.1.3-r1.0 due to checksum mismatches (on all the
SRC_URI entries).
openjdk-7 did successfully build about a month ago.
Is there a workaround, fix or other suggestions?
Thanks
--
On 09/30/2016 03:29 PM, Monserrat Sedeno wrote:
> As part of the process to set new OS distribution as supported on Yoctoc
> Project
> a new patch was created with the list of build sets that should be executed.
>
> Detailed information:
>
On Wed 2016-10-05 @ 11:01:15 AM, Jonathan Liu wrote:
> See if the following helps:
> bitbake -c cleanall core-image-minimal && bitbake core-image-minimal
Odd. I had started this email to say that this wasn't working (since this is
exactly what I had tried a couple times over the last several
I wonder why do we want to override default PACKAGES here. If we can leave
that alone things would work out on its own.
On Tue, Oct 4, 2016 at 11:55 PM, Paul Eggleton
wrote:
> On Wed, 05 Oct 2016 05:12:27 Dinh Nguyen wrote:
>> Thanks much Paul.
>>
>> PACKAGES
Thanks Khem
>> I guess its getting renamed as per debian package renaming rules. Just add
>> ALLOW_EMPTY_${PN} = "1"
I added ALLOW_EMPTY_${PN} = “1”
And encountered the same issue as specified in previous mail. For the very
first time after adding it, everything went well, including the -dev,
Hello All,
Can anyone help me out on this issue. Thanks.
Cheers,
Vijay
On Mon, Oct 3, 2016 at 6:19 PM, Vijayakumar Badiger wrote:
> Hello All,
>
> I am trying to integrate the YP Core - Krogoth 2.1.1 to the AGL Blowfish
> release. I am getting the below error when I
>> Are the files present in the image/packages? Maybe it is just the
>> bitbake cache skipping doing work it already did last time.
If I don’t do the bitbake clean, and just do bitbake again, then yes.
But if I do “bitbake -c clean c-mlib” and bitbake again, the is where the
problem.
>> Is that doing a compile in the install target?
Yes Len. Compile was done and there is no issue there.
Thanks,
—Dinh
On 10/5/16, 9:28 AM, "Lennart Sorensen" wrote:
>On Wed, Oct 05, 2016 at 04:10:01PM +, Dinh Nguyen (dinhn) wrote:
>> >>> I wonder
> On Oct 5, 2016, at 11:18 AM, Dinh Nguyen (dinhn) wrote:
>
>>> Are the files present in the image/packages? Maybe it is just the
>>> bitbake cache skipping doing work it already did last time.
>
> If I don’t do the bitbake clean, and just do bitbake again, then yes.
>
>
>
>> then it is just going to reuse the build artifacts from last builds and not
>> checkout the sources etc.
>> all those tasks will be skipped.
>> why are looking for sources in a build tree ?
Not only source under
.. yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git
But other data such
I also wonder if this actually belongs in
buildset-config.autobuilder-qa (which doesn't have any other configs),
or in buildset-config.controller where all the others reside.
-Bill
On Wed, Oct 5, 2016 at 1:00 PM, Aníbal Limón
wrote:
> Oh, I didn't notice that
On 10/05/2016 03:41 PM, Bill Randle wrote:
> I also wonder if this actually belongs in
> buildset-config.autobuilder-qa (which doesn't have any other configs),
> or in buildset-config.controller where all the others reside.
I don't know what was the original target for the autobuilder-qa
On Wed, Oct 5, 2016 at 1:47 PM, Aníbal Limón
wrote:
>
>
> On 10/05/2016 03:41 PM, Bill Randle wrote:
>> I also wonder if this actually belongs in
>> buildset-config.autobuilder-qa (which doesn't have any other configs),
>> or in buildset-config.controller where all
As part of the process to set new OS distribution as supported on Yoctoc Project
a new patch was created with the list of build sets that should be executed.
Detailed information:
https://wiki.yoctoproject.org/wiki/Distro_Testing_Plan#Execute_Build_Sets
Fixes [YOCTO #9905]
Note:In order to add
> On Oct 5, 2016, at 11:43 AM, Dinh Nguyen (dinhn) wrote:
>
>
>
>>> then it is just going to reuse the build artifacts from last builds and not
>>> checkout the sources etc.
>>> all those tasks will be skipped.
>
>>> why are looking for sources in a build tree ?
>
>
> Not
Oh, I didn't notice that this patch isn't applied to ab master branch.
Monse, could you send a new patch over master?
Cheers,
alimon
On 10/05/2016 09:59 AM, Aníbal Limón wrote:
>
>
> On 09/30/2016 03:29 PM, Monserrat Sedeno wrote:
>> As part of the process to set new OS distribution
On 10/05/2016 03:54 PM, Monserrat Sedeno wrote:
> As part of the process to set new OS distribution as supported on Yoctoc
> Project
> a new patch was created with the list of build sets that should be executed.
>
> Detailed information:
>
38 matches
Mail list logo