There would be an error when building gcc-cross in the do_install stage
if the TMPDIR's length is more than 200 characters:
make[1]: execvp: /bin/sh: Argument list too long
This is because of the limit of /usr/include/linux/limits.h:
$ grep PATH_MAX /usr/include/linux/limits.h
#define
On Apr 13, 2012 12:30 AM, Phil Blundell ph...@gnu.org wrote:
On Thu, 2012-04-12 at 17:13 -0400, Denys Dmytriyenko wrote:
Should we put it to vote? While we still have time before the release,
we need
to agree on the naming eventually.
To be honest, it seems to me like a vote would be a
On Wed, Apr 11, 2012 at 06:54:14PM +0300, Andrei Gherzan wrote:
This is done because of this change in gdbm:
gdbm: Package compat libs in gdbm-compat
Signed-off-by: Andrei Gherzan and...@gherzan.ro
---
meta/recipes-devtools/perl/perl_5.14.2.bb |2 +-
On Fri, 2012-04-13 at 14:45 +0800, Robert Yang wrote:
There would be an error when building gcc-cross in the do_install stage
if the TMPDIR's length is more than 200 characters:
make[1]: execvp: /bin/sh: Argument list too long
This is because of the limit of /usr/include/linux/limits.h:
I've done a bitbake world on Fedora 17 64bit (MACHINE = qemux86-64),
the failed pkgs are mklibs-native (have sent patch) and grub as far as
I know.
Will try bitbake core-image-sato with MACHINE = qemuarm/qemuppc/qemux86
and bitbake world with MACHINE = qemux86 on Fedora 17 64bit this
night.
Test
There was an error when build with gcc 4.7 (FC 17 64bit):
| fs/zfs/zfs.c: In function 'get_filesystem_dnode':
| fs/zfs/zfs.c:1449:7: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
..
cc1: all warnings being treated as errors
While compare
On 04/13/2012 05:41 PM, Robert Yang wrote:
I've done a bitbake world on Fedora 17 64bit (MACHINE = qemux86-64),
The MACHINE is qemux86 (not qemux86-64), sorry for the mistake.
the failed pkgs are mklibs-native (have sent patch) and grub as far as
I know.
Will try bitbake core-image-sato
On 13.04.2012 03:49, Kang Kai wrote:
On 2012年04月13日 02:47, Andreas Oberritter wrote:
Hello Kai,
because I was low on disk space, I just tried scripts/cleanup-workdir
for the first time. My observations:
Hi Andreas,
1.) It deletes work directories that were built for other machines
The following changes since commit f81b0593e74a31cb2d992df0583948ff57e3ed98:
gdbm: Activate -enable-libgdbm-compat and add symlinks to headers in
include/gdbm (2012-03-23 17:56:29 +0200)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib dcui/master
Here /usr/lib/lib*.so files are binaries rather than symbol links.
We should package them into ${PN} rather than ${PN}-dev, or else,
when a package, that rdepends on nspr, is packaged, we get a
non-dev package rdepends on nspr-dev ERROR.
Signed-off-by: Dexuan Cui dexuan@intel.com
---
V4 had some commits sent to oe-core and are not merged and forgot about
those. This led to a confict in python bb file.
The following changes since commit 6703173449ad21e1623ac75a66535cb2ed52aeeb:
package_rpm.bbclass: Set tmppath for rpm to somewhere which won't conflict
with the rootfs
In order to avoid breaking packages which depend on old package name libgdbm4
(= 1.10),
compat libs are packaged into a separate package named gdbm-compat.
Signed-off-by: Andrei Gherzan and...@gherzan.ro
---
meta/recipes-support/gdbm/gdbm_1.10.bb |7 ++-
1 files changed, 6
This is done because of this change in gdbm:
gdbm: Package compat libs in gdbm-compat
Signed-off-by: Andrei Gherzan and...@gherzan.ro
---
meta/recipes-devtools/perl/perl_5.14.2.bb |2 +-
meta/recipes-devtools/python/python_2.7.2.bb |2 +-
.../pulseaudio/pulseaudio_1.1.bb
On Fri, Apr 13, 2012 at 11:03, Martin Jansa martin.ja...@gmail.com wrote:
On Wed, Apr 11, 2012 at 06:54:14PM +0300, Andrei Gherzan wrote:
This is done because of this change in gdbm:
gdbm: Package compat libs in gdbm-compat
Signed-off-by: Andrei Gherzan and...@gherzan.ro
---
On Thu, Apr 12, 2012 at 21:46, Philip Balister phi...@balister.org wrote:
On 04/12/2012 11:40 AM, Richard Purdie wrote:
On Thu, 2012-04-12 at 14:32 -0300, Otavio Salvador wrote:
On Thu, Apr 12, 2012 at 14:22, Koen Kooi k...@dominion.thruhere.net wrote:
You just volunteered to handle all the
On Thu, 2012-04-12 at 22:00 +0800, Robert Yang wrote:
Is there any suggestions for this one please?
This is a change suitable for post 1.2 so it needs to wait until after
release.
Cheers,
Richard
___
Openembedded-core mailing list
perl package do_configure is changing /perl-5.14.2/patches/h2ph-multiarch.diff
from link to normal file in the process of correcting the paths.
So when patch task is re-executed after complete package building, giving error.
This path correction is not required for links as the link target file
After building boost package, re-execution of boostconfig task followed by
re-execution of compile task is giving following error
error: duplicate initialization of gcc with the following parameters during
compilation
It is because multiple entries of gcc are being added during boostconfig
Task do_patch_append calling do_fix_ia_headers is removing files using rm not
rm -f.
So first time execution of patch task is success, while re-execution of patch
task
fails as it tries to remove the files already removed.
So changed rm to rm -f.
[Yocto #2194]
Signed-off-by: Venkata Ramana
If the toolchain is reused from sstate and ccache is installed, build failures
were occuring due to gcc trying to access the original sysroot rather than the
new one, particularly if the old sysroot existed but was not readable by the
current user.
This turns out of the an issue inside gcc to do
On Fri, Apr 13, 2012 at 01:34:18PM +0300, Andrei Gherzan wrote:
In order to avoid breaking packages which depend on old package name libgdbm4
(= 1.10),
compat libs are packaged into a separate package named gdbm-compat.
Signed-off-by: Andrei Gherzan and...@gherzan.ro
Acked-by: Martin Jansa
On Fri, Apr 13, 2012 at 01:34:19PM +0300, Andrei Gherzan wrote:
This is done because of this change in gdbm:
gdbm: Package compat libs in gdbm-compat
Signed-off-by: Andrei Gherzan and...@gherzan.ro
Acked-by: Martin Jansa martin.ja...@gmail.com
---
If this value is not set to 1, then systems with some 32-bit libraries
but no 32-bit version of libgcc installed will have pseudo-native fail
at do_compile. It should only really be set to 0 by those who know what
they are doing.
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
The ??= assignment in pseudo.inc effectively nullifies this ??=
assignment here, so remove it.
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
meta/conf/distro/include/default-distrovars.inc |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git
On Thu, Apr 12, 2012 at 02:04:18PM +0100, Richard Purdie wrote:
This patch fixes up the issues that were being seen where BBCLASSEXTEND and
PACKAGECONFIG were interacting badly. It also ensures PACKAGECONFIG interacts
properly with multilib builds.
Ideally some of this code will be
If the toolchain is reused from sstate and ccache is installed, build failures
were occuring due to gcc trying to access the original sysroot rather than the
new one, particularly if the old sysroot existed but was not readable by the
current user.
This turns out of the an issue inside gcc to do
On 04/13/2012 05:35 AM, Paul Eggleton wrote:
If this value is not set to 1, then systems with some 32-bit libraries
but no 32-bit version of libgcc installed will have pseudo-native fail
at do_compile. It should only really be set to 0 by those who know what
they are doing.
Signed-off-by: Paul
On 04/13/2012 05:40 AM, Paul Eggleton wrote:
The ??= assignment in pseudo.inc effectively nullifies this ??=
assignment here, so remove it.
Signed-off-by: Paul Eggletonpaul.eggle...@linux.intel.com
---
meta/conf/distro/include/default-distrovars.inc |2 --
1 files changed, 0
On 04/12/2012 02:21 PM, Mark Hatle wrote:
pseudo was adding in an rpath, prevent that
rpm-native was not resolving dependencies that looked like possible
filename properly.
The following changes since commit 71e95c744eaa4dda1b3237db2e13f666f121c92b:
package_rpm.bbclass: Set tmppath for
On 04/12/2012 02:21 PM, Mark Hatle wrote:
[Yocto #2251]
Add --without-rpath to avoid embedding rpaths into the pseudo
components.
Signed-off-by: Mark Hatlemark.ha...@windriver.com
---
meta/recipes-devtools/pseudo/pseudo.inc|8
meta/recipes-devtools/pseudo/pseudo_1.3.bb |
On 4/13/12 10:13 AM, Saul Wold wrote:
On 04/12/2012 02:21 PM, Mark Hatle wrote:
[Yocto #2251]
Add --without-rpath to avoid embedding rpaths into the pseudo
components.
Signed-off-by: Mark Hatlemark.ha...@windriver.com
---
meta/recipes-devtools/pseudo/pseudo.inc|8
---
a/meta/recipes-devtools/perl/perl_5.14.2.bb
+++
b/meta/recipes-devtools/perl/perl_5.14.2.bb
@@ -164,8 +164,12 @@
do_configure() {
esac
# These are strewn all over the source
tree
for foo in `grep -I -m1 \/usr\/include\/.*\\.h ${WORKDIR}/*
-r | cut -f 1 -d :`
On Fri, 2012-04-13 at 10:22 -0500, Mark Hatle wrote:
We might still need this rpath or something similar since the nativesdk
now breaks not finding the correct version of the included libc.so.6
In this case, I don't think embedding a static RPATH makes sense, but perhaps
a
$ORIGIN path
On 4/13/12 10:33 AM, Richard Purdie wrote:
On Fri, 2012-04-13 at 10:22 -0500, Mark Hatle wrote:
We might still need this rpath or something similar since the nativesdk
now breaks not finding the correct version of the included libc.so.6
In this case, I don't think embedding a static RPATH
On Fri, 2012-04-13 at 10:40 -0500, Mark Hatle wrote:
On 4/13/12 10:33 AM, Richard Purdie wrote:
On Fri, 2012-04-13 at 10:22 -0500, Mark Hatle wrote:
We might still need this rpath or something similar since the nativesdk
now breaks not finding the correct version of the included libc.so.6
On Fri, Apr 13, 2012 at 4:46 AM, Venkata ramana gollamudi
ramana.gollam...@huawei.com wrote:
+ # D2194:Fixing the issue patch file link is replaced with
modified file
+ # Ignore if file is a link, as actual file will also get
caught during grep
That comment
On Fri, Apr 13, 2012 at 4:42 AM, Venkata ramana gollamudi
ramana.gollam...@huawei.com wrote:
+ # D2194:Fixing the failure of error: duplicate initialization of gcc
with the following parameters during compilation.
same here.
___
On Fri, Apr 13, 2012 at 6:13 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
If the toolchain is reused from sstate and ccache is installed, build failures
were occuring due to gcc trying to access the original sysroot rather than the
new one, particularly if the old sysroot
FYI this will impact us in coming time. If someone has questions
please bring it up
-- Forwarded message --
From: Steve McIntyre steve.mcint...@linaro.org
Date: Fri, Apr 13, 2012 at 10:37 AM
Subject: ARM hard-float linker path - consensus
To: cross-dis...@lists.linaro.org
Cc:
On Fri, Apr 13, 2012 at 11:11:02AM -0700, Khem Raj wrote:
FYI this will impact us in coming time. If someone has questions
please bring it up
While it's a slightly unexpected outcome (/lib/ld-linux-armhf.so.3) it's still
good to see some agreement here.
Do we want to make the necessary
From: Tom Zanussi tom.zanu...@intel.com
This patchset fixes a documentation build problem with docproc, then
turns documentation generation off by default, since when it works,
it adds a lot to the build time.
The following changes since commit 04b16f1038f7cae445d741e86c2cc19c70f991c1:
Andrei
From: Tom Zanussi tom.zanu...@intel.com
When building docs in systemtap, docproc is used to generate the
tapset documentation, but it gets built for the target, while it needs
to be build for the host instead. This change causes that to happen.
Fixes [YOCTO #2193].
Signed-off-by: Tom Zanussi
From: Tom Zanussi tom.zanu...@intel.com
Building the systemtap documentation adds significantly to the build
time, so disable it by default.
Signed-off-by: Tom Zanussi tom.zanu...@intel.com
---
meta/recipes-kernel/systemtap/systemtap_git.bb |4
1 files changed, 4 insertions(+), 0
On Fri, Apr 13, 2012 at 12:50 PM, Denys Dmytriyenko de...@denix.org wrote:
On Fri, Apr 13, 2012 at 11:11:02AM -0700, Khem Raj wrote:
FYI this will impact us in coming time. If someone has questions
please bring it up
While it's a slightly unexpected outcome (/lib/ld-linux-armhf.so.3) it's
On Fri, Apr 13, 2012 at 2:41 AM, Robert Yang liezhi.y...@windriver.com wrote:
There was an error when build with gcc 4.7 (FC 17 64bit):
| fs/zfs/zfs.c: In function 'get_filesystem_dnode':
| fs/zfs/zfs.c:1449:7: error: dereferencing type-punned pointer will break
strict-aliasing rules
Updating the 3.2 recipe SRCREVs to pickup the following meta change:
[
meta: Add igb.scc to Romley
Romley machine has 82580 Giga bit Ethernet Controller.
Add the relavent Nic driver to it.
Signed-off-by: Kishore Bodke kishore.k.bo...@intel.com
]
Signed-off-by: Bruce Ashfield
Richard/Saul,
Here are two last commits for linux-yocto. One is a pending
SRCREV update for the romley. It's included to make sure that the
meta branch head matches the SRCREVs. Otherwise, we are relying
on branch renaming for everyone. There's no risk, and this is already
in use by the BSP
During testing/extension of the linux-yocto-tiny kernel it was found that
defconfigs were not always properly applied. This was due to two issues:
- not being able to fully control the order of objects applied to the
git tree on the SRC_URI
- defconfigs triggering --allnoconfig before
I suspect this would effect 1.1.2.
-M
On Fri, Apr 13, 2012 at 8:13 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
If the toolchain is reused from sstate and ccache is installed, build failures
were occuring due to gcc trying to access the original sysroot rather than the
new
On 04/13/2012 01:55 PM, Bruce Ashfield wrote:
Richard/Saul,
Here are two last commits for linux-yocto. One is a pending
SRCREV update for the romley. It's included to make sure that the
meta branch head matches the SRCREVs. Otherwise, we are relying
on branch renaming for everyone. There's no
On 04/11/2012 07:26 AM, Andrei Gherzan wrote:
The bug is that the native python used to run genpkgmetadata.py is picking up
host's python modules.
More about this. RPM is built without python. And this modules is needed by the
above py file.
So:
1. rpm-native should be built with python
On 04/13/2012 03:33 AM, Andrei Gherzan wrote:
V4 had some commits sent to oe-core and are not merged and forgot about
those. This led to a confict in python bb file.
The following changes since commit 6703173449ad21e1623ac75a66535cb2ed52aeeb:
package_rpm.bbclass: Set tmppath for rpm to
On 04/13/2012 04:44 AM, Venkata ramana gollamudi wrote:
Task do_patch_append calling do_fix_ia_headers is removing files using rm not rm
-f.
So first time execution of patch task is success, while re-execution of patch
task
fails as it tries to remove the files already removed.
So changed rm
On 04/13/2012 04:42 AM, Venkata ramana gollamudi wrote:
After building boost package, re-execution of boostconfig task followed by
re-execution of compile task is giving following error
error: duplicate initialization of gcc with the following parameters during
compilation
It is because
On 04/12/2012 06:43 AM, Robert Yang wrote:
Test info:
Has been tested on:
Fedora 17 64bit
Fedora 16 64bit
Ubuntu 10.10 32bit
// Robert
The following changes since commit c37faea947ef3980934c02661ecd79cd9668b8a6:
libunistring: Fix parallel make issue (2012-04-12 12:37:52 +0100)
are
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Khem Raj
Sent: Friday, April 13, 2012 1:21 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 1/1]
On 04/13/2012 03:04 AM, Dexuan Cui wrote:
Here /usr/lib/lib*.so files are binaries rather than symbol links.
We should package them into ${PN} rather than ${PN}-dev, or else,
when a package, that rdepends on nspr, is packaged, we get a
non-dev package rdepends on nspr-dev ERROR.
Applied and
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Kamble, Nitin A
Sent: Friday, April 13, 2012 4:43 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Khem Raj
Sent: Friday, April 13, 2012 8:20 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 1/1]
From: Nitin A Kamble nitin.a.kam...@intel.com
The eglibc fix is done differently now.
grub recipe is fixed to use the gcc-cross compiler
grub grub-efi-native recipes are fixed for gcc4.7 compiler
more details in the commit messages.
Nitin
The following changes since commit
From: Nitin A Kamble nitin.a.kam...@intel.com
It was using distro gcc to build binaries for target. This got detected
on fedora 17 alpha, on which it hit an gcc-4.7 issue.
This Fixes Bug: [Yocto #2291]
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
From: Nitin A Kamble nitin.a.kam...@intel.com
This fixes bug [YOCTO #2293]
These build failure caused by gcc4.7 is fixed with a backport of a
grub-1.99 patch from fedora 17 alpha plus two more new patches
| gcc -DHAVE_CONFIG_H -I. -I.. -Wall -W -I../include -I../include
-DGRUB_MACHINE_EFI=1
From: Nitin A Kamble nitin.a.kam...@intel.com
Generally distros keep perl at /sur/bin/perl
Fedora 17 alpha also has /bin/perl
this causes eglibc build on such distros to put perl interpreter path in
the perl scripts as /bin/perl
But we set perl location for target as /usr/bin/perl
This
63 matches
Mail list logo
