[OE-core] [PATCH 2/3] grub-efi-native, grub: fix build with gcc 4.7
From: Nitin A Kamble 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 -DGRUB_MACHINE=I386_EFI -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.7.0/include -DGRUB_FILE=\"commands/efi/acpi.c\" -I. -I. -I.. -I.. -I../include -I../include -isystem/home/nitin/builds/build0/tmp/sysroots/x86_64-linux/usr/include -O2 -pipe -g -feliminate-unused-debug-types -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes -Wundef -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-dwarf2-cfi-asm -m32 -fno-stack-protector -mno-stack-arg-probe -Werror -Wno-trampolines -ffreestanding -isystem/home/nitin/builds/build0/tmp/sysroots/x86_64-linux/usr/include -O2 -pipe -c -o commands/efi/acpi_module-acpi.o `test -f 'commands/efi/acpi.c' || echo './'`commands/efi/acpi.c | gcc: error: unrecognized command line option '-melf_i386' | make[3]: *** [trig.module] Error 1 | make[3]: Entering directory `/home/nitin/builds/build0/tmp/work/x86_64-linux/grub-efi-i586-native-1.99-r7/grub-1.99/grub-core' | gcc -DHAVE_CONFIG_H -I. -I.. -Wall -W -I../include -I../include -DGRUB_MACHINE_EFI=1 -DGRUB_MACHINE=I386_EFI -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.7.0/include -DGRUB_FILE=\"fs/btrfs.c\" -I. -I. -I.. -I.. -I../include -I../include -isystem/home/nitin/builds/build0/tmp/sysroots/x86_64-linux/usr/include -O2 -pipe -g -feliminate-unused-debug-types -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes -Wundef -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-dwarf2-cfi-asm -m32 -fno-stack-protector -mno-stack-arg-probe -Werror -Wno-trampolines -ffreestanding -isystem/home/nitin/builds/build0/tmp/sysroots/x86_64-linux/usr/include -O2 -pipe -c -o fs/btrfs_module-btrfs.o `test -f 'fs/btrfs.c' || echo './'`fs/btrfs.c | fs/btrfs.c: In function 'grub_btrfs_read_logical': | fs/btrfs.c:791:5: error: 'err' may be used uninitialized in this function [-Werror=maybe-uninitialized] | fs/btrfs.c:592:18: note: 'err' was declared here | cc1: all warnings being treated as errors | make[3]: *** [fs/btrfs_module-btrfs.o] Error 1 | gcc -DHAVE_CONFIG_H -I. -I.. -Wall -W -I../include -I../include -DGRUB_MACHINE_EFI=1 -DGRUB_MACHINE=I386_EFI -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.7.0/include -DGRUB_FILE=\"fs/zfs/zfs.c\" -I. -I. -I.. -I.. -I../include -I../include -isystem/home/nitin/builds/build0/tmp/sysroots/x86_64-linux/usr/include -O2 -pipe -g -feliminate-unused-debug-types -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes -Wundef -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-dwarf2-cfi-asm -m32 -fno-stack-protector -mno-stack-arg-probe -Werror -Wno-trampolines -ffreestanding -isystem/home/nitin/builds/build0/tmp/sysroots/x86_64-linux/usr/include -O2 -pipe -c -o fs/zfs/zfs_module-zfs.o `test -f 'fs/zfs/zfs.c' || echo './'`fs/zfs/zfs.c | 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] | fs/zfs/zfs.c:1449:7: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] | fs/zfs/zfs.c: In function 'make_mdn': | fs/zfs/zfs.c:1478:3: error: dereferencing type-punned pointer will break strict-alERROR: Function failed: do_compile (see /home/nitin/builds/build0/tmp/work/x86_64-linux/grub-efi-i586-native-1.99-r7/temp/log.do_compile.9293 for further information) | iasing rules [-Werror=strict-aliasing] | fs/zfs/zfs.c: In function 'dnode_get_fullpath': | fs/zfs/zfs.c:1554:3: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] | fs/zfs/zfs.c:1554:3: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] | fs/zfs/zfs.c:1571:7: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] | fs/zfs/zfs.c:1571:7: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] | fs/zfs/zfs.c: In function 'grub_zfs_open': | fs/zfs/zfs.c:2234:7: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] | fs/zfs/zfs.c:2234:7: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] | fs/zfs/zfs.c: In function 'fill_fs_info': | fs/zfs/zfs.c:2362:7: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] | fs/zfs/zfs.c:2362:7: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] | fs/zfs/zfs.c:2395:3: error: dereferencin
[OE-core] [PATCH 3/3] eglibc: fix builds on fedora 17 alpha
From: Nitin A Kamble
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 mismatch of perl path causes failure of rootfs image creation
like this:
| error: Failed dependencies:
| /bin/perl is needed by eglibc-utils-2.13-r23+svnr15508.i586
NOTE: package core-image-sato-1.0-r0: task do_rootfs: Failed
ERROR: Task 8
(/home/nitin/prj/poky.git/meta/recipes-sato/images/core-image-sato.bb,
do_rootfs) failed with exit code '1'
This Fixes bug : [YOCTO #2286]
Signed-off-by: Nitin A Kamble
---
meta/recipes-core/eglibc/eglibc-package.inc |5 +
meta/recipes-core/eglibc/eglibc_2.13.bb |2 +-
meta/recipes-core/eglibc/eglibc_2.15.bb |2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index 9e45fc1..d13cb35 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -76,6 +76,11 @@ do_install_append () {
rm -f ${D}${sysconfdir}/localtime
oe_multilib_header bits/syscall.h
+
+ if [ -f ${D}${bindir}/mtrace ]
+ then
+ sed -e "s# /bin/perl# ${bindir}/perl#" -i ${D}${bindir}/mtrace
+ fi
}
do_install_locale () {
diff --git a/meta/recipes-core/eglibc/eglibc_2.13.bb
b/meta/recipes-core/eglibc/eglibc_2.13.bb
index ec06261..d8a41dc 100644
--- a/meta/recipes-core/eglibc/eglibc_2.13.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.13.bb
@@ -3,7 +3,7 @@ require eglibc.inc
SRCREV = "15508"
DEPENDS += "gperf-native"
-PR = "r25"
+PR = "r26"
PR_append = "+svnr${SRCPV}"
EGLIBC_BRANCH="eglibc-2_13"
diff --git a/meta/recipes-core/eglibc/eglibc_2.15.bb
b/meta/recipes-core/eglibc/eglibc_2.15.bb
index caed9e9..713efc3 100644
--- a/meta/recipes-core/eglibc/eglibc_2.15.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.15.bb
@@ -3,7 +3,7 @@ require eglibc.inc
SRCREV = "17386"
DEPENDS += "gperf-native"
-PR = "r5"
+PR = "r6"
PR_append = "+svnr${SRCPV}"
EGLIBC_BRANCH="eglibc-2_15"
--
1.7.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] misc critical bugfixes for fedora 17 alpha
From: Nitin A Kamble 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 ee71422b9893f9f77173fb2612d1ffbbc68643c3: linux-yocto: allow .cfg, .scc, .patch and defconfigs to be processed in order (2012-04-13 22:44:46 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib nitin/bugfixes http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/bugfixes Nitin A Kamble (3): grub-1.99: use gcc-cross for building the target binaries grub-efi-native, grub: fix build with gcc 4.7 eglibc: fix builds on fedora 17 alpha ...rub-1.99-gcc-4.7.0-strict-aliasing-errors.patch | 147 ...b-1.99-gcc-4.7.0-uninitialized-var-errors.patch | 41 ++ .../grub/files/grub-1.99-gcc-4.7.0.patch | 34 + meta/recipes-bsp/grub/grub-efi-native_1.99.bb |8 +- meta/recipes-bsp/grub/grub_1.99.bb |7 +- meta/recipes-core/eglibc/eglibc-package.inc|5 + meta/recipes-core/eglibc/eglibc_2.13.bb|2 +- meta/recipes-core/eglibc/eglibc_2.15.bb|2 +- 8 files changed, 241 insertions(+), 5 deletions(-) create mode 100644 meta/recipes-bsp/grub/files/grub-1.99-gcc-4.7.0-strict-aliasing-errors.patch create mode 100644 meta/recipes-bsp/grub/files/grub-1.99-gcc-4.7.0-uninitialized-var-errors.patch create mode 100644 meta/recipes-bsp/grub/files/grub-1.99-gcc-4.7.0.patch -- 1.7.7 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] grub-1.99: use gcc-cross for building the target binaries
From: Nitin A Kamble
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
---
meta/recipes-bsp/grub/grub_1.99.bb |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-bsp/grub/grub_1.99.bb
b/meta/recipes-bsp/grub/grub_1.99.bb
index ac66e83..07ee667 100644
--- a/meta/recipes-bsp/grub/grub_1.99.bb
+++ b/meta/recipes-bsp/grub/grub_1.99.bb
@@ -12,7 +12,7 @@ LICENSE = "GPLv3"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
RDEPENDS_${PN} = "diffutils freetype"
-PR = "r3"
+PR = "r4"
SRC_URI = "ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
file://grub-install.in.patch \
@@ -26,6 +26,8 @@ COMPATIBLE_HOST = '(x86_64.*|i.86.*)-(linux|freebsd.*)'
inherit autotools
inherit gettext
+CACHED_CONFIGUREVARS = "ac_cv_prog_ac_ct_TARGET_CC='${CC}'
ac_cv_prog_ac_ct_HOST_CC='${CC}' ac_cv_prog_ac_ct_BUILD_CC='${BUILD_CC}'"
+
EXTRA_OECONF = "--with-platform=pc --disable-grub-mkfont
--target=${TARGET_ARCH} --program-prefix="""
do_configure() {
--
1.7.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] grub 1.99: fix build for gcc 4.7
> -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] grub 1.99: fix build for gcc 4.7 > > On Fri, Apr 13, 2012 at 4:43 PM, Kamble, Nitin A > wrote: > > > > > >> -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] grub 1.99: fix build for gcc 4.7 > >> > >> On Fri, Apr 13, 2012 at 2:41 AM, Robert Yang > >> 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 [-Werror=strict-aliasing] > >> > .. > >> > cc1: all warnings being treated as errors > >> > > >> > While compare the compile command between gcc 4.4.4 and gcc 4.7.0, > >> > they are the same (both of them have -Wall and -Werror), it seems > >> that > >> > gcc > >> > 4.7.0 has changed its algorithm for the strict aliasing check, but > >> > I didn't find the related information from its release note. > >> > > >> > Add "-fno-strict-aliasing" to gcc's option would fix the problem, > >> this > >> > would disable the optimization for strict-aliasing. > >> > >> This seems a bit more than whats needed. You could try adding -Wno- > >> error=strict-aliasing to CFLAGS > >> > >> on another note. I do not see this failing with gcc-4.7(target > >> compiler) here when I build grub for qemux86 so I am a bit puzzled > >> > > > > > > Khem, > > There is another grub recipe issue, it is building target binaries > with distro compiler. Probably because of that you did not see issue > with 4.7 cross compiler. We have fix for that issue now. > > hmmm interesting that clarifies. So I guess once you fix it to do > _proper_ cross compile build then I guess the problem gets fixed when > we use gcc 4.6 but as soon as we move to gcc-4.7 this will reappear so > in any case this issue needs to fixed in a good manner I think in > anycase. > The 2293 bug is about grub-efi-native which correctly uses the distro compiler. And it hits gcc 4.7 issue on fedora 17 alpha, and that is also fixed. I will send out commits in few mins. Nitin > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] grub 1.99: fix build for gcc 4.7
On Fri, Apr 13, 2012 at 4:43 PM, Kamble, Nitin A wrote: > > >> -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] grub 1.99: fix build for gcc 4.7 >> >> On Fri, Apr 13, 2012 at 2:41 AM, Robert Yang >> 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 [-Werror=strict-aliasing] >> > .. >> > cc1: all warnings being treated as errors >> > >> > While compare the compile command between gcc 4.4.4 and gcc 4.7.0, >> > they are the same (both of them have -Wall and -Werror), it seems >> that >> > gcc >> > 4.7.0 has changed its algorithm for the strict aliasing check, but I >> > didn't find the related information from its release note. >> > >> > Add "-fno-strict-aliasing" to gcc's option would fix the problem, >> this >> > would disable the optimization for strict-aliasing. >> >> This seems a bit more than whats needed. You could try adding -Wno- >> error=strict-aliasing to CFLAGS >> >> on another note. I do not see this failing with gcc-4.7(target >> compiler) here when I build grub for qemux86 so I am a bit puzzled >> > > > Khem, > There is another grub recipe issue, it is building target binaries with > distro compiler. Probably because of that you did not see issue with 4.7 > cross compiler. We have fix for that issue now. hmmm interesting that clarifies. So I guess once you fix it to do _proper_ cross compile build then I guess the problem gets fixed when we use gcc 4.6 but as soon as we move to gcc-4.7 this will reappear so in any case this issue needs to fixed in a good manner I think in anycase. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] boost: fix re-execution of task
On Fri, Apr 13, 2012 at 3:23 PM, Saul Wold wrote:
> 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 multiple entries of gcc are being added during boostconfig
>> re-execution
>> there by failing the compilation.
>>
>> The patch fixes adding multiple "Using gcc" entries into
>> /tools/build/v2/user-config.jam
>>
>> [Yocto #2194]
>>
>> Signed-off-by: Venkata Ramana Gollamudi
>> ---
>> meta/recipes-support/boost/boost.inc | 6 +-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/meta/recipes-support/boost/boost.inc
>> b/meta/recipes-support/boost/boost.inc
>> index d70a7e2..c9306df 100644
>> --- a/meta/recipes-support/boost/boost.inc
>> +++ b/meta/recipes-support/boost/boost.inc
>> @@ -135,7 +135,11 @@ BJAM_OPTS = '${BJAM_TOOLS} \
>> do_boostconfig() {
>> cp -f boost/config/platform/linux.hpp
>> boost/config/platform/linux-gnueabi.hpp
>>
>> - echo 'using gcc : 4.3.1 : ${CXX} : compileflags
>> -DBOOST_SP_USE_PTHREADS -I${includedir} linkflags -L${libdir} ;'>>
>> ${S}/tools/build/v2/user-config.jam
>> + # D2194:Fixing the failure of "error: duplicate initialization of
>> gcc with the following parameters" during compilation.
>> + if ! grep -qe "^using gcc : 4.3.1"
>> ${S}/tools/build/v2/user-config.jam
>> + then
>> + echo 'using gcc : 4.3.1 : ${CXX} : compileflags
>> -DBOOST_SP_USE_PTHREADS -I${includedir} linkflags -L${libdir} ;'>>
>> ${S}/tools/build/v2/user-config.jam
>> + fi
>> }
>>
>> addtask do_boostconfig after do_patch before do_configure
>
>
> Merged into OE-Core
I had some feedback on this patch series. I wonder if it was so meaningless.
>
> Thanks
> Sau!
>
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] grub 1.99: fix build for gcc 4.7
> -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 1/1] grub 1.99: fix build for gcc 4.7
>
>
>
> > -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] grub 1.99: fix build for gcc 4.7
> >
> > On Fri, Apr 13, 2012 at 2:41 AM, Robert Yang
> > 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 [-Werror=strict-aliasing]
> > > ..
> > > cc1: all warnings being treated as errors
> > >
> > > While compare the compile command between gcc 4.4.4 and gcc 4.7.0,
> > > they are the same (both of them have -Wall and -Werror), it seems
> > that
> > > gcc
> > > 4.7.0 has changed its algorithm for the strict aliasing check, but
> I
> > > didn't find the related information from its release note.
> > >
> > > Add "-fno-strict-aliasing" to gcc's option would fix the problem,
> > this
> > > would disable the optimization for strict-aliasing.
> >
> > This seems a bit more than whats needed. You could try adding -Wno-
> > error=strict-aliasing to CFLAGS
> >
> > on another note. I do not see this failing with gcc-4.7(target
> > compiler) here when I build grub for qemux86 so I am a bit puzzled
> >
>
>
> Khem,
> There is another grub recipe issue, it is building target binaries
> with distro compiler. Probably because of that you did not see issue
> with 4.7 cross compiler. We have fix for that issue now.
>
> Nitin
>
Khem, Look at these:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2291
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2293
And both have been fixed.
Nitin
>
>
> > >
> > > [YOCTO #2291]
> > >
> > > Signed-off-by: Robert Yang
> > > ---
> > > meta/recipes-bsp/grub/grub_1.99.bb | 7 ++-
> > > 1 files changed, 6 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/meta/recipes-bsp/grub/grub_1.99.bb
> > > b/meta/recipes-bsp/grub/grub_1.99.bb
> > > index ac66e83..f45b634 100644
> > > --- a/meta/recipes-bsp/grub/grub_1.99.bb
> > > +++ b/meta/recipes-bsp/grub/grub_1.99.bb
> > > @@ -12,7 +12,7 @@ LICENSE = "GPLv3"
> > > LIC_FILES_CHKSUM =
> > "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
> > >
> > > RDEPENDS_${PN} = "diffutils freetype"
> > > -PR = "r3"
> > > +PR = "r4"
> > >
> > > SRC_URI = "ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
> > > file://grub-install.in.patch \ @@ -29,6 +29,11 @@ inherit
> > > gettext
> > > EXTRA_OECONF = "--with-platform=pc --disable-grub-mkfont --
> > target=${TARGET_ARCH} --program-prefix="""
> > >
> > > do_configure() {
> > > + # Fix build error for gcc 4.7
> > > + echo "CPPFLAGS_DEFAULT += -fno-strict-aliasing" >>
> > > + conf/Makefile.common
> > > + # Also modify Makefile.in, we can remove this when we can run
> > > + autoreconf
> > > + sed -i 's/^CPPFLAGS_DEFAULT = \(.*\)/CPPFLAGS_DEFAULT =
> > > + -fno-strict-aliasing \1/' \
> > > + Makefile.in grub-core/Makefile.in
> > > oe_runconf
> > > }
> > >
> > > --
> > > 1.7.1
> > >
> > >
> > > ___
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> cor
> > > e
> >
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] nspr: fix package spliting
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 built for qemux86. Had to bump PR to "r4" to increase past
another applied change.
> Signed-off-by: Dexuan Cui
Tested-by: Darren Hart
> ---
> meta/recipes-support/nspr/nspr_4.8.9.bb |7 ---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-support/nspr/nspr_4.8.9.bb
> b/meta/recipes-support/nspr/nspr_4.8.9.bb
> index 8b840d9..d3c683c 100644
> --- a/meta/recipes-support/nspr/nspr_4.8.9.bb
> +++ b/meta/recipes-support/nspr/nspr_4.8.9.bb
> @@ -5,7 +5,7 @@ LIC_FILES_CHKSUM =
> "file://configure.in;beginline=3;endline=40;md5=99d4d7d68bbc4
>
> file://Makefile.in;beginline=4;endline=38;md5=c2b512182a334e1bfa1edc4d1c84a298
> "
> SECTION = "libs/network"
>
> -PR = "r2"
> +PR = "r3"
>
> SRC_URI =
> "ftp://ftp.mozilla.org/pub/mozilla.org/nspr/releases/v${PV}/src/nspr-${PV}.tar.gz
> \
> file://remove-rpath-from-tests.patch \
> @@ -160,6 +160,7 @@ do_install_append() {
> install -m 0755 ${TESTS} ${D}${libdir}/nspr/tests
> }
>
> -FILES_${PN} = "${bindir}/*"
> -FILES_${PN}-dev += "${libdir}/nspr/tests/*"
> +FILES_${PN} = "${bindir}/* ${libdir}/lib*.so"
> +FILES_${PN}-dev = "${libdir}/nspr/tests/* ${libdir}/pkgconfig \
> +${includedir}/* ${datadir}/aclocal/* "
> FILES_${PN}-dbg += "${libdir}/nspr/tests/.debug/*"
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] grub 1.99: fix build for gcc 4.7
> -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] grub 1.99: fix build for gcc 4.7
>
> On Fri, Apr 13, 2012 at 2:41 AM, Robert Yang
> 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 [-Werror=strict-aliasing]
> > ..
> > cc1: all warnings being treated as errors
> >
> > While compare the compile command between gcc 4.4.4 and gcc 4.7.0,
> > they are the same (both of them have -Wall and -Werror), it seems
> that
> > gcc
> > 4.7.0 has changed its algorithm for the strict aliasing check, but I
> > didn't find the related information from its release note.
> >
> > Add "-fno-strict-aliasing" to gcc's option would fix the problem,
> this
> > would disable the optimization for strict-aliasing.
>
> This seems a bit more than whats needed. You could try adding -Wno-
> error=strict-aliasing to CFLAGS
>
> on another note. I do not see this failing with gcc-4.7(target
> compiler) here when I build grub for qemux86 so I am a bit puzzled
>
Khem,
There is another grub recipe issue, it is building target binaries with
distro compiler. Probably because of that you did not see issue with 4.7 cross
compiler. We have fix for that issue now.
Nitin
> >
> > [YOCTO #2291]
> >
> > Signed-off-by: Robert Yang
> > ---
> > meta/recipes-bsp/grub/grub_1.99.bb | 7 ++-
> > 1 files changed, 6 insertions(+), 1 deletions(-)
> >
> > diff --git a/meta/recipes-bsp/grub/grub_1.99.bb
> > b/meta/recipes-bsp/grub/grub_1.99.bb
> > index ac66e83..f45b634 100644
> > --- a/meta/recipes-bsp/grub/grub_1.99.bb
> > +++ b/meta/recipes-bsp/grub/grub_1.99.bb
> > @@ -12,7 +12,7 @@ LICENSE = "GPLv3"
> > LIC_FILES_CHKSUM =
> "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
> >
> > RDEPENDS_${PN} = "diffutils freetype"
> > -PR = "r3"
> > +PR = "r4"
> >
> > SRC_URI = "ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
> > file://grub-install.in.patch \ @@ -29,6 +29,11 @@ inherit
> > gettext
> > EXTRA_OECONF = "--with-platform=pc --disable-grub-mkfont --
> target=${TARGET_ARCH} --program-prefix="""
> >
> > do_configure() {
> > + # Fix build error for gcc 4.7
> > + echo "CPPFLAGS_DEFAULT += -fno-strict-aliasing" >>
> > + conf/Makefile.common
> > + # Also modify Makefile.in, we can remove this when we can run
> > + autoreconf
> > + sed -i 's/^CPPFLAGS_DEFAULT = \(.*\)/CPPFLAGS_DEFAULT =
> > + -fno-strict-aliasing \1/' \
> > + Makefile.in grub-core/Makefile.in
> > oe_runconf
> > }
> >
> > --
> > 1.7.1
> >
> >
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] mklibs-native 0.1.33: include unistd.h to fix build for gcc 4.7
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 available in the git repository at: git://git.pokylinux.org/poky-contrib robert/mklibs http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/mklibs Robert Yang (1): mklibs-native 0.1.33: include unistd.h to fix build for gcc 4.7 .../mklibs/files/include-unistd.h-for-gcc47.patch | 29 .../mklibs/mklibs-native_0.1.33.bb |3 +- 2 files changed, 31 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-devtools/mklibs/files/include-unistd.h-for-gcc47.patch ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core Merged with Updated Patch Header as it's a back port Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] boost: fix re-execution of task
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 multiple entries of gcc are being added during boostconfig
re-execution
there by failing the compilation.
The patch fixes adding multiple "Using gcc" entries into
/tools/build/v2/user-config.jam
[Yocto #2194]
Signed-off-by: Venkata Ramana Gollamudi
---
meta/recipes-support/boost/boost.inc |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-support/boost/boost.inc
b/meta/recipes-support/boost/boost.inc
index d70a7e2..c9306df 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -135,7 +135,11 @@ BJAM_OPTS= '${BJAM_TOOLS} \
do_boostconfig() {
cp -f boost/config/platform/linux.hpp
boost/config/platform/linux-gnueabi.hpp
- echo 'using gcc : 4.3.1 : ${CXX} : compileflags -DBOOST_SP_USE_PTHREADS
-I${includedir} linkflags -L${libdir} ;'>> ${S}/tools/build/v2/user-config.jam
+ # D2194:Fixing the failure of "error: duplicate initialization of gcc with
the following parameters" during compilation.
+ if ! grep -qe "^using gcc : 4.3.1" ${S}/tools/build/v2/user-config.jam
+ then
+ echo 'using gcc : 4.3.1 : ${CXX} : compileflags
-DBOOST_SP_USE_PTHREADS -I${includedir} linkflags -L${libdir} ;'>>
${S}/tools/build/v2/user-config.jam
+ fi
}
addtask do_boostconfig after do_patch before do_configure
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eglibc: fix re-execution of task
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" to "rm -f". [Yocto #2194] Signed-off-by: Venkata Ramana Gollamudi --- meta/recipes-core/eglibc/eglibc_2.13.bb |8 meta/recipes-core/eglibc/eglibc_2.15.bb |8 2 files changed, 8 insertions(+), 8 deletions(-) Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [V5 0/2] Package gdbm compat libs in gdbm-compat and PR bumps
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 somewhere which won't conflict with the rootfs (2012-04-12 21:25:10 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib ag/gdbm http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ag/gdbm Andrei Gherzan (2): gdbm: Package compat libs in gdbm-compat PR bump packages with gdbm in DEPENDS 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 |2 +- meta/recipes-support/apr/apr-util_1.4.1.bb |2 +- meta/recipes-support/gdbm/gdbm_1.10.bb |7 ++- 5 files changed, 10 insertions(+), 5 deletions(-) Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Bug 2134 - bitbake package-index fails for rpm
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 support. 2. native python should only look into STAGING_DIR_NATIVE directory for modules. 3. createrepo scripts should use native python The following changes since commit 190f6d791d51aaa4cfb9f1cf932bc205ff674fb5: runqemu-internal: Add console=tty for qemuppc and NFS (2012-04-06 01:12:47 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib ag/package-index http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ag/package-index Andrei Gherzan (3): createrepo: Python scripts should use the python interpreter from env package-index: Force NATIVE python to use modules from STAGING_DIR_NATIVE rpm-native: Compile python rpm module (with-python) meta/recipes-core/meta/package-index.bb|3 + meta/recipes-devtools/rpm/rpm_5.4.0.bb |2 - ...n-scripts-should-use-interpreter-from-env.patch | 47 .../createrepo/createrepo_0.4.11.bb|3 +- 4 files changed, 52 insertions(+), 3 deletions(-) create mode 100644 meta/recipes-support/createrepo/createrepo/python-scripts-should-use-interpreter-from-env.patch Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] linux-yocto: (hopefully) final fixes
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 risk, and this is already in use by the BSP layer. The second commit is a change that I've been working on all week with Andrea and his work on extending linux-yocto-tiny. The work that was done to support out of tree features was missing .cfg and defconfig support. This meant that you could run into patching issues. To fix it, I pulled back changes that I made a few weeks ago to allow all types of fragments, features, and defconfigs to be supported. The diffstat is largely a movement of code from the recipe back to the tools (where it belonged), but the intent stays the same. I've tested this on every use case I could find .. - core BSPs - Nitin's x32 use case - Andrea's use case - kernel.org test case - Constructed tests with fragments, nested features, etc. Andrea has also tested his use case. These all pass, and the code fixes an intended feature for 1.2 as well as fixing the immediate bug in question. This is for YOCTO 2250. Cheers, Bruce cc: andrea.ad...@gmail.com The following changes since commit 023a12b70b1bbbd3625ab5a6df2ae9943a14bea5: linux-yocto/meta-yocto: update hardware reference SRCREVs (2012-04-13 16:35:59 -0400) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel-oe http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-oe Bruce Ashfield (2): linux-yocto/3.2: add igb support to romley linux-yocto: allow .cfg, .scc, .patch and defconfigs to be processed in order meta/classes/kernel-yocto.bbclass | 74 ++-- .../kern-tools/kern-tools-native_git.bb|2 +- meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb|2 +- meta/recipes-kernel/linux/linux-yocto-tiny_3.2.bb |2 +- meta/recipes-kernel/linux/linux-yocto_3.2.bb |2 +- 5 files changed, 11 insertions(+), 71 deletions(-) Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] gcc-4.6: Add fix for relocation problem and ccache
I suspect this would effect 1.1.2.
-M
On Fri, Apr 13, 2012 at 8:13 AM, Richard Purdie
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 existed but was not readable by the
> current user.
>
> This turns out of the an issue inside gcc to do with preservation of the
> sysroot
> option. See the gcc patch for more details. It only triggers when preprocessed
> sources are used which happens when ccache is used.
>
> The same issue occurs with c++ and c++-cpp-output so the same fix is applied
> there.
>
> [YOCTO #2074]
>
> Signed-off-by: Richard Purdie
> ---
> diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc
> b/meta/recipes-devtools/gcc/gcc-4.6.inc
> index d40a534..020e21b 100644
> --- a/meta/recipes-devtools/gcc/gcc-4.6.inc
> +++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
> @@ -1,6 +1,6 @@
> require gcc-common.inc
>
> -PR = "r24"
> +PR = "r25"
>
> # Third digit in PV should be incremented after a minor release
> # happens from this branch on gcc e.g. currently its 4.6.0
> @@ -73,6 +73,7 @@ SRC_URI =
> "svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};proto=http \
> file://gcc-arm-set-cost.patch \
> file://GPLUSPLUS_INCLUDE_DIR_with_sysroot.patch \
> file://fortran-cross-compile-hack.patch \
> + file://cpp-honour-sysroot.patch \
> "
>
> SRC_URI_append_sh3 = " file://sh3-installfix-fixheaders.patch "
> diff --git a/meta/recipes-devtools/gcc/gcc-4.6/cpp-honour-sysroot.patch
> b/meta/recipes-devtools/gcc/gcc-4.6/cpp-honour-sysroot.patch
> new file mode 100644
> index 000..4792c20
> --- /dev/null
> +++ b/meta/recipes-devtools/gcc/gcc-4.6/cpp-honour-sysroot.patch
> @@ -0,0 +1,40 @@
> +Currently, if the gcc toolchain is relocated and installed from sstate, then
> you try and compile
> +preprocessed source (.i or .ii files), the compiler will try and access the
> builtin sysroot location
> +rather than the --sysroot option specified on the commandline. If access to
> that directory is
> +permission denied (unreadable), gcc will error.
> +
> +This happens when ccache is in use due to the fact it uses preprocessed
> source files.
> +
> +The fix below adds %I to the cpp-output spec macro so the default
> substitutions for -iprefix,
> +-isystem, -isysroot happen and the correct sysroot is used.
> +
> +[YOCTO #2074]
> +
> +Upstream-Status: Pending
> +
> +RP 2012/04/13
> +
> +Index: gcc-4_6-branch/gcc/gcc.c
> +===
> +--- gcc-4_6-branch.orig/gcc/gcc.c 2012-04-13 12:24:37.939671140 +
> gcc-4_6-branch/gcc/gcc.c 2012-04-13 12:24:54.439670688 +
> +@@ -953,7 +953,7 @@
> + %W{o*:--output-pch=%*}}%V}}", 0, 0, 0},
> + {".i", "@cpp-output", 0, 0, 0},
> + {"@cpp-output",
> +- "%{!M:%{!MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
> %{!fsyntax-only:%(invoke_as)", 0, 0, 0},
> ++ "%{!M:%{!MM:%{!E:cc1 -fpreprocessed %i %I %(cc1_options)
> %{!fsyntax-only:%(invoke_as)", 0, 0, 0},
> + {".s", "@assembler", 0, 0, 0},
> + {"@assembler",
> + "%{!M:%{!MM:%{!E:%{!S:as %(asm_debug) %(asm_options) %i %A ", 0, 0,
> 0},
> +Index: gcc-4_6-branch/gcc/cp/lang-specs.h
> +===
> +--- gcc-4_6-branch.orig/gcc/cp/lang-specs.h 2012-04-13 12:25:01.019670594
> +
> gcc-4_6-branch/gcc/cp/lang-specs.h 2012-04-13 12:25:07.567670180 +
> +@@ -64,5 +64,5 @@
> + {".ii", "@c++-cpp-output", 0, 0, 0},
> + {"@c++-cpp-output",
> + "%{!M:%{!MM:%{!E:\
> +- cc1plus -fpreprocessed %i %(cc1_options) %2\
> ++ cc1plus -fpreprocessed %i %I %(cc1_options) %2\
> + %{!fsyntax-only:%(invoke_as)", 0, 0, 0},
>
>
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] linux-yocto/3.2: add igb support to romley
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
]
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb |2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_3.2.bb |2 +-
meta/recipes-kernel/linux/linux-yocto_3.2.bb |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb
index 94ada7e..efc4611 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb
@@ -16,7 +16,7 @@ LINUX_KERNEL_TYPE = "preempt-rt"
SRCREV_machine ?= "32ecb53e9ff759bbd297a10712b62a6575daaf86"
SRCREV_machine_qemuppc ?= "0d5625bb868cc2471d5dd49eb7abe7eb5fe1044b"
-SRCREV_meta ?= "59f350ec3794e19fa806c1b73749d851f8ebf364"
+SRCREV_meta ?= "135c75bf9615334b5b8bb9108d612fe7dfbdb901"
PR = "r1"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.2.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.2.bb
index d2c8bf7..fbff706 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.2.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.2.bb
@@ -12,7 +12,7 @@ KCONFIG_MODE = "--allnoconfig"
LINUX_VERSION ?= "3.2.11"
SRCREV_machine ?= "ec236058dc254183dbfb3744bf21f110c37af30b"
-SRCREV_meta ?= "59f350ec3794e19fa806c1b73749d851f8ebf364"
+SRCREV_meta ?= "135c75bf9615334b5b8bb9108d612fe7dfbdb901"
PR = "r0"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.2.bb
b/meta/recipes-kernel/linux/linux-yocto_3.2.bb
index b2a37c0..8bea0a0 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.2.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.2.bb
@@ -23,7 +23,7 @@ SRCREV_machine_qemuppc ?=
"92de4e2f3c6b397c8b363e079cc4d5e9bcadf877"
SRCREV_machine_qemux86 ?= "8ada1bb97415fe959a57a08504be4eb8a656ed30"
SRCREV_machine_qemux86-64 ?= "4ca7e2c5d42e755e1b4c3e1478128f047a8ed2a8"
SRCREV_machine ?= "01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a"
-SRCREV_meta ?= "59f350ec3794e19fa806c1b73749d851f8ebf364"
+SRCREV_meta ?= "135c75bf9615334b5b8bb9108d612fe7dfbdb901"
PR = "r1"
PV = "${LINUX_VERSION}+git${SRCPV}"
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] linux-yocto: (hopefully) final fixes
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 layer. The second commit is a change that I've been working on all week with Andrea and his work on extending linux-yocto-tiny. The work that was done to support out of tree features was missing .cfg and defconfig support. This meant that you could run into patching issues. To fix it, I pulled back changes that I made a few weeks ago to allow all types of fragments, features, and defconfigs to be supported. The diffstat is largely a movement of code from the recipe back to the tools (where it belonged), but the intent stays the same. I've tested this on every use case I could find .. - core BSPs - Nitin's x32 use case - Andrea's use case - kernel.org test case - Constructed tests with fragments, nested features, etc. Andrea has also tested his use case. These all pass, and the code fixes an intended feature for 1.2 as well as fixing the immediate bug in question. This is for YOCTO 2250. Cheers, Bruce cc: andrea.ad...@gmail.com The following changes since commit 023a12b70b1bbbd3625ab5a6df2ae9943a14bea5: linux-yocto/meta-yocto: update hardware reference SRCREVs (2012-04-13 16:35:59 -0400) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel-oe http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-oe Bruce Ashfield (2): linux-yocto/3.2: add igb support to romley linux-yocto: allow .cfg, .scc, .patch and defconfigs to be processed in order meta/classes/kernel-yocto.bbclass | 74 ++-- .../kern-tools/kern-tools-native_git.bb|2 +- meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb|2 +- meta/recipes-kernel/linux/linux-yocto-tiny_3.2.bb |2 +- meta/recipes-kernel/linux/linux-yocto_3.2.bb |2 +- 5 files changed, 11 insertions(+), 71 deletions(-) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] linux-yocto: allow .cfg, .scc, .patch and defconfigs to be processed in order
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 being applied
To fix this, the recipe space code that previously detected and generated
automatic features moves back to the kernel tools (where it was before) and
is updated to also process .cfg and defconfigs. Moving this back to the
tools allow other recipes to automatically benefit from the additional
support.
The second issue is addressed by allowing configme to take --alldefconfig
when a recipe wishes to pass a defconfig and override the default
behaviour.
Fixes [YOCTO: 2250]
Signed-off-by: Bruce Ashfield
---
meta/classes/kernel-yocto.bbclass | 74 ++--
.../kern-tools/kern-tools-native_git.bb|2 +-
2 files changed, 8 insertions(+), 68 deletions(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index b7e8b32..0caf6a6 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -20,7 +20,9 @@ def find_sccs(d):
sources_list=[]
for s in sources:
base, ext = os.path.splitext(os.path.basename(s))
- if ext and ext in ('.scc'):
+ if ext and ext in ('.scc' '.cfg' '.patch'):
+ sources_list.append(s)
+ elif base and base in 'defconfig':
sources_list.append(s)
return sources_list
@@ -73,72 +75,9 @@ do_patch() {
fi
sccs="${@" ".join(find_sccs(d))}"
- patches_and_dirs="${@" ".join(find_urls(d))}"
-
- # This loops through all patches, and looks for directories that do
- # not already have feature descriptions. If a directory doesn't have
- # a feature description, we switch to the ${WORKDIR} variant of the
- # feature (so we can write to it) and generate a feature for those
- # patches. The generated feature will respect the patch order.
- #
- # By leaving source patch directories that already have .scc files
- # as-is it means that a SRC_URI can only contain a .scc file, and all
- # patches that the .scc references will be picked up, without having
- # to be repeated on the SRC_URI line .. which is more intutive
- set +e
- patch_dirs=
- for pp in ${patches_and_dirs}; do
- p=`echo $pp | cut -f1 -d:`
- wp=`echo $pp | cut -f2 -d:`
- pdir=`dirname ${p}`
- pname=`basename ${p}`
- scc=`find ${pdir} -maxdepth 1 -name '*.scc'`
- if [ -z "${scc}" ]; then
- # there is no scc file. We need to switch to someplace
that we know
- # we can create content (the workdir)
- workdir_subdir=`dirname ${wp}`
- suggested_dir="${WORKDIR}/${workdir_subdir}"
- echo ${gen_feature_dirs} | grep -q ${suggested_dir}
- if [ $? -ne 0 ]; then
- gen_feature_dirs="${gen_feature_dirs}
${suggested_dir}"
- fi
- # we call the file *.scc_tmp, so the test above will
continue to find
- # that patches from a common subdirectory don't have a
scc file and
- # they'll be placed in order, into this file. We'll
rename it later.
- gen_feature_name="gen_`echo ${workdir_subdir} | sed
's%/%%g'`_desc.scc_tmp"
- echo "patch ${pname}" >>
${WORKDIR}/${workdir_subdir}/${gen_feature_name}
- else
- suggested_dir="${pdir}"
- fi
- echo ${patch_dirs} | grep -q ${suggested_dir}
- if [ $? -ne 0 ]; then
- patch_dirs="${patch_dirs} ${suggested_dir}"
- fi
- done
-
- # look for any found scc files, and ensure they are added to the list
- # of directories passsed to updateme
- for s in ${sccs}; do
- sdir=`dirname ${s}`
- echo ${patch_dirs} | grep -q ${sdir}
- if [ $? -ne 0 ]; then
- patch_dirs="${patch_dirs} ${sdir}"
- fi
- done
-
- # go through the patch directories and look for any scc feature files
- # that were constructed above. If one is found, rename it to ".scc" so
- # the kernel patching can see it.
- for pdir in ${patch_dirs}; do
- scc=`find ${pdir} -maxdepth 1 -name '*.scc_tmp'`
-if [ -n "${scc}" ]; then
- new_scc=`echo ${scc} | sed 's/_tmp//'`
- mv -f ${scc} ${new_scc}
- fi
- done
-
- patch_dirs="${patch_dirs} ${WOR
Re: [OE-core] [PATCH 1/1] grub 1.99: fix build for gcc 4.7
On Fri, Apr 13, 2012 at 2:41 AM, Robert Yang 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 [-Werror=strict-aliasing]
> ..
> cc1: all warnings being treated as errors
>
> While compare the compile command between gcc 4.4.4 and gcc 4.7.0, they
> are the same (both of them have -Wall and -Werror), it seems that gcc
> 4.7.0 has changed its algorithm for the strict aliasing check, but I
> didn't find the related information from its release note.
>
> Add "-fno-strict-aliasing" to gcc's option would fix the problem, this
> would disable the optimization for strict-aliasing.
This seems a bit more than whats needed. You could try adding
-Wno-error=strict-aliasing to CFLAGS
on another note. I do not see this failing with gcc-4.7(target compiler) here
when I build grub for qemux86 so I am a bit puzzled
>
> [YOCTO #2291]
>
> Signed-off-by: Robert Yang
> ---
> meta/recipes-bsp/grub/grub_1.99.bb | 7 ++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/meta/recipes-bsp/grub/grub_1.99.bb
> b/meta/recipes-bsp/grub/grub_1.99.bb
> index ac66e83..f45b634 100644
> --- a/meta/recipes-bsp/grub/grub_1.99.bb
> +++ b/meta/recipes-bsp/grub/grub_1.99.bb
> @@ -12,7 +12,7 @@ LICENSE = "GPLv3"
> LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
>
> RDEPENDS_${PN} = "diffutils freetype"
> -PR = "r3"
> +PR = "r4"
>
> SRC_URI = "ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
> file://grub-install.in.patch \
> @@ -29,6 +29,11 @@ inherit gettext
> EXTRA_OECONF = "--with-platform=pc --disable-grub-mkfont
> --target=${TARGET_ARCH} --program-prefix="""
>
> do_configure() {
> + # Fix build error for gcc 4.7
> + echo "CPPFLAGS_DEFAULT += -fno-strict-aliasing" >> conf/Makefile.common
> + # Also modify Makefile.in, we can remove this when we can run autoreconf
> + sed -i 's/^CPPFLAGS_DEFAULT = \(.*\)/CPPFLAGS_DEFAULT =
> -fno-strict-aliasing \1/' \
> + Makefile.in grub-core/Makefile.in
> oe_runconf
> }
>
> --
> 1.7.1
>
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Fwd: ARM hard-float linker path - consensus
On Fri, Apr 13, 2012 at 12:50 PM, Denys Dmytriyenko 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 still > good to see some agreement here. > > Do we want to make the necessary toolchain changes right away, or wait for > them to propagate from upstream? I plan to propose do it post 1.2 yocto release > > -- > Denys > > >> -- Forwarded message -- >> From: Steve McIntyre >> Date: Fri, Apr 13, 2012 at 10:37 AM >> Subject: ARM hard-float linker path - consensus >> To: cross-dis...@lists.linaro.org >> Cc: libc-po...@sourceware.org, gcc-patc...@gcc.gnu.org >> >> >> Hi folks, >> >> As promised, here's minutes from the call we had this >> afternoon. Spoiler: the result we've agreed is >> >> /lib/ld-linux-armhf.so.3 >> >> And here's a transcription of the minutes from >> >> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 >> >> >> >> Meeting: 13th April 2012, 15:00 UTC >> >> Agenda >> -- >> >> * Debian/Ubuntu have so far built using >> /lib/arm-linux-gnueabihf/ld-linux.so.3 >> * Some other distros (Fedora, OpenSUSE) are still using >> /lib/ld-linux.so.3 option which matches the older soft-float ABI >> * Some people are proposing /libhf/ld-linux.so.3 or >> /libhfp/ld-linux.so.3 (multilib) >> * Some people proposed /lib/ld-arm-linux-gnueabihf.so.3 (similar to >> x86_64, libs still in /lib, from Michael Hope) >> * What should we do as a community? >> >> Present >> --- >> >> Name Affiliations >> >> Steve McIntyre ARM, Debian, Linaro >> Wookey ARM, Debian, Linaro >> Richard Earnshaw ARM, gcc >> Jeff Law Fedora, Red Hat, gcc, glibc >> Jon Masters Fedora, Red Hat >> Andrew Haley Fedora, Red Hat, gcc >> Andreas Jaeger SUSE, openSUSE, glibc >> Carlos O'Donnell Mentor, gcc >> Steve Langasek Canonical, Ubuntu, Debian >> Dann Frazier Canonical, Ubuntu, Debian >> Adam Conrad Canonical, Ubuntu, Debian >> Matthias Klose Canonical, Ubuntu, Debian >> Mike Frysinger Gentoo >> Dennis Gilmore Fedora, Red Hat >> >> Discussion >> -- >> >> We started with a couple of questions up front to establish the >> grounds for discussion: >> >> * We believed that decision makers were present for all the important >> parties, i.e. all the arm hard-float distros, plus toolchain >> developers. This meant that a decision taken at the meeting could >> be implemented without needing further arguments/negotiations. >> >> * All the people present understood the importance of cross-distro >> binary compatibility, and they all wanted it. This led to agreement >> that we needed to agree on a standard path for the runtime linker >> for ARM hard-float Linux binaries. >> >> Debian and Ubuntu had so far been using the "multi-arch" path of >> /lib/arm-linux-gnueabihf/ld-linux.so.3. Fedora and OpenSUSE were thus >> far using /lib/ld-linux.so.3, the same as the soft-float ABI. Others >> had proposed alternative paths such as /libhf/ld-linux.so.3 or >> /libhfp/ld-linux.so.3 (multilib) or >> /lib/ld-arm-linux-gnueabihf.so.3. Discussion showed that none of these >> were found to be universally acceptable. >> >> Two parties were likely to be soon affected by an agreement here: >> >> 1. Ubuntu 12.04 (releasing with armhf in ~2 weeks) >> >> Adam/Steve L agreed that all efforts would be put in to switch the >> compilers in Ubuntu to a new path before release. Default things like >> gcc would be correct, but less common tools might still be targetting >> the old path /lib/arm-linux-gnueabihf/ld-linux.so. at release. They >> could be fixed in the longer term and would not stop progress here. >> >> 2. Mentor (Codebench due for release in ~1 week) >> >> Carlos mentioned this - Codebench has been using /lib/ld-linux.so.3 >> for hard-float binaries for some time and it was too late to change >> that for this upcoming release. Next release due in October. Suggested >> and accepted that this should be mentioned in release notes: if people >> want to use Codebench on some systems (Debian/Ubuntu and derivatives), >> they'll need to tweak their system setup. He may be able to do the >> linker change and rebuild in a point release in a few weeks. >> >> It was briefly suggested that the soft-float linker should be renamed >> away from /lib/ld-linux.so.3 as well at this time, but that idea was >> quickly shot down. >> >> Proposal #1: /lib/ld-armhf.so.3 (not generally liked) >> >> Proposal #2: /lib/ld-linux-armhf.so.3 (not favourite, but considered >> an acceptable compromise by all) >> >> No need to go any further. >> >> Conclusion >> -- >> >> All the people in the meeting agreed: the new runtime linker path for >> ARM hard-float Linux binaries was
[OE-core] [PATCH 2/2] systemtap: disable document generation by default
From: Tom Zanussi
Building the systemtap documentation adds significantly to the build
time, so disable it by default.
Signed-off-by: Tom Zanussi
---
meta/recipes-kernel/systemtap/systemtap_git.bb |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index 1d2c9f3..91bccd1 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.bb
+++ b/meta/recipes-kernel/systemtap/systemtap_git.bb
@@ -20,6 +20,10 @@ EXTRA_OECONF += "--with-libelf=${STAGING_DIR_TARGET}
--without-rpm \
ac_cv_file__usr_include_avahi_client=no \
ac_cv_file__usr_include_avahi_common=no "
+STAP_DOCS ?= "--disable-docs --disable-publican --disable-refdocs"
+
+EXTRA_OECONF += "${STAP_DOCS} "
+
inherit autotools gettext
BBCLASSEXTEND = "native nativesdk"
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] systemtap doc build fix
From: Tom Zanussi 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 Gherzan (1): rpm-native: Compile python rpm module (with-python) are available in the git repository at: git://git.yoctoproject.org/poky-contrib.git tzanussi/2193-fix http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=tzanussi/2193-fix Tom Zanussi (2): systemtap: fix docproc build error systemtap: disable document generation by default .../systemtap/systemtap/docproc-build-fix.patch| 19 +++ meta/recipes-kernel/systemtap/systemtap_git.bb | 10 +- meta/recipes-kernel/systemtap/systemtap_git.inc|4 +++- 3 files changed, 31 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-kernel/systemtap/systemtap/docproc-build-fix.patch ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] systemtap: fix docproc build error
From: Tom Zanussi
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
---
.../systemtap/systemtap/docproc-build-fix.patch| 19 +++
meta/recipes-kernel/systemtap/systemtap_git.bb |6 +-
meta/recipes-kernel/systemtap/systemtap_git.inc|4 +++-
3 files changed, 27 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-kernel/systemtap/systemtap/docproc-build-fix.patch
diff --git a/meta/recipes-kernel/systemtap/systemtap/docproc-build-fix.patch
b/meta/recipes-kernel/systemtap/systemtap/docproc-build-fix.patch
new file mode 100644
index 000..33a8994
--- /dev/null
+++ b/meta/recipes-kernel/systemtap/systemtap/docproc-build-fix.patch
@@ -0,0 +1,19 @@
+Upstream-Status: Inappropriate [configuration]
+
+Signed-off-by: Tom Zanussi
+
+Index: git/doc/SystemTap_Tapset_Reference/Makefile.am
+===
+--- git.orig/doc/SystemTap_Tapset_Reference/Makefile.am2012-04-13
08:43:46.263339003 -0500
git/doc/SystemTap_Tapset_Reference/Makefile.am 2012-04-13
09:31:22.470083915 -0500
+@@ -27,6 +27,10 @@
+ noinst_PROGRAMS = docproc
+ SRCTREE=$(abs_top_srcdir)/
+ DOCPROC=$(abs_builddir)/docproc
++docproc_LINK = $(CC_FOR_BUILD) $(LDFLAGS_FOR_BUILD) -o $@
++
++docproc.o: $(srcdir)/docproc.c
++ $(CC_FOR_BUILD) -c $(CFLAGS_FOR_BUILD) -o $@ $(srcdir)/docproc.c
+
+ all: $(PDFDOCS) stamp-htmldocs stamp-mandocs
+ tapsets.xml: docproc $(shell find $(SRCTREE)/tapset -name '*.stp')
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index c4a9d87..1d2c9f3 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.bb
+++ b/meta/recipes-kernel/systemtap/systemtap_git.bb
@@ -6,7 +6,11 @@ DEPENDS = "elfutils sqlite3 systemtap-native"
DEPENDS_virtclass-native = "elfutils-native sqlite3-native gettext-native"
DEPENDS_virtclass-nativesdk = "elfutils-nativesdk sqlite3-nativesdk
gettext-nativesdk"
-PR = "r2"
+PR = "r3"
+
+export CC_FOR_BUILD = "${BUILD_CC}"
+export CFLAGS_FOR_BUILD = "${BUILD_CFLAGS}"
+export LDFLAGS_FOR_BUILD = "${BUILD_LDFLAGS}"
EXTRA_OECONF += "--with-libelf=${STAGING_DIR_TARGET} --without-rpm \
ac_cv_file__usr_include_nss=no \
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.inc
b/meta/recipes-kernel/systemtap/systemtap_git.inc
index cc250ff..c4d6e34 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.inc
+++ b/meta/recipes-kernel/systemtap/systemtap_git.inc
@@ -4,7 +4,9 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
SRCREV = "83bd2699d8cff2f2d6b9eaf5ea254e4cb6b33e81"
PV = "1.7+git${SRCPV}"
-SRC_URI = "git://sources.redhat.com/git/systemtap.git;protocol=git"
+SRC_URI = "git://sources.redhat.com/git/systemtap.git;protocol=git \
+ file://docproc-build-fix.patch \
+ "
SRC_URI[md5sum]= "cb202866ed704c44a876d041f788bdee"
SRC_URI[sha256sum] =
"8ffe35caec0d937bd23fd78a3a8d94b58907cc0de0330b35e38f9f764815c459"
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Fwd: ARM hard-float linker path - consensus
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 toolchain changes right away, or wait for them to propagate from upstream? -- Denys > -- Forwarded message -- > From: Steve McIntyre > Date: Fri, Apr 13, 2012 at 10:37 AM > Subject: ARM hard-float linker path - consensus > To: cross-dis...@lists.linaro.org > Cc: libc-po...@sourceware.org, gcc-patc...@gcc.gnu.org > > > Hi folks, > > As promised, here's minutes from the call we had this > afternoon. Spoiler: the result we've agreed is > > /lib/ld-linux-armhf.so.3 > > And here's a transcription of the minutes from > > https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 > > > > Meeting: 13th April 2012, 15:00 UTC > > Agenda > -- > > * Debian/Ubuntu have so far built using > /lib/arm-linux-gnueabihf/ld-linux.so.3 > * Some other distros (Fedora, OpenSUSE) are still using > /lib/ld-linux.so.3 option which matches the older soft-float ABI > * Some people are proposing /libhf/ld-linux.so.3 or > /libhfp/ld-linux.so.3 (multilib) > * Some people proposed /lib/ld-arm-linux-gnueabihf.so.3 (similar to > x86_64, libs still in /lib, from Michael Hope) > * What should we do as a community? > > Present > --- > > Name Affiliations > > Steve McIntyre ARM, Debian, Linaro > Wookey ARM, Debian, Linaro > Richard Earnshaw ARM, gcc > Jeff Law Fedora, Red Hat, gcc, glibc > Jon Masters Fedora, Red Hat > Andrew Haley Fedora, Red Hat, gcc > Andreas Jaeger SUSE, openSUSE, glibc > Carlos O'Donnell Mentor, gcc > Steve Langasek Canonical, Ubuntu, Debian > Dann Frazier Canonical, Ubuntu, Debian > Adam Conrad Canonical, Ubuntu, Debian > Matthias Klose Canonical, Ubuntu, Debian > Mike Frysinger Gentoo > Dennis Gilmore Fedora, Red Hat > > Discussion > -- > > We started with a couple of questions up front to establish the > grounds for discussion: > > * We believed that decision makers were present for all the important > parties, i.e. all the arm hard-float distros, plus toolchain > developers. This meant that a decision taken at the meeting could > be implemented without needing further arguments/negotiations. > > * All the people present understood the importance of cross-distro > binary compatibility, and they all wanted it. This led to agreement > that we needed to agree on a standard path for the runtime linker > for ARM hard-float Linux binaries. > > Debian and Ubuntu had so far been using the "multi-arch" path of > /lib/arm-linux-gnueabihf/ld-linux.so.3. Fedora and OpenSUSE were thus > far using /lib/ld-linux.so.3, the same as the soft-float ABI. Others > had proposed alternative paths such as /libhf/ld-linux.so.3 or > /libhfp/ld-linux.so.3 (multilib) or > /lib/ld-arm-linux-gnueabihf.so.3. Discussion showed that none of these > were found to be universally acceptable. > > Two parties were likely to be soon affected by an agreement here: > > 1. Ubuntu 12.04 (releasing with armhf in ~2 weeks) > > Adam/Steve L agreed that all efforts would be put in to switch the > compilers in Ubuntu to a new path before release. Default things like > gcc would be correct, but less common tools might still be targetting > the old path /lib/arm-linux-gnueabihf/ld-linux.so. at release. They > could be fixed in the longer term and would not stop progress here. > > 2. Mentor (Codebench due for release in ~1 week) > > Carlos mentioned this - Codebench has been using /lib/ld-linux.so.3 > for hard-float binaries for some time and it was too late to change > that for this upcoming release. Next release due in October. Suggested > and accepted that this should be mentioned in release notes: if people > want to use Codebench on some systems (Debian/Ubuntu and derivatives), > they'll need to tweak their system setup. He may be able to do the > linker change and rebuild in a point release in a few weeks. > > It was briefly suggested that the soft-float linker should be renamed > away from /lib/ld-linux.so.3 as well at this time, but that idea was > quickly shot down. > > Proposal #1: /lib/ld-armhf.so.3 (not generally liked) > > Proposal #2: /lib/ld-linux-armhf.so.3 (not favourite, but considered > an acceptable compromise by all) > > No need to go any further. > > Conclusion > -- > > All the people in the meeting agreed: the new runtime linker path for > ARM hard-float Linux binaries was to be > > /lib/ld-linux-armhf.so.3 > > ACTION: People at the meeting to present this decision to their > companies / communities and get the appropriate changes made. > > Further discussion > ---
[OE-core] Fwd: ARM hard-float linker path - consensus
FYI this will impact us in coming time. If someone has questions please bring it up -- Forwarded message -- From: Steve McIntyre Date: Fri, Apr 13, 2012 at 10:37 AM Subject: ARM hard-float linker path - consensus To: cross-dis...@lists.linaro.org Cc: libc-po...@sourceware.org, gcc-patc...@gcc.gnu.org Hi folks, As promised, here's minutes from the call we had this afternoon. Spoiler: the result we've agreed is /lib/ld-linux-armhf.so.3 And here's a transcription of the minutes from https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 Meeting: 13th April 2012, 15:00 UTC Agenda -- * Debian/Ubuntu have so far built using /lib/arm-linux-gnueabihf/ld-linux.so.3 * Some other distros (Fedora, OpenSUSE) are still using /lib/ld-linux.so.3 option which matches the older soft-float ABI * Some people are proposing /libhf/ld-linux.so.3 or /libhfp/ld-linux.so.3 (multilib) * Some people proposed /lib/ld-arm-linux-gnueabihf.so.3 (similar to x86_64, libs still in /lib, from Michael Hope) * What should we do as a community? Present --- Name Affiliations Steve McIntyre ARM, Debian, Linaro Wookey ARM, Debian, Linaro Richard Earnshaw ARM, gcc Jeff Law Fedora, Red Hat, gcc, glibc Jon Masters Fedora, Red Hat Andrew Haley Fedora, Red Hat, gcc Andreas Jaeger SUSE, openSUSE, glibc Carlos O'Donnell Mentor, gcc Steve Langasek Canonical, Ubuntu, Debian Dann Frazier Canonical, Ubuntu, Debian Adam Conrad Canonical, Ubuntu, Debian Matthias Klose Canonical, Ubuntu, Debian Mike Frysinger Gentoo Dennis Gilmore Fedora, Red Hat Discussion -- We started with a couple of questions up front to establish the grounds for discussion: * We believed that decision makers were present for all the important parties, i.e. all the arm hard-float distros, plus toolchain developers. This meant that a decision taken at the meeting could be implemented without needing further arguments/negotiations. * All the people present understood the importance of cross-distro binary compatibility, and they all wanted it. This led to agreement that we needed to agree on a standard path for the runtime linker for ARM hard-float Linux binaries. Debian and Ubuntu had so far been using the "multi-arch" path of /lib/arm-linux-gnueabihf/ld-linux.so.3. Fedora and OpenSUSE were thus far using /lib/ld-linux.so.3, the same as the soft-float ABI. Others had proposed alternative paths such as /libhf/ld-linux.so.3 or /libhfp/ld-linux.so.3 (multilib) or /lib/ld-arm-linux-gnueabihf.so.3. Discussion showed that none of these were found to be universally acceptable. Two parties were likely to be soon affected by an agreement here: 1. Ubuntu 12.04 (releasing with armhf in ~2 weeks) Adam/Steve L agreed that all efforts would be put in to switch the compilers in Ubuntu to a new path before release. Default things like gcc would be correct, but less common tools might still be targetting the old path /lib/arm-linux-gnueabihf/ld-linux.so. at release. They could be fixed in the longer term and would not stop progress here. 2. Mentor (Codebench due for release in ~1 week) Carlos mentioned this - Codebench has been using /lib/ld-linux.so.3 for hard-float binaries for some time and it was too late to change that for this upcoming release. Next release due in October. Suggested and accepted that this should be mentioned in release notes: if people want to use Codebench on some systems (Debian/Ubuntu and derivatives), they'll need to tweak their system setup. He may be able to do the linker change and rebuild in a point release in a few weeks. It was briefly suggested that the soft-float linker should be renamed away from /lib/ld-linux.so.3 as well at this time, but that idea was quickly shot down. Proposal #1: /lib/ld-armhf.so.3 (not generally liked) Proposal #2: /lib/ld-linux-armhf.so.3 (not favourite, but considered an acceptable compromise by all) No need to go any further. Conclusion -- All the people in the meeting agreed: the new runtime linker path for ARM hard-float Linux binaries was to be /lib/ld-linux-armhf.so.3 ACTION: People at the meeting to present this decision to their companies / communities and get the appropriate changes made. Further discussion -- General unhappiness with the mess that led to this meeting. Future planning needs to be better between the various groups for the next time we have a new CPU/ABI/whatever. ACTION: Jon Masters to talk to the Linux Foundation about setting up a forum for such discussions. In the meantime, strong consensus to use the cross-dis...@lists.linaro.org mailing list for any more conversations now we have people in contact. ACTION: Steve McIntyre to write up the minutes and circulate. Include an updated linker path patch for g
Re: [OE-core] [PATCHv2] gcc-4.6: Add fix for relocation problem and ccache
On Fri, Apr 13, 2012 at 6:13 AM, Richard Purdie 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 existed but was not readable by the > current user. > > This turns out of the an issue inside gcc to do with preservation of the > sysroot > option. See the gcc patch for more details. It only triggers when preprocessed > sources are used which happens when ccache is used. > > The same issue occurs with c++ and c++-cpp-output so the same fix is applied > there. > > [YOCTO #2074] > > Signed-off-by: Richard Purdie looks good. Acked-by: Khem Raj ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] boost: fix re-execution of task
On Fri, Apr 13, 2012 at 4:42 AM, Venkata ramana gollamudi wrote: > + # D2194:Fixing the failure of "error: duplicate initialization of gcc > with the following parameters" during compilation. same here. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] perl: fix re-execution of task
On Fri, Apr 13, 2012 at 4:46 AM, Venkata ramana gollamudi 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 should be corrected to avoid your internal bug tracking information ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] pseudo: Tell pseudo to avoid specifying an 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 > >> > >> In this case, I don't think embedding a static RPATH makes sense, but > >> perhaps a > >> $ORIGIN path might? > >> > >> Can chrpath be used to add an rpath after compilation and linking, if so > >> that is > >> what I would suggest to do. Otherwise I'm not exactly sure how to resolve > >> this... > >> > >> Note, typically pseudo is -not- linked the "sdk" version of the libc, but > >> is > >> linked to the host libc. In the past when exporting and sdk with > >> something like > >> pseudo you needed to either build on a common machine (where everything was > >> compatible) or have a way to rebuild pseudo on the final target system. > >> Perhaps > >> that is what is needed? > > > > We need to embed a full static rpath and then our nativesdk relocation > > code will then handle adding in the correct $ORIGIN for us. > > > > The way the sdk works, it will link against the sdk libc btw and this > > avoids the need to rebuild on the target system. We just need the rpath > > in there so it can figure things out correctly. > > Ha, that is what we had (unintentionally) that triggered the QA failure. > > If it's only for a nativesdk build, then we simply switch the --without-rpath Maybe, maybe not. It depends exactly what rpath its encoding in there. Previously it looked like it was encoding the sysroot path too (which is a security hole). We need a target rpath in there and no sysroot path. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] pseudo: Tell pseudo to avoid specifying an RPATH
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 makes sense, but perhaps a $ORIGIN path might? Can chrpath be used to add an rpath after compilation and linking, if so that is what I would suggest to do. Otherwise I'm not exactly sure how to resolve this... Note, typically pseudo is -not- linked the "sdk" version of the libc, but is linked to the host libc. In the past when exporting and sdk with something like pseudo you needed to either build on a common machine (where everything was compatible) or have a way to rebuild pseudo on the final target system. Perhaps that is what is needed? We need to embed a full static rpath and then our nativesdk relocation code will then handle adding in the correct $ORIGIN for us. The way the sdk works, it will link against the sdk libc btw and this avoids the need to rebuild on the target system. We just need the rpath in there so it can figure things out correctly. Ha, that is what we had (unintentionally) that triggered the QA failure. If it's only for a nativesdk build, then we simply switch the --without-rpath --Mark Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] pseudo: Tell pseudo to avoid specifying an RPATH
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 might? > > Can chrpath be used to add an rpath after compilation and linking, if so that > is > what I would suggest to do. Otherwise I'm not exactly sure how to resolve > this... > > Note, typically pseudo is -not- linked the "sdk" version of the libc, but is > linked to the host libc. In the past when exporting and sdk with something > like > pseudo you needed to either build on a common machine (where everything was > compatible) or have a way to rebuild pseudo on the final target system. > Perhaps > that is what is needed? We need to embed a full static rpath and then our nativesdk relocation code will then handle adding in the correct $ORIGIN for us. The way the sdk works, it will link against the sdk libc btw and this avoids the need to rebuild on the target system. We just need the rpath in there so it can figure things out correctly. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] perl: fix re-execution of task
> ---
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 ":"` ; do
> -echo Fixing: $foo
> -
sed -e "s%/usr/include/%${STAGING_INCDIR}/%g" -i $foo
> + # 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
> + if [
! -h $foo ]; then
> + echo Fixing: $foo
> + sed -e
"s%/usr/include/%${STAGING_INCDIR}/%g" -i $foo
> + fi
From: Richard Purdie
To: Venkata ramana gollamudi
Cc: "'openembedded-core@lists.openembedded.org'"
, Sanil kumar
Date: Fri, 13 Apr 2012 16:29:36 +0100
In-Reply-To:
<36ed13f3654ae54ca763e6821d93a5711043a...@szxeml534-mbs.china.huawei.com>
References:
<36ed13f3654ae54ca763e6821d93a5711043a...@szxeml534-mbs.china.huawei.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.2.2-
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
On Fri, 2012-04-13 at 11:46 +, Venkata ramana gollamudi wrote:
> 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
> will be also be modified individually.
> Fix done to ignore the path correction during do_configure,
> if file is a link.
>
> [Yocto #2194]
>
> Signed-off-by: Venkata Ramana Gollamudi
> ---
> meta/recipes-devtools/perl/perl_5.14.2.bb |8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-devtools/perl/perl_5.14.2.bb
> b/meta/recipes-devtools/perl/perl_5.14.2.bb
> index 92ca9b8..414aa22 100644
> --- 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 ":"` ; do
> -echo Fixing: $foo
> -sed -e "s%/usr/include/%${STAGING_INCDIR}/%g" -i $foo
> + # 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
> + if [ ! -h $foo ]; then
> + echo Fixing: $foo
> + sed -e "s%/usr/include/%${STAGING_INCDIR}/%g" -i $foo
> + fi
> done
>
> rm -f config
I think its a bad idea to assume patches are symlinks. Could we add
something like --exclude=patches to the grep command?
Secondly, the above will still cause problems if ${STAGING_INCDIR}
contains /usr/include which it usually will, for example if:
STAGING_INCDIR=/foo/usr/include
then you can end up with:
/foo/foo/foo/foo/usr/include
after a few runs. This fix therefore still needs some work.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] pseudo: Tell pseudo to avoid specifying an RPATH
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 Hatle
---
meta/recipes-devtools/pseudo/pseudo.inc|8
meta/recipes-devtools/pseudo/pseudo_1.3.bb |2 +-
meta/recipes-devtools/pseudo/pseudo_git.bb |2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-devtools/pseudo/pseudo.inc
b/meta/recipes-devtools/pseudo/pseudo.inc
index 664a9b5..d5c33df 100644
--- a/meta/recipes-devtools/pseudo/pseudo.inc
+++ b/meta/recipes-devtools/pseudo/pseudo.inc
@@ -29,9 +29,9 @@ NO32LIBS ??= "0"
# Compile for the local machine arch...
do_compile () {
if [ "${SITEINFO_BITS}" == "64" ]; then
- ${S}/configure --prefix=${prefix}
--libdir=${prefix}/lib/pseudo/lib${SITEINFO_BITS}
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=${SITEINFO_BITS}
--enable-static-sqlite
+ ${S}/configure --prefix=${prefix}
--libdir=${prefix}/lib/pseudo/lib${SITEINFO_BITS}
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=${SITEINFO_BITS}
--enable-static-sqlite --without-rpath
else
- ${S}/configure --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=${SITEINFO_BITS}
--enable-static-sqlite
+ ${S}/configure --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=${SITEINFO_BITS}
--enable-static-sqlite --without-rpath
fi
oe_runmake ${MAKEOPTS}
}
@@ -42,7 +42,7 @@ do_compile () {
do_compile_prepend_virtclass-native () {
if [ "${SITEINFO_BITS}" == "64" -a -e "/usr/include/gnu/stubs-32.h" -a "${PN}" ==
"pseudo-native" -a "${NO32LIBS}" != "1" ]; then
# We need the 32-bit libpseudo on a 64-bit machine...
- ./configure --prefix=${prefix}
--libdir=${prefix}/lib/pseudo/lib
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=32
+ ./configure --prefix=${prefix}
--libdir=${prefix}/lib/pseudo/lib
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=32 --without-rpath
oe_runmake ${MAKEOPTS} libpseudo
# prevent it from removing the lib, but remove everything else
make 'LIB=foo' ${MAKEOPTS} distclean
@@ -52,7 +52,7 @@ do_compile_prepend_virtclass-native () {
do_compile_prepend_virtclass-nativesdk () {
if [ "${SITEINFO_BITS}" == "64" -a -e "/usr/include/gnu/stubs-32.h" -a "${PN}" ==
"pseudo-native" -a "${NO32LIBS}" != "1" ]; then
# We need the 32-bit libpseudo on a 64-bit machine...
- ./configure --prefix=${prefix}
--libdir=${prefix}/lib/pseudo/lib
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=32
+ ./configure --prefix=${prefix}
--libdir=${prefix}/lib/pseudo/lib
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=32 --without-rpath
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 might?
Can chrpath be used to add an rpath after compilation and linking, if so that is
what I would suggest to do. Otherwise I'm not exactly sure how to resolve this...
Note, typically pseudo is -not- linked the "sdk" version of the libc, but is
linked to the host libc. In the past when exporting and sdk with something like
pseudo you needed to either build on a common machine (where everything was
compatible) or have a way to rebuild pseudo on the final target system. Perhaps
that is what is needed?
--Mark
/opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/pseudo -P
/opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr tar -C "/tmp/opt" -xjf
"/intel/home/sgw/Downloads/core-image-minimal-qemux86-64.tar.bz2"
tar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found
(required by
/opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/lib/pseudo/lib64/libpseudo.so)
See also bug 1968
I do have a libc.so.6.
/opt/poky/1.2/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 -> libc-2.15.so
Sau!
oe_runmake ${MAKEOPTS} libpseudo
# prevent it from removing the lib, but remove everything else
make 'LIB=foo' ${MAKEOPTS} distclean
diff --git a/meta/recipes-devtools/pseudo/pseudo_1.3.bb
b/meta/recipes-devtools/pseudo/pseudo_1.3.bb
index e7a329c..080b739 100644
--- a/meta/recipes-devtools/pseudo/pseudo_1.3.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_1.3.bb
@@ -1,6 +1,6 @@
require pseudo.inc
-PR = "r7"
+PR = "r8"
SRC_URI = "http://www.yoctoproject.org/downloads/${BPN}/${BPN}-${PV}.tar.bz2";
diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 9414c79..7857275 100644
--- a/meta/recipes-devtools/pseudo/pseudo_
Re: [OE-core] [PATCH 1/2] pseudo: Tell pseudo to avoid specifying an RPATH
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 Hatle
---
meta/recipes-devtools/pseudo/pseudo.inc|8
meta/recipes-devtools/pseudo/pseudo_1.3.bb |2 +-
meta/recipes-devtools/pseudo/pseudo_git.bb |2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-devtools/pseudo/pseudo.inc
b/meta/recipes-devtools/pseudo/pseudo.inc
index 664a9b5..d5c33df 100644
--- a/meta/recipes-devtools/pseudo/pseudo.inc
+++ b/meta/recipes-devtools/pseudo/pseudo.inc
@@ -29,9 +29,9 @@ NO32LIBS ??= "0"
# Compile for the local machine arch...
do_compile () {
if [ "${SITEINFO_BITS}" == "64" ]; then
- ${S}/configure --prefix=${prefix}
--libdir=${prefix}/lib/pseudo/lib${SITEINFO_BITS}
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=${SITEINFO_BITS}
--enable-static-sqlite
+ ${S}/configure --prefix=${prefix}
--libdir=${prefix}/lib/pseudo/lib${SITEINFO_BITS}
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=${SITEINFO_BITS}
--enable-static-sqlite --without-rpath
else
- ${S}/configure --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=${SITEINFO_BITS}
--enable-static-sqlite
+ ${S}/configure --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=${SITEINFO_BITS}
--enable-static-sqlite --without-rpath
fi
oe_runmake ${MAKEOPTS}
}
@@ -42,7 +42,7 @@ do_compile () {
do_compile_prepend_virtclass-native () {
if [ "${SITEINFO_BITS}" == "64" -a -e "/usr/include/gnu/stubs-32.h" -a "${PN}" ==
"pseudo-native" -a "${NO32LIBS}" != "1" ]; then
# We need the 32-bit libpseudo on a 64-bit machine...
- ./configure --prefix=${prefix}
--libdir=${prefix}/lib/pseudo/lib
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=32
+ ./configure --prefix=${prefix}
--libdir=${prefix}/lib/pseudo/lib
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=32 --without-rpath
oe_runmake ${MAKEOPTS} libpseudo
# prevent it from removing the lib, but remove everything else
make 'LIB=foo' ${MAKEOPTS} distclean
@@ -52,7 +52,7 @@ do_compile_prepend_virtclass-native () {
do_compile_prepend_virtclass-nativesdk () {
if [ "${SITEINFO_BITS}" == "64" -a -e "/usr/include/gnu/stubs-32.h" -a "${PN}" ==
"pseudo-native" -a "${NO32LIBS}" != "1" ]; then
# We need the 32-bit libpseudo on a 64-bit machine...
- ./configure --prefix=${prefix}
--libdir=${prefix}/lib/pseudo/lib
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=32
+ ./configure --prefix=${prefix}
--libdir=${prefix}/lib/pseudo/lib
--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=32 --without-rpath
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
/opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/pseudo -P
/opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr tar -C "/tmp/opt" -xjf
"/intel/home/sgw/Downloads/core-image-minimal-qemux86-64.tar.bz2"
tar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found
(required by
/opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/lib/pseudo/lib64/libpseudo.so)
See also bug 1968
I do have a libc.so.6.
/opt/poky/1.2/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 -> libc-2.15.so
Sau!
oe_runmake ${MAKEOPTS} libpseudo
# prevent it from removing the lib, but remove everything else
make 'LIB=foo' ${MAKEOPTS} distclean
diff --git a/meta/recipes-devtools/pseudo/pseudo_1.3.bb
b/meta/recipes-devtools/pseudo/pseudo_1.3.bb
index e7a329c..080b739 100644
--- a/meta/recipes-devtools/pseudo/pseudo_1.3.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_1.3.bb
@@ -1,6 +1,6 @@
require pseudo.inc
-PR = "r7"
+PR = "r8"
SRC_URI = "http://www.yoctoproject.org/downloads/${BPN}/${BPN}-${PV}.tar.bz2";
diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 9414c79..7857275 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -2,7 +2,7 @@ require pseudo.inc
SRCREV = "f0375c9aaefbccfd41aebbf6d332bb4d9e8f980c"
PV = "1.3+git${SRCPV}"
-PR = "r22"
+PR = "r23"
DEFAULT_PREFERENCE = "-1"
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Two small fixes, pseudo and rpm
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 rpm to somewhere which won't conflict with the rootfs (2012-04-12 21:24:55 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib mhatle/fixes http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/fixes Mark Hatle (2): pseudo: Tell pseudo to avoid specifying an RPATH rpm: Ensure that we check both providename and filepaths meta/recipes-devtools/pseudo/pseudo.inc|8 ++-- meta/recipes-devtools/pseudo/pseudo_1.3.bb |2 +- meta/recipes-devtools/pseudo/pseudo_git.bb |2 +- meta/recipes-devtools/rpm/rpm/rpm-resolvedep.patch | 36 meta/recipes-devtools/rpm/rpm_5.4.0.bb |3 +- 5 files changed, 44 insertions(+), 7 deletions(-) create mode 100644 meta/recipes-devtools/rpm/rpm/rpm-resolvedep.patch Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] default-distrovars: remove NO32LIBS setting
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 Eggleton
---
meta/conf/distro/include/default-distrovars.inc |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/meta/conf/distro/include/default-distrovars.inc
b/meta/conf/distro/include/default-distrovars.inc
index 16b3108..c38cd35 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -37,8 +37,6 @@ COMMON_LICENSE_DIR ??=
"${COREBASE}/meta/files/common-licenses"
BB_GENERATE_MIRROR_TARBALLS ??= "0"
-NO32LIBS ??= "1"
-
# Default to emitting logfiles if a build fails.
BBINCLUDELOGS ??= "yes"
SDK_VERSION ??= "oe-core.0"
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] pseudo: default NO32LIBS to 1
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 Eggleton
---
meta/recipes-devtools/pseudo/pseudo.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/pseudo/pseudo.inc
b/meta/recipes-devtools/pseudo/pseudo.inc
index d5c33df..d710058 100644
--- a/meta/recipes-devtools/pseudo/pseudo.inc
+++ b/meta/recipes-devtools/pseudo/pseudo.inc
@@ -24,7 +24,7 @@ do_configure () {
:
}
-NO32LIBS ??= "0"
+NO32LIBS ??= "1"
# Compile for the local machine arch...
do_compile () {
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2] gcc-4.6: Add fix for relocation problem and ccache
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 with preservation of the sysroot
option. See the gcc patch for more details. It only triggers when preprocessed
sources are used which happens when ccache is used.
The same issue occurs with c++ and c++-cpp-output so the same fix is applied
there.
[YOCTO #2074]
Signed-off-by: Richard Purdie
---
diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc
b/meta/recipes-devtools/gcc/gcc-4.6.inc
index d40a534..020e21b 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
@@ -1,6 +1,6 @@
require gcc-common.inc
-PR = "r24"
+PR = "r25"
# Third digit in PV should be incremented after a minor release
# happens from this branch on gcc e.g. currently its 4.6.0
@@ -73,6 +73,7 @@ SRC_URI =
"svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};proto=http \
file://gcc-arm-set-cost.patch \
file://GPLUSPLUS_INCLUDE_DIR_with_sysroot.patch \
file://fortran-cross-compile-hack.patch \
+ file://cpp-honour-sysroot.patch \
"
SRC_URI_append_sh3 = " file://sh3-installfix-fixheaders.patch "
diff --git a/meta/recipes-devtools/gcc/gcc-4.6/cpp-honour-sysroot.patch
b/meta/recipes-devtools/gcc/gcc-4.6/cpp-honour-sysroot.patch
new file mode 100644
index 000..4792c20
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-4.6/cpp-honour-sysroot.patch
@@ -0,0 +1,40 @@
+Currently, if the gcc toolchain is relocated and installed from sstate, then
you try and compile
+preprocessed source (.i or .ii files), the compiler will try and access the
builtin sysroot location
+rather than the --sysroot option specified on the commandline. If access to
that directory is
+permission denied (unreadable), gcc will error.
+
+This happens when ccache is in use due to the fact it uses preprocessed source
files.
+
+The fix below adds %I to the cpp-output spec macro so the default
substitutions for -iprefix,
+-isystem, -isysroot happen and the correct sysroot is used.
+
+[YOCTO #2074]
+
+Upstream-Status: Pending
+
+RP 2012/04/13
+
+Index: gcc-4_6-branch/gcc/gcc.c
+===
+--- gcc-4_6-branch.orig/gcc/gcc.c 2012-04-13 12:24:37.939671140 +
gcc-4_6-branch/gcc/gcc.c 2012-04-13 12:24:54.439670688 +
+@@ -953,7 +953,7 @@
+ %W{o*:--output-pch=%*}}%V}}", 0, 0, 0},
+ {".i", "@cpp-output", 0, 0, 0},
+ {"@cpp-output",
+- "%{!M:%{!MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)", 0, 0, 0},
++ "%{!M:%{!MM:%{!E:cc1 -fpreprocessed %i %I %(cc1_options)
%{!fsyntax-only:%(invoke_as)", 0, 0, 0},
+ {".s", "@assembler", 0, 0, 0},
+ {"@assembler",
+"%{!M:%{!MM:%{!E:%{!S:as %(asm_debug) %(asm_options) %i %A ", 0, 0, 0},
+Index: gcc-4_6-branch/gcc/cp/lang-specs.h
+===
+--- gcc-4_6-branch.orig/gcc/cp/lang-specs.h2012-04-13 12:25:01.019670594
+
gcc-4_6-branch/gcc/cp/lang-specs.h 2012-04-13 12:25:07.567670180 +
+@@ -64,5 +64,5 @@
+ {".ii", "@c++-cpp-output", 0, 0, 0},
+ {"@c++-cpp-output",
+"%{!M:%{!MM:%{!E:\
+-cc1plus -fpreprocessed %i %(cc1_options) %2\
++cc1plus -fpreprocessed %i %I %(cc1_options) %2\
+ %{!fsyntax-only:%(invoke_as)", 0, 0, 0},
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] base.bbclass: Fix PACKAGECONFIG issues with native and nativesdk BBCLASSEXTEND recipes (and multilib)
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 abstracted into lib/oe/classextend.py but
> at this point in release more invasive changes like this are inappropriate.
>
> This patch also removed empty strings from expressions rather than
> passing them around as this was complicating the additional code
> unnecessarily.
>
> The patch was verified against the OE-Core metadata where the return values
> of
> expandFilter() were sanity checked by hand for native/nativesdk and
> multilib combinations.
I can confirm it also fixes gtk+-native depends, cannot do more tests
now.
meta-oe people could be interested in this patch
http://git.openembedded.org/meta-openembedded-contrib/commit/?h=jansa/xorg&id=1ab99af784f5f1564f28f6afc4718d630b42a606
when this change hits oe-core
> [YOCTO #2225]
>
> Signed-off-by: Richard Purdie
> ---
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index 2e8a0b0..3c9d76c 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -305,9 +305,32 @@ python () {
> pkgconfigflags = d.getVarFlags("PACKAGECONFIG") or {}
> if pkgconfigflags:
> pkgconfig = (d.getVar('PACKAGECONFIG', True) or "").split()
> +pn = d.getVar("PN", True)
> +mlprefix = d.getVar("MLPREFIX", True)
> +
> +def expandFilter(appends, extension, prefix):
> +appends = bb.utils.explode_deps(d.expand(" ".join(appends)))
> +newappends = []
> +for a in appends:
> + if a.endswith("-native") or a.endswith("-cross"):
> + newappends.append(a)
> + elif a.startswith("virtual/"):
> + subs = a.split("/", 1)[1]
> + newappends.append("virtual/" + prefix + subs + extension)
> + else:
> + newappends.append(prefix + a + extension)
> +return newappends
> +
> def appendVar(varname, appends):
> if not appends:
> return
> +if varname.find("DEPENDS") != -1:
> +if pn.endswith("-nativesdk"):
> +appends = expandFilter(appends, "-nativesdk", "")
> +if pn.endswith("-native"):
> +appends = expandFilter(appends, "-native", "")
> +if mlprefix:
> +appends = expandFilter(appends, "", mlprefix)
> varname = d.expand(varname)
> d.appendVar(varname, " " + " ".join(appends))
>
> @@ -324,11 +347,14 @@ python () {
> elif len(items) == 4:
> enable, disable, depend, rdepend = items
> if flag in pkgconfig:
> -extradeps.append(depend)
> -extrardeps.append(rdepend)
> -extraconf.append(enable)
> -else:
> -extraconf.append(disable)
> +if depend:
> +extradeps.append(depend)
> +if rdepend:
> +extrardeps.append(rdepend)
> +if enable:
> +extraconf.append(enable)
> +elif disable:
> +extraconf.append(disable)
> appendVar('DEPENDS', extradeps)
> appendVar('RDEPENDS_${PN}', extrardeps)
> appendVar('EXTRA_OECONF', extraconf)
>
>
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] default-distrovars: remove NO32LIBS setting
The ??= assignment in pseudo.inc effectively nullifies this ??=
assignment here, so remove it.
Signed-off-by: Paul Eggleton
---
meta/conf/distro/include/default-distrovars.inc |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/meta/conf/distro/include/default-distrovars.inc
b/meta/conf/distro/include/default-distrovars.inc
index 16b3108..c38cd35 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -37,8 +37,6 @@ COMMON_LICENSE_DIR ??=
"${COREBASE}/meta/files/common-licenses"
BB_GENERATE_MIRROR_TARBALLS ??= "0"
-NO32LIBS ??= "1"
-
# Default to emitting logfiles if a build fails.
BBINCLUDELOGS ??= "yes"
SDK_VERSION ??= "oe-core.0"
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] pseudo: default NO32LIBS to 1
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
---
meta/recipes-devtools/pseudo/pseudo.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/pseudo/pseudo.inc
b/meta/recipes-devtools/pseudo/pseudo.inc
index d5c33df..d710058 100644
--- a/meta/recipes-devtools/pseudo/pseudo.inc
+++ b/meta/recipes-devtools/pseudo/pseudo.inc
@@ -24,7 +24,7 @@ do_configure () {
:
}
-NO32LIBS ??= "0"
+NO32LIBS ??= "1"
# Compile for the local machine arch...
do_compile () {
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [V5 2/2] PR bump packages with gdbm in DEPENDS
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
Acked-by: Martin Jansa
> ---
> 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 |2 +-
> meta/recipes-support/apr/apr-util_1.4.1.bb |2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-devtools/perl/perl_5.14.2.bb
> b/meta/recipes-devtools/perl/perl_5.14.2.bb
> index 92ca9b8..8f3ad25 100644
> --- a/meta/recipes-devtools/perl/perl_5.14.2.bb
> +++ b/meta/recipes-devtools/perl/perl_5.14.2.bb
> @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
> "file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \
> # We need gnugrep (for -I)
> DEPENDS = "virtual/db grep-native"
> DEPENDS += "gdbm zlib"
> -PR = "r4"
> +PR = "r5"
>
> # 5.10.1 has Module::Build built-in
> PROVIDES += "libmodule-build-perl"
> diff --git a/meta/recipes-devtools/python/python_2.7.2.bb
> b/meta/recipes-devtools/python/python_2.7.2.bb
> index d1d0d83..0a1708a 100644
> --- a/meta/recipes-devtools/python/python_2.7.2.bb
> +++ b/meta/recipes-devtools/python/python_2.7.2.bb
> @@ -1,6 +1,6 @@
> require python.inc
> DEPENDS = "python-native bzip2 db gdbm openssl readline sqlite3 zlib"
> -PR = "${INC_PR}.10"
> +PR = "${INC_PR}.11"
>
> DISTRO_SRC_URI ?= "file://sitecustomize.py"
> DISTRO_SRC_URI_linuxstdbase = ""
> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
> b/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
> index e98a591..fd61149 100644
> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
> @@ -1,6 +1,6 @@
> require pulseaudio.inc
>
> -PR = "r7"
> +PR = "r8"
>
> DEPENDS += "libjson gdbm speex libxml-parser-perl-native"
>
> diff --git a/meta/recipes-support/apr/apr-util_1.4.1.bb
> b/meta/recipes-support/apr/apr-util_1.4.1.bb
> index 029cf7e..deb608f 100644
> --- a/meta/recipes-support/apr/apr-util_1.4.1.bb
> +++ b/meta/recipes-support/apr/apr-util_1.4.1.bb
> @@ -9,7 +9,7 @@ LICENSE = "Apache-2.0"
> LIC_FILES_CHKSUM = "file://LICENSE;md5=519e0a18e03f7c023070568c14b077bb \
>
> file://include/apu_version.h;endline=17;md5=806685a84e71f10c80144c48eb35df42"
>
> -PR = "r0"
> +PR = "r1"
>
> SRC_URI = "${APACHE_MIRROR}/apr/${BPN}-${PV}.tar.gz \
> file://configfix.patch \
> --
> 1.7.5.4
>
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [V5 1/2] gdbm: Package compat libs in gdbm-compat
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
Acked-by: Martin Jansa
> ---
> meta/recipes-support/gdbm/gdbm_1.10.bb |7 ++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/meta/recipes-support/gdbm/gdbm_1.10.bb
> b/meta/recipes-support/gdbm/gdbm_1.10.bb
> index 26b8009..6b68d27 100644
> --- a/meta/recipes-support/gdbm/gdbm_1.10.bb
> +++ b/meta/recipes-support/gdbm/gdbm_1.10.bb
> @@ -4,7 +4,7 @@ SECTION = "libs"
> LICENSE = "GPLv3"
> LIC_FILES_CHKSUM = "file://COPYING;md5=241da1b9fe42e642cbb2c24d5e0c4d24"
>
> -PR = "r2"
> +PR = "r3"
>
> SRC_URI = "${GNU_MIRROR}/gdbm/gdbm-${PV}.tar.gz"
>
> @@ -25,3 +25,8 @@ do_install_append () {
> ln -sf ../ndbm.h ${D}/${includedir}/gdbm/ndbm.h
> ln -sf ../gdbm.h ${D}/${includedir}/gdbm/gdbm.h
> }
> +
> +PACKAGES =+ "${PN}-compat \
> +"
> +FILES_${PN}-compat = "${libdir}/libgdbm_compat${SOLIBS} \
> + "
> --
> 1.7.5.4
>
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gcc-4.6: Add fix for relocation problem and ccache
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 with preservation of the sysroot
option. See the gcc patch for more details. It only triggers when preprocessed
sources are used which happens when ccache is used.
[YOCTO #2074]
Signed-off-by: Richard Purdie
---
diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc
b/meta/recipes-devtools/gcc/gcc-4.6.inc
index d40a534..3b2e97e 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
@@ -73,6 +73,7 @@ SRC_URI =
"svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};proto=http \
file://gcc-arm-set-cost.patch \
file://GPLUSPLUS_INCLUDE_DIR_with_sysroot.patch \
file://fortran-cross-compile-hack.patch \
+ file://cpp-honour-sysroot.patch \
"
SRC_URI_append_sh3 = " file://sh3-installfix-fixheaders.patch "
diff --git a/meta/recipes-devtools/gcc/gcc-4.6/cpp-honour-sysroot.patch
b/meta/recipes-devtools/gcc/gcc-4.6/cpp-honour-sysroot.patch
new file mode 100644
index 000..808596f
--- a/dev/null
+++ b/meta/recipes-devtools/gcc/gcc-4.6/cpp-honour-sysroot.patch
@@ -0,0 +1,29 @@
+Currently, if the gcc toolchain is relocated and installed from sstate, then
you try and compile
+preprocessed source (.i files), the compiler will try and access the builtin
sysroot location
+rather than the --sysroot option specified on the commandline. If access to
that directory is
+permission denied (unreadable), gcc will error.
+
+This happens when ccache is in use due to the fact it uses preprocessed source
files.
+
+The fix below adds %I to the cpp-output spec macro so the default sustitutions
for -iprefix,
+-isystem, -isysroot happen and the correct sysroot is used.
+
+[YOCTO #2074]
+
+Upstream-Status: Pending
+
+RP 2012/04/13
+
+Index: gcc-4_6-branch/gcc/gcc.c
+===
+--- gcc-4_6-branch.orig/gcc/gcc.c 2012-04-13 11:21:23.119758988 +
gcc-4_6-branch/gcc/gcc.c 2012-04-13 11:21:54.095758269 +
+@@ -953,7 +953,7 @@
+ %W{o*:--output-pch=%*}}%V}}", 0, 0, 0},
+ {".i", "@cpp-output", 0, 0, 0},
+ {"@cpp-output",
+- "%{!M:%{!MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)", 0, 0, 0},
++ "%{!M:%{!MM:%{!E:cc1 -fpreprocessed %i %I %(cc1_options)
%{!fsyntax-only:%(invoke_as)", 0, 0, 0},
+ {".s", "@assembler", 0, 0, 0},
+ {"@assembler",
+"%{!M:%{!MM:%{!E:%{!S:as %(asm_debug) %(asm_options) %i %A ", 0, 0, 0},
--
cgit 0.9.0.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] eglibc: fix re-execution of task
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 Gollamudi
---
meta/recipes-core/eglibc/eglibc_2.13.bb |8
meta/recipes-core/eglibc/eglibc_2.15.bb |8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc_2.13.bb
b/meta/recipes-core/eglibc/eglibc_2.13.bb
index 927f72f..872767e 100644
--- a/meta/recipes-core/eglibc/eglibc_2.13.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.13.bb
@@ -141,7 +141,7 @@ do_fix_ia_headers() {
cp ${S}/sysdeps/unix/sysv/linux/x86_64/bits/environments.h
${S}/sysdeps/unix/sysv/linux/i386/bits/environments.h
cp ${S}/sysdeps/unix/sysv/linux/x86_64/bits/fcntl.h
${S}/sysdeps/unix/sysv/linux/i386/bits/fcntl.h
cp ${S}/sysdeps/x86_64/fpu/bits/fenv.h ${S}/sysdeps/i386/fpu/bits/fenv.h
- rm ${S}/sysdeps/i386/bits/huge_vall.h
+ rm -f ${S}/sysdeps/i386/bits/huge_vall.h
cp ${S}/sysdeps/x86_64/bits/link.h ${S}/sysdeps/i386/bits/link.h
cp ${S}/sysdeps/x86_64/bits/mathdef.h ${S}/sysdeps/i386/bits/mathdef.h
cp ${S}/sysdeps/x86_64/fpu/bits/mathinline.h
${S}/sysdeps/i386/fpu/bits/mathinline.h
@@ -150,14 +150,14 @@ do_fix_ia_headers() {
cp ${S}/nptl/sysdeps/unix/sysv/linux/x86_64/bits/pthreadtypes.h
${S}/nptl/sysdeps/unix/sysv/linux/i386/bits/pthreadtypes.h
cp ${S}/sysdeps/x86_64/bits/select.h ${S}/sysdeps/i386/bits/select.h
cp ${S}/nptl/sysdeps/unix/sysv/linux/x86_64/bits/semaphore.h
${S}/nptl/sysdeps/unix/sysv/linux/i386/bits/semaphore.h
- rm ${S}/sysdeps/unix/sysv/linux/x86_64/bits/sem.h
+ rm -f ${S}/sysdeps/unix/sysv/linux/x86_64/bits/sem.h
cp ${S}/sysdeps/x86_64/bits/setjmp.h ${S}/sysdeps/i386/bits/setjmp.h
cp ${S}/sysdeps/unix/sysv/linux/x86_64/bits/shm.h
${S}/sysdeps/unix/sysv/linux/i386/bits/shm.h
cp ${S}/sysdeps/unix/sysv/linux/x86_64/bits/sigcontext.h
${S}/sysdeps/unix/sysv/linux/i386/bits/sigcontext.h
cp ${S}/sysdeps/unix/sysv/linux/x86_64/bits/stat.h
${S}/sysdeps/unix/sysv/linux/i386/bits/stat.h
- rm ${S}/sysdeps/i386/i486/bits/string.h ; cp
${S}/sysdeps/x86_64/bits/string.h ${S}/sysdeps/i386/bits/string.h
+ rm -f ${S}/sysdeps/i386/i486/bits/string.h ; cp
${S}/sysdeps/x86_64/bits/string.h ${S}/sysdeps/i386/bits/string.h
# Skip syscall.h, see do_install
- rm ${S}/sysdeps/unix/sysv/linux/i386/bits/wchar.h
+ rm -f ${S}/sysdeps/unix/sysv/linux/i386/bits/wchar.h
cp ${S}/sysdeps/x86_64/bits/wordsize.h ${S}/sysdeps/i386/bits/wordsize.h
cp ${S}/sysdeps/x86_64/bits/xtitypes.h ${S}/sysdeps/i386/bits/xtitypes.h
# i386 version is correct, x86_64 is incorrect for fpu_control.h
diff --git a/meta/recipes-core/eglibc/eglibc_2.15.bb
b/meta/recipes-core/eglibc/eglibc_2.15.bb
index 1575e7f..dd04378 100644
--- a/meta/recipes-core/eglibc/eglibc_2.15.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.15.bb
@@ -154,7 +154,7 @@ do_fix_ia_headers() {
cp ${S}/sysdeps/unix/sysv/linux/x86_64/bits/environments.h
${S}/sysdeps/unix/sysv/linux/i386/bits/environments.h
cp ${S}/sysdeps/unix/sysv/linux/x86_64/bits/fcntl.h
${S}/sysdeps/unix/sysv/linux/i386/bits/fcntl.h
cp ${S}/sysdeps/x86_64/fpu/bits/fenv.h ${S}/sysdeps/i386/fpu/bits/fenv.h
- rm ${S}/sysdeps/i386/bits/huge_vall.h
+ rm -f ${S}/sysdeps/i386/bits/huge_vall.h
cp ${S}/sysdeps/x86_64/bits/link.h ${S}/sysdeps/i386/bits/link.h
cp ${S}/sysdeps/x86_64/bits/mathdef.h ${S}/sysdeps/i386/bits/mathdef.h
cp ${S}/sysdeps/x86_64/fpu/bits/mathinline.h
${S}/sysdeps/i386/fpu/bits/mathinline.h
@@ -163,14 +163,14 @@ do_fix_ia_headers() {
cp ${S}/nptl/sysdeps/unix/sysv/linux/x86_64/bits/pthreadtypes.h
${S}/nptl/sysdeps/unix/sysv/linux/i386/bits/pthreadtypes.h
cp ${S}/sysdeps/x86_64/bits/select.h ${S}/sysdeps/i386/bits/select.h
cp ${S}/nptl/sysdeps/unix/sysv/linux/x86_64/bits/semaphore.h
${S}/nptl/sysdeps/unix/sysv/linux/i386/bits/semaphore.h
- rm ${S}/sysdeps/unix/sysv/linux/x86_64/bits/sem.h
+ rm -f ${S}/sysdeps/unix/sysv/linux/x86_64/bits/sem.h
cp ${S}/sysdeps/x86_64/bits/setjmp.h ${S}/sysdeps/i386/bits/setjmp.h
cp ${S}/sysdeps/unix/sysv/linux/x86_64/bits/shm.h
${S}/sysdeps/unix/sysv/linux/i386/bits/shm.h
cp ${S}/sysdeps/unix/sysv/linux/x86_64/bits/sigcontext.h
${S}/sysdeps/unix/sysv/linux/i386/bits/sigcontext.h
cp ${S}/sysdeps/unix/sysv/linux/x86_64/bits/stat.h
${S}/sysdeps/unix/sysv/linux/i386/bits/stat.h
- rm ${S}/sysdeps/i386/i486/bits/string.h ; cp
${S}/sysdeps/x86_64/bits/string.h ${S}/sysdeps/i386/bits/string.h
+ rm -f ${S}/sysdeps/i386/i486/bits/string.h ; cp
${S}/sysdeps/x86_64/bits/string.h ${S}/sysdeps/i386/bits/string.h
[OE-core] [PATCH] boost: fix re-execution of task
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
re-execution
there by failing the compilation.
The patch fixes adding multiple "Using gcc" entries into
/tools/build/v2/user-config.jam
[Yocto #2194]
Signed-off-by: Venkata Ramana Gollamudi
---
meta/recipes-support/boost/boost.inc |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-support/boost/boost.inc
b/meta/recipes-support/boost/boost.inc
index d70a7e2..c9306df 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -135,7 +135,11 @@ BJAM_OPTS= '${BJAM_TOOLS} \
do_boostconfig() {
cp -f boost/config/platform/linux.hpp
boost/config/platform/linux-gnueabi.hpp
- echo 'using gcc : 4.3.1 : ${CXX} : compileflags -DBOOST_SP_USE_PTHREADS
-I${includedir} linkflags -L${libdir} ;' >> ${S}/tools/build/v2/user-config.jam
+ # D2194:Fixing the failure of "error: duplicate initialization of gcc
with the following parameters" during compilation.
+ if ! grep -qe "^using gcc : 4.3.1" ${S}/tools/build/v2/user-config.jam
+ then
+ echo 'using gcc : 4.3.1 : ${CXX} : compileflags
-DBOOST_SP_USE_PTHREADS -I${includedir} linkflags -L${libdir} ;' >>
${S}/tools/build/v2/user-config.jam
+ fi
}
addtask do_boostconfig after do_patch before do_configure
--
1.7.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] perl: fix re-execution of task
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
will be also be modified individually.
Fix done to ignore the path correction during do_configure,
if file is a link.
[Yocto #2194]
Signed-off-by: Venkata Ramana Gollamudi
---
meta/recipes-devtools/perl/perl_5.14.2.bb |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/perl/perl_5.14.2.bb
b/meta/recipes-devtools/perl/perl_5.14.2.bb
index 92ca9b8..414aa22 100644
--- 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 ":"` ; do
-echo Fixing: $foo
-sed -e "s%/usr/include/%${STAGING_INCDIR}/%g" -i $foo
+ # 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
+ if [ ! -h $foo ]; then
+ echo Fixing: $foo
+ sed -e "s%/usr/include/%${STAGING_INCDIR}/%g" -i $foo
+ fi
done
rm -f config
--
1.7.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] qt4-x11-free: enable -accessibility and -sm
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 Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Yocto Project 1.2 M4 schedule
On Thu, Apr 12, 2012 at 21:46, Philip Balister 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 wrote: You just volunteered to handle all the "Does it work with yocto 1.2?" questions :) Simply put: people are stupid, they need explicit PHB compliant names in tags, even if it isn't 100% politically correct to say "yocto" when we actually mean "oe-core". Unless the yocto 1.2 release note state that it's based on oe-core "foo" and all layers compatible with "foo" use "foo" in tags/branches. >>> >>> I think layers ought to have tags for both ... >>> >>> -oe-core- >>> -yocto- >> >> This would be rather sad if it were necessary. The whole point is we're >> trying to build things which are compatible with each other. If that >> turns out not to be the case I want to fix it, not encourage it. > > We need a coherent tag name to use across layers. The Yocto Project is > the umbrella project, so using the yocto-project in the tag name is a > good way to show this coordination among projects to people not familiar > with how things are working. (As Koen notes, this makes communication > with people whose primary exposure to the Yocto Project is watching > youtube videos) I'm also in favor of a yocto-project-1.2 tag, for the same reason as Koen and Philip mention. That would make it easier communicating with customers and PHB's that has heard of Yocto Project... > I do not want to see table containing Yocto Project release information > and they relate to a set of seemingly random tags in other layers. The risk for this is definitely somewhat higher with a strict -XX release tag (which also might collide with other projects/layer more easily). Thus, I'm advocating a 'yocto-project'-prefix for the tags in question. /Anders ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [V4 2/2] PR bump packages with gdbm in DEPENDS
On Fri, Apr 13, 2012 at 11:03, Martin Jansa 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
> > ---
> > 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 |2 +-
> > meta/recipes-support/apr/apr-util_1.4.1.bb |2 +-
> > 4 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git
> > a/meta/recipes-devtools/perl/perl_5.14.2.bbb/meta/recipes-devtools/perl/
> perl_5.14.2.bb
> > index 92ca9b8..8f3ad25 100644
> > --- a/meta/recipes-devtools/perl/perl_5.14.2.bb
> > +++ b/meta/recipes-devtools/perl/perl_5.14.2.bb
> > @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
> "file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \
> > # We need gnugrep (for -I)
> > DEPENDS = "virtual/db grep-native"
> > DEPENDS += "gdbm zlib"
> > -PR = "r4"
> > +PR = "r5"
> >
> > # 5.10.1 has Module::Build built-in
> > PROVIDES += "libmodule-build-perl"
> > diff --git
> > a/meta/recipes-devtools/python/python_2.7.2.bbb/meta/recipes-devtools/python/
> python_2.7.2.bb
> > index a3a2c96..00a5558 100644
> > --- a/meta/recipes-devtools/python/python_2.7.2.bb
> > +++ b/meta/recipes-devtools/python/python_2.7.2.bb
> > @@ -1,6 +1,6 @@
> > require python.inc
> > DEPENDS = "python-native bzip2 db gdbm openssl readline sqlite3 zlib"
> > -PR = "${INC_PR}.14"
> > +PR = "${INC_PR}.15"
>
> This does not apply
>
> current PR is:
> PR = "${INC_PR}.10"
>
> http://git.openembedded.org/openembedded-core/log/meta/recipes-devtools/python/python_2.7.2.bb
>
> so no idea where you got 'PR = "${INC_PR}.14"'
>
> Cheers,
>
>
Thank you Martin. V5 sent.
@g
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [V5 2/2] PR bump packages with gdbm in DEPENDS
This is done because of this change in gdbm:
"gdbm: Package compat libs in gdbm-compat"
Signed-off-by: Andrei Gherzan
---
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 |2 +-
meta/recipes-support/apr/apr-util_1.4.1.bb |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-devtools/perl/perl_5.14.2.bb
b/meta/recipes-devtools/perl/perl_5.14.2.bb
index 92ca9b8..8f3ad25 100644
--- a/meta/recipes-devtools/perl/perl_5.14.2.bb
+++ b/meta/recipes-devtools/perl/perl_5.14.2.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
"file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \
# We need gnugrep (for -I)
DEPENDS = "virtual/db grep-native"
DEPENDS += "gdbm zlib"
-PR = "r4"
+PR = "r5"
# 5.10.1 has Module::Build built-in
PROVIDES += "libmodule-build-perl"
diff --git a/meta/recipes-devtools/python/python_2.7.2.bb
b/meta/recipes-devtools/python/python_2.7.2.bb
index d1d0d83..0a1708a 100644
--- a/meta/recipes-devtools/python/python_2.7.2.bb
+++ b/meta/recipes-devtools/python/python_2.7.2.bb
@@ -1,6 +1,6 @@
require python.inc
DEPENDS = "python-native bzip2 db gdbm openssl readline sqlite3 zlib"
-PR = "${INC_PR}.10"
+PR = "${INC_PR}.11"
DISTRO_SRC_URI ?= "file://sitecustomize.py"
DISTRO_SRC_URI_linuxstdbase = ""
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
b/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
index e98a591..fd61149 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
@@ -1,6 +1,6 @@
require pulseaudio.inc
-PR = "r7"
+PR = "r8"
DEPENDS += "libjson gdbm speex libxml-parser-perl-native"
diff --git a/meta/recipes-support/apr/apr-util_1.4.1.bb
b/meta/recipes-support/apr/apr-util_1.4.1.bb
index 029cf7e..deb608f 100644
--- a/meta/recipes-support/apr/apr-util_1.4.1.bb
+++ b/meta/recipes-support/apr/apr-util_1.4.1.bb
@@ -9,7 +9,7 @@ LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=519e0a18e03f7c023070568c14b077bb \
file://include/apu_version.h;endline=17;md5=806685a84e71f10c80144c48eb35df42"
-PR = "r0"
+PR = "r1"
SRC_URI = "${APACHE_MIRROR}/apr/${BPN}-${PV}.tar.gz \
file://configfix.patch \
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [V5 1/2] gdbm: Package compat libs in gdbm-compat
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
---
meta/recipes-support/gdbm/gdbm_1.10.bb |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-support/gdbm/gdbm_1.10.bb
b/meta/recipes-support/gdbm/gdbm_1.10.bb
index 26b8009..6b68d27 100644
--- a/meta/recipes-support/gdbm/gdbm_1.10.bb
+++ b/meta/recipes-support/gdbm/gdbm_1.10.bb
@@ -4,7 +4,7 @@ SECTION = "libs"
LICENSE = "GPLv3"
LIC_FILES_CHKSUM = "file://COPYING;md5=241da1b9fe42e642cbb2c24d5e0c4d24"
-PR = "r2"
+PR = "r3"
SRC_URI = "${GNU_MIRROR}/gdbm/gdbm-${PV}.tar.gz"
@@ -25,3 +25,8 @@ do_install_append () {
ln -sf ../ndbm.h ${D}/${includedir}/gdbm/ndbm.h
ln -sf ../gdbm.h ${D}/${includedir}/gdbm/gdbm.h
}
+
+PACKAGES =+ "${PN}-compat \
+"
+FILES_${PN}-compat = "${libdir}/libgdbm_compat${SOLIBS} \
+ "
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [V5 0/2] Package gdbm compat libs in gdbm-compat and PR bumps
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 (2012-04-12 21:25:10 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib ag/gdbm http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ag/gdbm Andrei Gherzan (2): gdbm: Package compat libs in gdbm-compat PR bump packages with gdbm in DEPENDS 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 |2 +- meta/recipes-support/apr/apr-util_1.4.1.bb |2 +- meta/recipes-support/gdbm/gdbm_1.10.bb |7 ++- 5 files changed, 10 insertions(+), 5 deletions(-) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Dexuan: nspr: fix package splitin
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 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/master Dexuan Cui (1): nspr: fix package spliting meta/recipes-support/nspr/nspr_4.8.9.bb |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] nspr: fix package spliting
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
---
meta/recipes-support/nspr/nspr_4.8.9.bb |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-support/nspr/nspr_4.8.9.bb
b/meta/recipes-support/nspr/nspr_4.8.9.bb
index 8b840d9..d3c683c 100644
--- a/meta/recipes-support/nspr/nspr_4.8.9.bb
+++ b/meta/recipes-support/nspr/nspr_4.8.9.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM =
"file://configure.in;beginline=3;endline=40;md5=99d4d7d68bbc4
file://Makefile.in;beginline=4;endline=38;md5=c2b512182a334e1bfa1edc4d1c84a298 "
SECTION = "libs/network"
-PR = "r2"
+PR = "r3"
SRC_URI =
"ftp://ftp.mozilla.org/pub/mozilla.org/nspr/releases/v${PV}/src/nspr-${PV}.tar.gz
\
file://remove-rpath-from-tests.patch \
@@ -160,6 +160,7 @@ do_install_append() {
install -m 0755 ${TESTS} ${D}${libdir}/nspr/tests
}
-FILES_${PN} = "${bindir}/*"
-FILES_${PN}-dev += "${libdir}/nspr/tests/*"
+FILES_${PN} = "${bindir}/* ${libdir}/lib*.so"
+FILES_${PN}-dev = "${libdir}/nspr/tests/* ${libdir}/pkgconfig \
+${includedir}/* ${datadir}/aclocal/* "
FILES_${PN}-dbg += "${libdir}/nspr/tests/.debug/*"
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] cleanup-workdir
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
>> (archs) than the current one. I guess the list of architectures to
>> handle should be queried from bitbake to avoid this.
> Do you mean that you build for 2 archs under the same "build" directory?
I have two build directories, one for each machine, sharing a single tmp
directory.
The basic layout looks roughly like this:
$OE/build/machineA/conf/local.conf
$OE/build/machineB/conf/local.conf
$OE/tmp/work/
> Even in this way the script only delete the packages' build dir for old
> versions.
That's right, but different machines may have different versions due to
COMPATIBLE_MACHINE settings. In my setup, there's also a layer for each
machine, which contains hardware drivers etc. Although every machine
provides the same set of drivers (same ${PN}), the versions differ slightly.
> Your requirement is that cleanup-workdir just clean the build dirs for
> current arch, right?
Yes. For each arch listed in PACKAGE_ARCHS (or
ALL_MULTILIB_PACKAGE_ARCHS?) for the current machine.
>> 2.) It doesn't delete work directories of previously deleted recipes.
> Because when the recipe gone, I can NOT tell whether the directory is
> left by bitbake or created by user.
> I will list them and let user to choose delete them or not.
It should be safe to assume that there are no directories created by the
user, as tmp/work is known to be managed by OE. However, recipes don't
disappear very often, so asking the user seems to be fine.
Regards,
Andreas
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] grub 1.99: fix build for gcc 4.7
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" with MACHINE = qemuarm/qemuppc/qemux86 and "bitbake world" with MACHINE = qemux86 on Fedora 17 64bit this Here should be: MACHINE = qemux86-64 // Robert night. Test info: Have tested on: Ubuntu 10.10 Fedora 13/16/17 x86_64 // Robert The following changes since commit 71e95c744eaa4dda1b3237db2e13f666f121c92b: package_rpm.bbclass: Set tmppath for rpm to somewhere which won't conflict with the rootfs (2012-04-12 21:24:55 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib robert/grub http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/grub Robert Yang (1): grub 1.99: fix build for gcc 4.7 meta/recipes-bsp/grub/grub_1.99.bb |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] grub 1.99: fix build for gcc 4.7
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 the compile command between gcc 4.4.4 and gcc 4.7.0, they
are the same (both of them have -Wall and -Werror), it seems that gcc
4.7.0 has changed its algorithm for the strict aliasing check, but I
didn't find the related information from its release note.
Add "-fno-strict-aliasing" to gcc's option would fix the problem, this
would disable the optimization for strict-aliasing.
[YOCTO #2291]
Signed-off-by: Robert Yang
---
meta/recipes-bsp/grub/grub_1.99.bb |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-bsp/grub/grub_1.99.bb
b/meta/recipes-bsp/grub/grub_1.99.bb
index ac66e83..f45b634 100644
--- a/meta/recipes-bsp/grub/grub_1.99.bb
+++ b/meta/recipes-bsp/grub/grub_1.99.bb
@@ -12,7 +12,7 @@ LICENSE = "GPLv3"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
RDEPENDS_${PN} = "diffutils freetype"
-PR = "r3"
+PR = "r4"
SRC_URI = "ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
file://grub-install.in.patch \
@@ -29,6 +29,11 @@ inherit gettext
EXTRA_OECONF = "--with-platform=pc --disable-grub-mkfont
--target=${TARGET_ARCH} --program-prefix="""
do_configure() {
+# Fix build error for gcc 4.7
+echo "CPPFLAGS_DEFAULT += -fno-strict-aliasing" >> conf/Makefile.common
+# Also modify Makefile.in, we can remove this when we can run autoreconf
+sed -i 's/^CPPFLAGS_DEFAULT = \(.*\)/CPPFLAGS_DEFAULT =
-fno-strict-aliasing \1/' \
+ Makefile.in grub-core/Makefile.in
oe_runconf
}
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] grub 1.99: fix build for gcc 4.7
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 info: Have tested on: Ubuntu 10.10 Fedora 13/16/17 x86_64 // Robert The following changes since commit 71e95c744eaa4dda1b3237db2e13f666f121c92b: package_rpm.bbclass: Set tmppath for rpm to somewhere which won't conflict with the rootfs (2012-04-12 21:24:55 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib robert/grub http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/grub Robert Yang (1): grub 1.99: fix build for gcc 4.7 meta/recipes-bsp/grub/grub_1.99.bb |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] gcc-cross: Argument list too long
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: > > $ grep PATH_MAX /usr/include/linux/limits.h > #define PATH_MAX4096/* # chars in a path name including nul */ > > I don't think it's worth to fix the do_install of gcc-cross, but it would > be good if we can add a check in oe-init-build-env or meta/classes > /sanity.bbclass to check wether the TMPDIR(or build directory) is longer than > a > reasonable vaule, e.g., 1/16th or 1/32th of PATH_MAX? If you are OK with this, > I'd like to work on it. > > To reproduce the error: > > $ cd /path/to/workdir/ > $ for i in `seq 20`; do mkdir _23_5_78_; cd _23_5_78_; done > $ source /path/to/poky/oe-init-build-env > $ bitbake gcc-cross > > Then the error comes. > > $ pwd | wc -c > 224 I think sanity.bbclass would be a good place to have a one time check of the length of TMPDIR... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [V4 2/2] PR bump packages with gdbm in DEPENDS
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
> ---
> 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 |2 +-
> meta/recipes-support/apr/apr-util_1.4.1.bb |2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-devtools/perl/perl_5.14.2.bb
> b/meta/recipes-devtools/perl/perl_5.14.2.bb
> index 92ca9b8..8f3ad25 100644
> --- a/meta/recipes-devtools/perl/perl_5.14.2.bb
> +++ b/meta/recipes-devtools/perl/perl_5.14.2.bb
> @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
> "file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \
> # We need gnugrep (for -I)
> DEPENDS = "virtual/db grep-native"
> DEPENDS += "gdbm zlib"
> -PR = "r4"
> +PR = "r5"
>
> # 5.10.1 has Module::Build built-in
> PROVIDES += "libmodule-build-perl"
> diff --git a/meta/recipes-devtools/python/python_2.7.2.bb
> b/meta/recipes-devtools/python/python_2.7.2.bb
> index a3a2c96..00a5558 100644
> --- a/meta/recipes-devtools/python/python_2.7.2.bb
> +++ b/meta/recipes-devtools/python/python_2.7.2.bb
> @@ -1,6 +1,6 @@
> require python.inc
> DEPENDS = "python-native bzip2 db gdbm openssl readline sqlite3 zlib"
> -PR = "${INC_PR}.14"
> +PR = "${INC_PR}.15"
This does not apply
current PR is:
PR = "${INC_PR}.10"
http://git.openembedded.org/openembedded-core/log/meta/recipes-devtools/python/python_2.7.2.bb
so no idea where you got 'PR = "${INC_PR}.14"'
Cheers,
>
> DISTRO_SRC_URI ?= "file://sitecustomize.py"
> DISTRO_SRC_URI_linuxstdbase = ""
> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
> b/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
> index e98a591..fd61149 100644
> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
> @@ -1,6 +1,6 @@
> require pulseaudio.inc
>
> -PR = "r7"
> +PR = "r8"
>
> DEPENDS += "libjson gdbm speex libxml-parser-perl-native"
>
> diff --git a/meta/recipes-support/apr/apr-util_1.4.1.bb
> b/meta/recipes-support/apr/apr-util_1.4.1.bb
> index 029cf7e..deb608f 100644
> --- a/meta/recipes-support/apr/apr-util_1.4.1.bb
> +++ b/meta/recipes-support/apr/apr-util_1.4.1.bb
> @@ -9,7 +9,7 @@ LICENSE = "Apache-2.0"
> LIC_FILES_CHKSUM = "file://LICENSE;md5=519e0a18e03f7c023070568c14b077bb \
>
> file://include/apu_version.h;endline=17;md5=806685a84e71f10c80144c48eb35df42"
>
> -PR = "r0"
> +PR = "r1"
>
> SRC_URI = "${APACHE_MIRROR}/apr/${BPN}-${PV}.tar.gz \
> file://configfix.patch \
> --
> 1.7.5.4
>
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Yocto Project 1.2 M4 schedule
On Apr 13, 2012 12:30 AM, "Phil Blundell" 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 waste of time. It's > only a name, after all. This is Richard's project and I think he should > probably just pick a tag name that he likes and be done with it. > One vote for this! > p. > > > > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
