Re: [OE-core] [denzil 11/18] qemu-0.15.1: add patch to fix compilatation problems on powerpc
On Thu, Feb 7, 2013 at 5:56 PM, Mark Hatle mark.ha...@windriver.com wrote:
From: Matthew McClintock m...@freescale.com
ERROR: Function failed: do_compile (see
/opt/yocto/cache-build/p5020ds-64b/build_p5020ds-64b_release/tmp/work/ppc64e5500-fsl-linux/qemu-0.15.1-r6/temp/log.do_compile.28447
for further information)
ERROR: Logfile of failure stored in:
/opt/yocto/cache-build/p5020ds-64b/build_p5020ds-64b_release/tmp/work/ppc64e5500-fsl-linux/qemu-0.15.1-r6/temp/log.do_compile.28447
Log data follows:
| DEBUG: SITE files ['endian-big', 'bit-64', 'powerpc-common',
'common-linux', 'common-glibc', 'powerpc-linux', 'powerpc64-linux', 'common']
| ERROR: Function failed: do_compile (see
/opt/yocto/cache-build/p5020ds-64b/build_p5020ds-64b_release/tmp/work/ppc64e5500-fsl-linux/qemu-0.15.1-r6/temp/log.do_compile.28447
for further information)
| NOTE: make -j 24
| LINK ppc-linux-user/qemu-ppc
|
/opt/yocto/cache-build/p5020ds-64b/build_p5020ds-64b_release/tmp/sysroots/x86_64-linux/usr/libexec/ppc64e5500-fsl-linux/gcc/powerpc64-fsl-linux/4.6.4/ld:/opt/yocto/cache-build/p5020ds-64b/build_p5020ds-64b_release/tmp/work/ppc64e5500-fsl-linux/qemu-0.15.1-r6/qemu-0.15.1/ppc64.ld:84:
syntax error
| collect2: ld returned 1 exit status
| make[1]: *** [qemu-ppc] Error 1
| make: *** [subdir-ppc-linux-user] Error 2
| make: *** Waiting for unfinished jobs
| ERROR: oe_runmake failed
Signed-off-by: Matthew McClintock m...@freescale.com
(master rev: a9207aad5b163a071cd8298517d61514c587e0ed)
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
meta/recipes-devtools/qemu/qemu_0.15.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/qemu/qemu_0.15.1.bb
b/meta/recipes-devtools/qemu/qemu_0.15.1.bb
index b3fb354..2cc59f6 100644
--- a/meta/recipes-devtools/qemu/qemu_0.15.1.bb
+++ b/meta/recipes-devtools/qemu/qemu_0.15.1.bb
@@ -3,7 +3,7 @@ require qemu.inc
LIC_FILES_CHKSUM = file://COPYING;md5=441c28d2cf86e15a37fa47e15a72fbac \
file://COPYING.LIB;endline=24;md5=c04def7ae38850e7d3ef548588159913
-PR = r8
+PR = r9
FILESPATH = ${FILE_DIRNAME}/qemu-${PV}
FILESDIR = ${WORKDIR}
--
1.8.1.2.545.g2f19ada
Missing a patch?
-M
___
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] libpfm4: exclude from world
On Thu, Feb 7, 2013 at 4:43 PM, Saul Wold s...@linux.intel.com wrote:
On 02/07/2013 06:33 AM, Martin Jansa wrote:
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-kernel/libpfm/libpfm4_4.3.0.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-kernel/libpfm/libpfm4_4.3.0.bb
b/meta/recipes-kernel/libpfm/libpfm4_4.3.0.bb
index 460029f..438dbc3 100644
--- a/meta/recipes-kernel/libpfm/libpfm4_4.3.0.bb
+++ b/meta/recipes-kernel/libpfm/libpfm4_4.3.0.bb
@@ -24,3 +24,6 @@ S = ${WORKDIR}/libpfm-${PV}
do_install () {
oe_runmake install
}
+
+# oprofile depends on it only for ppc* and it fails to build on arm
+EXCLUDE_FROM_WORLD = 1
Should it be EXCLUDE_FROM_WORLD or
COMPATIBLE_MACHINE= (*ppc*|mpc*)
Since for a ppc world build it would be valid.
We really need COMPATIBLE_ARCH here...
Actually I've found since I tried to upstream my last patches that
libpfm is only a req for ppc64. I'm going to submit some follow up
patches once I hear back from the oprofile person I've been chatting
with
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libpfm4: exclude from world
On Tue, Feb 12, 2013 at 11:19 AM, Phil Blundell p...@pbcl.net wrote: On Tue, 2013-02-12 at 17:14 +, McClintock Matthew-B29882 wrote: We really need COMPATIBLE_ARCH here... Why can't you use COMPATIBLE_HOST? Yes, that's what it's called ;) -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core] oprofile: avoid processing files under .pc
On Fri, Feb 1, 2013 at 4:40 PM, Chris Larson clar...@kergoth.com wrote: On Fri, Feb 1, 2013 at 1:16 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: On Fri, Feb 1, 2013 at 4:12 AM, b28...@freescale.com wrote: From: Ting Liu b28...@freescale.com Fix the below issue: | DEBUG: Executing shell function do_configure | sed: can't read ./.pc/opstart.patch/doc/opstop.1.in: Permission denied | sed: can't read ./.pc/opstart.patch/doc/opstart.1.in: Permission denied | sed: can't read ./.pc/opstart.patch/utils/opstart.c: Permission denied | ERROR: Function failed: do_configure Permissions are messed up on these files, obviously: $ ls -alh .pc/opstart.patch/doc/ total 12K drwxr-sr-x 2 jenkins jenkins 4.0K Jan 31 20:49 . drwxr-sr-x 4 jenkins jenkins 4.0K Jan 31 20:49 .. -rw-r--r-- 1 jenkins jenkins 2.5K Jan 31 20:49 Makefile.am -- 1 jenkins jenkins0 Jan 31 20:49 opstart.1.in -- 1 jenkins jenkins0 Jan 31 20:49 opstop.1.in But this was only occurring on one machine (our CentOS box). So, I've actually isolated this down to the version of patch we were using which is creating these new files with odd permissions. So, I'm not sure how to handle this - do we actually require a newer version of patch? patch-native is assume provided and we can't just remove that since we will get circular deps. Should we require the user upgrade patch on this old CentOS 5.x box? I need to leave now so I'm leaving the problem here for now to see if anyone else has a comment. This seems like a silly reason to require a newer patch version, when it's trivial to fix the recipe to not enter .pc, IMO. Nothing should be modifying files in there directly anyway. Sounds good to me. -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] kernel.bbclass, module-base.bbclass: Use CC to form KERNEL_CC
On Sat, Jan 19, 2013 at 4:40 PM, Khem Raj raj.k...@gmail.com wrote:
kernel compiler is not special and we currently have it so
we want to pass -march and -mtune options as CFLAGS to kernel
build so that compiler picks the right subarch flags when
compiling assembly files in particular. Otherwise defaults
are chosen which may not be right in many case e.g. when
compiling kernel for collie machine we should use arch=armv4
but it uses toolchain/as defaults which is armv5te
in some case e.g. thumb1 we know that kernel can not be compiled
in thumb1 mode so we can provide that information e.g. -marm
option through KERNEL_HOST_CC_ARCH variable as we do now
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/classes/kernel-arch.bbclass | 13 +
meta/classes/kernel.bbclass | 16 +---
meta/classes/module-base.bbclass | 16
3 files changed, 14 insertions(+), 31 deletions(-)
diff --git a/meta/classes/kernel-arch.bbclass
b/meta/classes/kernel-arch.bbclass
index b3b78b6..a51e82b 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -43,3 +43,16 @@ def map_uboot_arch(a, d):
export UBOOT_ARCH = ${@map_uboot_arch(d.getVar('ARCH', True), d)}
+# Set TARGET_??_KERNEL_ARCH in the machine .conf to set architecture
+# specific options necessary for building the kernel and modules.
+TARGET_CC_KERNEL_ARCH ?=
+HOST_CC_KERNEL_ARCH ?= ${TARGET_CC_KERNEL_ARCH}
+TARGET_LD_KERNEL_ARCH ?=
+HOST_LD_KERNEL_ARCH ?= ${TARGET_LD_KERNEL_ARCH}
+TARGET_AR_KERNEL_ARCH ?=
+HOST_AR_KERNEL_ARCH ?= ${TARGET_AR_KERNEL_ARCH}
+
+KERNEL_CC = ${CC} ${HOST_CC_KERNEL_ARCH}
Why change to ${CC} from ${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX}?
It breaks some kernel builds we have...
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] kernel.bbclass, module-base.bbclass: Use CC to form KERNEL_CC
On Mon, Feb 4, 2013 at 4:51 PM, Khem Raj raj.k...@gmail.com wrote:
On Mon, Feb 4, 2013 at 12:13 PM, McClintock Matthew-B29882
b29...@freescale.com wrote:
+
+KERNEL_CC = ${CC} ${HOST_CC_KERNEL_ARCH}
Why change to ${CC} from ${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX}?
It breaks some kernel builds we have...
you did not tell what exactly breaks.
Shame on me. Our kernel gets built wrong if we pass the extra -march
or -mtune to the compiler during the kernel build. It might be
exposing another issue but not sure exactly. I need to dig up a log so
I can send that over later. Here was my fix:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mattsm/masterid=f008446117106831585ed371453d1f052cdfd9eb
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core] oprofile: avoid processing files under .pc
On Fri, Feb 1, 2013 at 4:12 AM, b28...@freescale.com wrote:
From: Ting Liu b28...@freescale.com
Fix the below issue:
| DEBUG: Executing shell function do_configure
| sed: can't read ./.pc/opstart.patch/doc/opstop.1.in: Permission denied
| sed: can't read ./.pc/opstart.patch/doc/opstart.1.in: Permission
denied
| sed: can't read ./.pc/opstart.patch/utils/opstart.c: Permission denied
| ERROR: Function failed: do_configure
Permissions are messed up on these files, obviously:
$ ls -alh .pc/opstart.patch/doc/
total 12K
drwxr-sr-x 2 jenkins jenkins 4.0K Jan 31 20:49 .
drwxr-sr-x 4 jenkins jenkins 4.0K Jan 31 20:49 ..
-rw-r--r-- 1 jenkins jenkins 2.5K Jan 31 20:49 Makefile.am
-- 1 jenkins jenkins0 Jan 31 20:49 opstart.1.in
-- 1 jenkins jenkins0 Jan 31 20:49 opstop.1.in
But this was only occurring on one machine (our CentOS box). So, I've
actually isolated this down to the version of patch we were using
which is creating these new files with odd permissions.
So, I'm not sure how to handle this - do we actually require a newer
version of patch? patch-native is assume provided and we can't just
remove that since we will get circular deps.
Should we require the user upgrade patch on this old CentOS 5.x box? I
need to leave now so I'm leaving the problem here for now to see if
anyone else has a comment.
-M
Signed-off-by: Ting Liu b28...@freescale.com
---
meta/recipes-kernel/oprofile/oprofile.inc |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/oprofile/oprofile.inc
b/meta/recipes-kernel/oprofile/oprofile.inc
index d6d20ae..b09aaf8 100644
--- a/meta/recipes-kernel/oprofile/oprofile.inc
+++ b/meta/recipes-kernel/oprofile/oprofile.inc
@@ -19,7 +19,7 @@ FILES_${PN} = ${bindir} ${libdir}/${BPN}/lib*${SOLIBS}
${datadir}/${BPN}
FILES_${PN}-dev += ${libdir}/${BPN}/lib*${SOLIBSDEV}
${libdir}/${BPN}/lib*.la
FILES_${PN}-staticdev += ${libdir}/${BPN}/lib*.a
-INC_PR = r1
+INC_PR = r2
SRC_URI = file://opstart.patch \
file://oprofile-no-query-modules.patch \
@@ -30,7 +30,7 @@ inherit autotools
EXTRA_OECONF = --with-kernel=${STAGING_KERNEL_DIR} --without-x
do_configure () {
- find . -type f | xargs sed -i 's#ROOTHOME#${ROOT_HOME}#'
+ find . -wholename './.pc' -prune -o -type f -print | xargs sed -i
's#ROOTHOME#${ROOT_HOME}#'
cp ${WORKDIR}/acinclude.m4 ${S}/
autotools_do_configure
}
--
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] [PATCH] linux-dtb: Add extra padding to the blob.
On Mon, Jan 28, 2013 at 9:00 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Mon, Jan 28, 2013 at 12:24 PM, Vakul Garg va...@freescale.com wrote: U-boot patches portal devices for adding new properties in portal nodes. T4 devices such as T4240 have large number of portals. This requires extra space in device tree blob. The large number of portals need more padding space to be added. Signed-off-by: Vakul Garg va...@freescale.com This might be overridable so it could be overrided in the machine and do not change the default for everyone. What do you think? Agreed. I suggest just making this change: -KERNEL_DEVICETREE_FLAGS = -R 8 -p 0x3000 +KERNEL_DEVICETREE_FLAGS ?= -R 8 -p 0x3000 Then the machines/distros themselves can override this var. -M -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ 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] anyone interested in CentOS 5 fixes for dpkg-native?
On Tue, Jan 8, 2013 at 11:56 AM, Donn Seeley donn.see...@windriver.com wrote: We recently tried to build using 'PACKAGE_CLASSES = package_deb' and found that our ancient CentOS 5 build VMs couldn't compile and link dpkg-native. (We support CentOS 5 for very conservative customers, so we run test builds with it regularly.) Given that package_deb isn't used frequently and that CentOS 5 is so old, I thought that I would ask first before submitting fixes for that configuration. Do we want the patches in oe-core? I vote yes, additionally these patches don't look too complex or intrusive. -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [for-denzil] bitbake: command: add error to return of runCommand
On Tue, Dec 18, 2012 at 3:28 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2012-12-18 at 11:18 -0600, Matthew McClintock wrote:
From: Christopher Larson chris_lar...@mentor.com
Currently, command.py can return an error message from runCommand, due to
being unable to run the command, yet few of our UIs (just hob) can handle it
today. This can result in seeing a TypeError with traceback in certain rare
circumstances.
To resolve this, we need a clean way to get errors back from runCommand,
without having to isinstance() the return value. This implements such a thing
by making runCommand also return an error (or None if no error occurred).
As runCommand now has a method of returning errors, we can also alter the
getCmdLineAction bits such that the returned value is just the action, not an
additional message. If a sync command wants to return an error, it raises
CommandError(message), and the message will be passed to the caller
appropriately.
Example Usage:
result, error = server.runCommand(...)
if error:
log.error('Unable to run command: %s' % error)
return 1
(Bitbake rev: 717831b8315cb3904d9b590e633000bc897e8fb6)
This patch has bugs in it. See recent fixes in master.
Signed-off-by: Christopher Larson chris_lar...@mentor.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
bitbake/lib/bb/command.py | 43 +++--
bitbake/lib/bb/server/process.py|2 +-
bitbake/lib/bb/ui/crumbs/hobeventhandler.py |5 ++-
bitbake/lib/bb/ui/depexp.py | 38 ++
bitbake/lib/bb/ui/goggle.py | 17 +-
bitbake/lib/bb/ui/knotty.py | 45
++-
bitbake/lib/bb/ui/ncurses.py| 21 -
7 files changed, 112 insertions(+), 59 deletions(-)
diff --git a/bitbake/lib/bb/command.py b/bitbake/lib/bb/command.py
index fd8912a..00b854e 100644
--- a/bitbake/lib/bb/command.py
+++ b/bitbake/lib/bb/command.py
@@ -44,6 +44,9 @@ class CommandFailed(CommandExit):
self.error = message
CommandExit.__init__(self, 1)
+class CommandError(Exception):
+pass
+
class Command:
A queue of asynchronous commands for bitbake
@@ -57,21 +60,25 @@ class Command:
self.currentAsyncCommand = None
def runCommand(self, commandline):
-try:
-command = commandline.pop(0)
-if command in CommandsSync.__dict__:
-# Can run synchronous commands straight away
-return getattr(CommandsSync, command)(self.cmds_sync, self,
commandline)
-if self.currentAsyncCommand is not None:
-return Busy (%s in progress) % self.currentAsyncCommand[0]
-if command not in CommandsAsync.__dict__:
-return No such command
-self.currentAsyncCommand = (command, commandline)
-self.cooker.server_registration_cb(self.cooker.runCommands,
self.cooker)
-return True
-except:
-import traceback
-return traceback.format_exc()
+command = commandline.pop(0)
+if hasattr(CommandsSync, command):
+# Can run synchronous commands straight away
+command_method = getattr(self.cmds_sync, command)
+try:
+result = command_method(self, commandline)
+except CommandError as exc:
+return None, exc.args[0]
+except Exception:
+return None, traceback.format_exc()
Missing import traceback.
+else:
+return result, None
+if self.currentAsyncCommand is not None:
+return None, Busy (%s in progress) %
self.currentAsyncCommand[0]
+if command not in CommandsAsync.__dict__:
+return None, No such command
+self.currentAsyncCommand = (command, commandline)
+self.cooker.server_registration_cb(self.cooker.runCommands,
self.cooker)
+return True, None
def runAsyncCommand(self):
try:
@@ -139,7 +146,11 @@ class CommandsSync:
Get any command parsed from the commandline
-return command.cooker.commandlineAction
+cmd_action = command.cooker.commandlineAction
+if cmd_action['msg']:
+raise CommandError(msg)
Error, msg not defined.
Thanks, will look for these and add them / send to list as well. Look
for another patch when I get to it.
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc-cross: Explicitly depend on linux-libc-headers
On Thu, Nov 22, 2012 at 3:36 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
gcc-cross cannot build without linux-libc-headers but doesn't explicitly
depend on
it relying on the implied dependency through libc. With cases where pieces
can be installed through sstate, we now need this explicit dependency to
ensure builds with partial sstate work.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc
b/meta/recipes-devtools/gcc/gcc-cross.inc
index 6d160d6..cde08ee 100644
--- a/meta/recipes-devtools/gcc/gcc-cross.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross.inc
@@ -1,6 +1,6 @@
inherit cross
-DEPENDS = virtual/${TARGET_PREFIX}binutils
virtual/${TARGET_PREFIX}libc-for-gcc ${NATIVEDEPS}
+DEPENDS = virtual/${TARGET_PREFIX}binutils
virtual/${TARGET_PREFIX}libc-for-gcc linux-libc-headers ${NATIVEDEPS}
How would you suggest not forcing a rebuild of all components if the
linux headers signature changes? During our normal development we
change Linux headers for things that would in no way effect gcc or
even libc. It's painful to watch a complete rebuild occur because of
this.
Just have a different recipe for headers for some components?
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] meta-freescale general mailing list
On Mon, Nov 19, 2012 at 7:05 AM, Leon Woestenberg sidebranch.openembed...@gmail.com wrote: Hello Otavio, all, On Sun, Nov 18, 2012 at 9:00 PM, Otavio Salvador ota...@ossystems.com.br wrote: On Thu, Nov 15, 2012 at 3:02 PM, Otavio Salvador ota...@ossystems.com.br wrote: On Thu, Nov 15, 2012 at 1:36 PM, Philip Balister phi...@balister.org wrote: On 11/14/2012 11:58 AM, McClintock Matthew-B29882 wrote: Do we have a standard for yocto/OE list names on gmane? I tried to add it but it did not work. It is now done. You can see it at http://blog.gmane.org/gmane.linux.embedded.yocto.meta-freescale Regards, Otavio Thanks. There is a small typo in the gmane: Leyers vs Layers. -Freescale OpenEmbedded/Yocto Leyers discussion list () +Freescale OpenEmbedded/Yocto Layers discussion list () I've sent a request to fix this. -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] OE Changelog since 2012-11-11 until 2012-11-18
On Mon, Nov 19, 2012 at 12:49 PM, cliff.br...@gmail.com wrote: Changelog since 2012-11-11 until 2012-11-18. Projects included in this report: bitbake: git://git.openembedded.org/bitbake openembedded-core: git://git.openembedded.org/openembedded-core meta-openembedded: git://git.openembedded.org/meta-openembedded meta-angstrom: git://github.com/Angstrom-distribution/meta-angstrom.git meta-arago: git://arago-project.org/git/meta-arago.git meta-beagleboard: git://github.com/beagleboard/meta-beagleboard.git meta-browser: git://github.com/OSSystems/meta-browser.git meta-bug: git://github.com/buglabs/meta-bug.git meta-chicken: git://github.com/OSSystems/meta-chicken meta-efikamx: git://github.com/kraj/meta-efikamx.git meta-ettus: http://github.com/koenkooi/meta-ettus.git meta-fsl-arm: git://git.yoctoproject.org/meta-fsl-arm meta-fsl-ppc: git://github.com/Freescale/meta-fsl-arm-extra.git[submodule meta-fsl-ppc] This looks funny. -M meta-guacamayo: git://github.com/Guacamayo/meta-guacamayo.git meta-gumstix: git://github.com/gumstix/meta-gumstix.git meta-gumstix-community: git://gitorious.org/schnitzeltony-oe-meta/meta-gumstix-community.git meta-handheld: git://git.openembedded.org/meta-handheld meta-igep: http://github.com/ebutera/meta-igep.git meta-intel: git://git.yoctoproject.org/meta-intel meta-ivi: git://git.yoctoproject.org/meta-ivi meta-java: git://github.com/woglinde/meta-java meta-kde: git://gitorious.org/openembedded-core-layers/meta-kde.git meta-micro: git://git.openembedded.org/meta-micro meta-mono: git://git.yoctoproject.org/meta-mono.git meta-netbookpro: git://github.com/tworaz/meta-netbookpro meta-nslu2: git://github.com/kraj/meta-nslu2 meta-opie: git://git.openembedded.org/meta-opie meta-qt3: git://git.yoctoproject.org/meta-qt3 meta-slugos: git://github.com/kraj/meta-slugos meta-systemd: git://git.yoctoproject.org/meta-systemd meta-raspberrypi: git://github.com/djwillis/meta-raspberrypi.git meta-smartphone: http://git.shr-project.org/repo/meta-smartphone.git meta-ti: git://git.yoctoproject.org/meta-ti meta-webos: git://github.com/openwebos/meta-webos.git meta-xilinx: git://git.yoctoproject.org/meta-xilinx meta-yocto: git://git.yoctoproject.org/meta-yocto openembedded: git://git.openembedded.org/openembedded Changelog for bitbake: Christopher Larson (1): knotty: kill duplicated import of 'time' Cristiana Voicu (1): hob: hob was freezing because it doesn't receives well the log file Robert Yang (1): print clear message for bitbake -e ASSUME_PROVIDED Changelog for openembedded-core: Christopher Larson (1): bash: fix mkbuiltins build failure Constantin Musca (3): puzzles: upgrade to r9660 libxslt: upgrade to 1.1.27 insane.bbclass: add qa package name check Denis 'GNUtoo' Carikli (1): boost: Activate zlib and bzip2 because they now work. Enrico Scholz (2): binutils: fixed --enable-targets option opkg: added alternatives-ln patch Gilbert Coville (1): pulseaudio: explicitly disable xen, rather than letting it detect Jessica Zhang (1): Fix the first line typo of adt-installer Laurentiu Palcu (8): populate_sdk_base.bbclass: use SDK_ARCH instead of SDKMACHINE xf86-video-vesa: upgrade to 2.3.2 xf86-video-intel: upgrade to 2.20.12 xf86-input-mouse: upgrade to 1.8.1 xcb-proto: upgrade to 1.8 fontconfig: upgrade to 2.10.1 mdadm: upgrade to 3.2.6 xf86-input-synaptics: add mtdev dependency Mark Hatle (4): rpm: Slightly change the way python-rpm is constructed python-smartpm: Add smartpm recipe rpm: Add additional RPMSENSE values to python module python-smartpm: Add basic knowledge of RPMSENSE_MISSINGOK Martin Jansa (1): qt4: remove -lGLU from QMAKE_LIBS_OPENGL in our linux.conf Phil Blundell (1): insane: detect and warn about relocations in .text Richard Purdie (11): libc-common: Ensure sysconfdir exists before installing files to it python.inc: make lsb override more concise sstate: Be consistent about sstate-inputdirs/outputdirs ending with '/' classes: Be consistent about sstate-inputdirs/outputdirs ending with '/' utils.bbclass: Fix documentation of create_cmdline_wrapper sstate: Fix various path manipulation issues sstate: Bump version number to deal with layout fixes make-3.82: Add patch for archive expression expansion issues python: Resolve intermediate staging issues sstate: Drop now unneeded python whitelist entries libcgroup/libxkbcommon: Use BPN in SRC_URI Ross Burton (11): autotools: set _FOR_BUILD variables here meta: remove redundant _FOR_BUILD variables xorg-driver-common: remove AC_CHECK_FILE workaround glib-2.0: remove zip build dependency glib-2.0: upgrade to latest stable, 2.34.1. mesa: remove python2 detection hack libunique: fix compilation with GLib 2.34 initrdscripts:
[OE-core] meta-freescale general mailing list
YoctoProject.org is now hosting a meta-freescale mailing list that are going to unify the communities of meta-fsl-ppc and meta-fsl-arm. From now on all patches affecting meta-fsl-ppc and meta-fsl-arm can be sent to meta-freesc...@yoctoproject.org and have the respective tag in the patch. Please check the README in respective layer about the command line to use for git format-patch. Please subscribe here: https://lists.yoctoproject.org/listinfo/meta-freescale Archives here: https://lists.yoctoproject.org/pipermail/meta-freescale/ -Matthew ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] classes: Be consistent about sstate-inputdirs/outputdirs ending with '/'
On Wed, Nov 14, 2012 at 9:59 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Wed, 2012-11-14 at 16:22 +0100, Martin Jansa wrote:
On Wed, Nov 14, 2012 at 04:09:45PM +0100, Martin Jansa wrote:
On Tue, Nov 13, 2012 at 02:05:00PM +, Richard Purdie wrote:
If sstate-inputdirs and sstate-outputdirs don't match with ending '/'
characters, the manifest file can end up corrupted. This change
ensures the metadata is consistent in ending do_populate_root tasks
with this character to avoid manifest file corruption.
diff --git a/meta/recipes-devtools/gcc/gcc-cross-initial.inc
b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
index ff6556c..1ac1db6 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-initial.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
@@ -74,6 +74,6 @@ sysroot_stage_all() {
mv ${SYSROOT_DESTDIR}${target_libdir}/*
${SYSROOT_DESTDIR}${STAGING_DIR_TARGET}${target_libdir}/ || true
}
-do_populate_sysroot[sstate-inputdirs] =
${SYSROOT_DESTDIR}/${STAGING_DIR_HOST}
${SYSROOT_DESTDIR}/${STAGING_DIR_TARGET}/${target_base_libdir}
-do_populate_sysroot[sstate-outputdirs] = ${STAGING_DIR_HOST}
${STAGING_DIR_TCBOOTSTRAP}/${target_base_libdir}
+do_populate_sysroot[sstate-inputdirs] =
${SYSROOT_DESTDIR}/${STAGING_DIR_HOST}/
${SYSROOT_DESTDIR}/${STAGING_DIR_TARGET}/${target_base_libdir}/
+do_populate_sysroot[sstate-outputdirs] = ${STAGING_DIR_HOST}/
${STAGING_DIR_TCBOOTSTRAP}/${target_base_libdir}/
Not sure if it can be caused by this, but building from scratch fails
today with:
with some added debug output it looks like trying to move the same directory
twice:
WARNING: Moving
/OE/oe-core/tmp-eglibc/work/x86_64-oe-linux/gcc-cross-initial-4.7.2-r13/sstate-install-populate-sysroot/
to
/OE/oe-core/tmp-eglibc/work/x86_64-oe-linux/gcc-cross-initial-4.7.2-r13/sysroot-destdir///OE/oe-core/tmp-eglibc/sysroots/x86_64-linux/
WARNING: Moving
/OE/oe-core/tmp-eglibc/work/x86_64-oe-linux/gcc-cross-initial-4.7.2-r13/sstate-install-populate-sysroot/
to
/OE/oe-core/tmp-eglibc/work/x86_64-oe-linux/gcc-cross-initial-4.7.2-r13/sysroot-destdir///OE/oe-core/tmp-eglibc/sysroots/qemux86-64//lib/
ERROR: Error executing a python function in
/OE/oe-core/openembedded-core/meta/recipes-devtools/gcc/gcc-cross-initial_4.7.bb:
There is something missing from after sstate-install-populate-sysroot/.
I've pushed a fix into master. Its only appearing when installing from
sstate.
I've seen this on older releases also...
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] cryptodev kernel module recipe
On Tue, Nov 13, 2012 at 5:45 PM, Chris Larson clar...@kergoth.com wrote: On Fri, Nov 2, 2012 at 3:15 PM, Yashpal Dutta yashpal.du...@freescale.com wrote: This is a /dev/crypto device driver, equivalent to those in OpenBSD or FreeBSD. The main idea is to access of existing ciphers in kernel space from userspace, thus enabling re-use of a hardware implementation of a cipher. Signed-off-by: Yashpal Dutta yashpal.du...@freescale.com I would think that patches which add recipes to oe-core would do more than describe what it is, but also provide justification for its inclusion in oe-core vs some other layer. If that was already covered in a previous thread, that's fine, but I wanted to make sure it was explicit. Honestly, I'm not really sure why it should be in OE-core other than that ocf-linux which is semi-equivalent is here also. Maybe we should look at a meta-crypto layer or just keep this our own layer. Not sure, opening for discussion here. -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cryptodev kernel module recipe
On Wed, Oct 31, 2012 at 12:11 PM, Bruce Ashfield
bruce.ashfi...@gmail.com wrote:
On Tue, Oct 30, 2012 at 2:50 PM, McClintock Matthew-B29882
b29...@freescale.com wrote:
On Thu, Oct 18, 2012 at 8:33 AM, Bruce Ashfield
bruce.ashfi...@gmail.com wrote:
On Thu, Oct 18, 2012 at 5:57 AM, Yashpal Dutta
yashpal.du...@freescale.com wrote:
This is a /dev/crypto device driver, equivalent to those in OpenBSD or
FreeBSD.
The main idea is to access of existing ciphers in kernel space from
userspace,
thus enabling re-use of a hardware implementation of a cipher.
I always use OCF for an overlapping set of functionality. To make this
external
module gracefully deal with a situation such as this, maybe a check for
OCF
in the kernel config ?
The same thing could be said about having a kernel with this
functionality
already integrated (I have several of those as well).
That's a more general question about what's the best way to gracefully
deal
with out of tree modules detecting that they are being built against a
kernel
that already has the functionality merged. The easy answer is that
it's something
the distro maintainer needs to know, and manage, and maybe that's the
final answer. But I'm more wondering about this with respect to
inter-operability
of layers, if something in a layer depends/rdepends on this module, it
will be
pulled in, and won't that limit the mix/match/stacking of the various
layers ?
I added Richard for comment on the above.
But that of course raises the question, why should this be in oe-core
versus
something like OCF ? This is definitely simpler, but OCF has it's use
cases and
advantages as well, that are an overlapping set of functionality.
I don't have all the answers, just plenty of questions :)
I'm not overly familiar with OCF. Does this just RCONFLICT with ocf-linux?
I missed this yesterday, sorry about that. gmail just left this in the
thread and
not in my inbox .. but anyway.
I only see parts ocf in oe-core, but maybe I'm just not understanding what
the
recipe is doing (are you seeing more) ? i.e. ocf-linux is buried under the
open-ssl recipe, and really looks to be just providing headers.
I'm doing some builds now to learn more .. which I just did .. and from what
I
can see, it is just the headers, which isn't all that useful without the
kernel
underpinning.
ocf-linux recipe does infact appear to be just headers. As far as what
it's used for I'm not even sure. I'll ask the crypto guys to chime in
here.
OCF does definitely accelerate openssl when properly used in both the kernel
and
userspace, but I'm not seeing the full offload kernel framework anywhere.
Can't comment what others do, it would be ideal if we got all users
talking here though.
I wonder if anyone actually uses it :)
Good question, it was added by Saul so maybe he can chime in here.
But yes AFAIC, if you had a full OCF, you need these to conflict, since
they'll both
try and enable/provide cryptodev.
Yashpal,
You should to add
RCONFLICTS_${PN} = ocf-linux
and/or maybe
RCONFLICTS_${PN}-dev = ocf-linux-dev
to your v2 of the patch.
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cryptodev kernel module recipe
On Thu, Oct 18, 2012 at 8:33 AM, Bruce Ashfield
bruce.ashfi...@gmail.com wrote:
On Thu, Oct 18, 2012 at 5:57 AM, Yashpal Dutta
yashpal.du...@freescale.com wrote:
This is a /dev/crypto device driver, equivalent to those in OpenBSD or
FreeBSD.
The main idea is to access of existing ciphers in kernel space from
userspace,
thus enabling re-use of a hardware implementation of a cipher.
I always use OCF for an overlapping set of functionality. To make this
external
module gracefully deal with a situation such as this, maybe a check for OCF
in the kernel config ?
The same thing could be said about having a kernel with this functionality
already integrated (I have several of those as well).
That's a more general question about what's the best way to gracefully deal
with out of tree modules detecting that they are being built against a kernel
that already has the functionality merged. The easy answer is that
it's something
the distro maintainer needs to know, and manage, and maybe that's the
final answer. But I'm more wondering about this with respect to
inter-operability
of layers, if something in a layer depends/rdepends on this module, it will be
pulled in, and won't that limit the mix/match/stacking of the various layers ?
I added Richard for comment on the above.
But that of course raises the question, why should this be in oe-core versus
something like OCF ? This is definitely simpler, but OCF has it's use cases
and
advantages as well, that are an overlapping set of functionality.
I don't have all the answers, just plenty of questions :)
I'm not overly familiar with OCF. Does this just RCONFLICT with ocf-linux?
-M
Cheers,
Bruce
Signed-off-by: Yashpal Dutta yashpal.du...@freescale.com
---
meta/recipes-kernel/cryptodev/cryptodev_1.5.bb | 18 +
.../cryptodev/files/makefile_fixup.patch | 26
2 files changed, 44 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-kernel/cryptodev/cryptodev_1.5.bb
create mode 100644 meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
diff --git a/meta/recipes-kernel/cryptodev/cryptodev_1.5.bb
b/meta/recipes-kernel/cryptodev/cryptodev_1.5.bb
new file mode 100644
index 000..5125710
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/cryptodev_1.5.bb
@@ -0,0 +1,18 @@
+SECTION = devel
+SUMMARY = Linux Cryptodev KERNEL MODULE
+DESCRIPTION = The Cryptodev package contains the kernel /dev/crypto module
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263
+
+DEPENDS = virtual/kernel
+
+inherit module
+
+SRCREV = 1c24a0aa996630518d47826a2e3fea129ea094c7
+
+SRC_URI = git://repo.or.cz/cryptodev-linux.git;protocol=git \
+ file://makefile_fixup.patch
+
+EXTRA_OEMAKE='KERNEL_DIR=${STAGING_KERNEL_DIR} PREFIX=${D}'
+
+S = ${WORKDIR}/git
diff --git a/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
b/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
new file mode 100644
index 000..323aacd
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
@@ -0,0 +1,26 @@
+diff --git a/Makefile b/Makefile
+index 2be8825..b36d68c 100644
+--- a/Makefile
b/Makefile
+@@ -1,6 +1,7 @@
+ KBUILD_CFLAGS += -I$(src)
+ KERNEL_DIR = /lib/modules/$(shell uname -r)/build
+ VERSION = 1.5
++PREFIX =
+
+ cryptodev-objs = ioctl.o main.o cryptlib.o authenc.o zc.o util.o
+
+@@ -12,10 +13,10 @@ build: version.h
+ version.h: Makefile
+ @echo #define VERSION \$(VERSION)\ version.h
+
+-install:
++modules_install:
+ make -C $(KERNEL_DIR) SUBDIRS=`pwd` modules_install
+- @echo Installing cryptodev.h in /usr/include/crypto ...
+- @install -D crypto/cryptodev.h /usr/include/crypto/cryptodev.h
++ @echo Installing cryptodev.h in $(PREFIX)/usr/include/crypto ...
++ @install -D crypto/cryptodev.h
$(PREFIX)/usr/include/crypto/cryptodev.h
+
+ clean:
+ make -C $(KERNEL_DIR) SUBDIRS=`pwd` clean
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
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] cryptodev kernel module recipe
On Thu, Oct 18, 2012 at 3:16 PM, Darren Hart dvh...@linux.intel.com wrote: +++ b/meta/recipes-kernel/cryptodev/cryptodev_1.5.bb @@ -0,0 +1,18 @@ +SECTION = devel +SUMMARY = Linux Cryptodev KERNEL MODULE +DESCRIPTION = The Cryptodev package contains the kernel /dev/crypto module +LICENSE = GPLv2 +LIC_FILES_CHKSUM = file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 + +DEPENDS = virtual/kernel This DEPENDS in inherited from the module.bbclass, no need to duplicate + +inherit module + +SRCREV = 1c24a0aa996630518d47826a2e3fea129ea094c7 + +SRC_URI = git://repo.or.cz/cryptodev-linux.git;protocol=git \ + file://makefile_fixup.patch Tabs to indent, spaces to align. Spaces here please. Yashpal, Can you address these two comments and submit a v2 of the patch if required. -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot.inc: update linker arguments to pass --sysroot arg (BUILD BREAKAGE)
On Mon, Oct 29, 2012 at 4:26 AM, Steffen Sledz sl...@dresearch-fe.de wrote:
On 29.07.2012 11:29, Richard Purdie wrote:
On Thu, 2012-07-26 at 11:21 -0500, Matthew McClintock wrote:
If we are building from sstate-cache it's possible to be building
from another folder on another machine, therefore the linker requires
that a proper --sysroot is passed too it so it can find things like
libgcc.a and avoid errors such as:
| arm-poky-linux-gnueabi-gcc -g -O2 -fno-common -ffixed-r8 -msoft-float
-D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80008000
-I/local/yocto/upstream/label/ubuntu1204-64b/machine/beagleboard/poky/edison/tmp/work/beagleboard-poky-linux-gnueabi/u-boot-v2011.06+git5+b1af6f532e0d348b153d5c148369229d24af361a-r0/git/include
-fno-builtin -ffreestanding -nostdinc -isystem
/local/yocto/upstream/label/ubuntu1204-64b/machine/beagleboard/poky/edison/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/../../lib/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.6.3/include
-pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux
-mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes
-fno-stack-protector -fno-toplevel-reorder -o hello_world.o hello_world.c
-c
| arm-poky-linux-gnueabi-gcc -g -O2 -fno-common -ffixed-r8 -msoft-float
-D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80008000
-I/local/yocto/upstream/label/ubuntu1204-64b/machine/beagleboard/poky/edison/tmp/work/beagleboard-poky-linux-gnueabi/u-boot-v2011.06+git5+b1af6f532e0d348b153d5c148369229d24af361a-r0/git/include
-fno-builtin -ffreestanding -nostdinc -isystem
/local/yocto/upstream/label/ubuntu1204-64b/machine/beagleboard/poky/edison/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/../../lib/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.6.3/include
-pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux
-mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes
-fno-stack-protector -fno-toplevel-reorder -o stubs.o stubs.c -c
| arm-poky-linux-gnueabi-ld -r -o libstubs.o stubs.o
| arm-poky-linux-gnueabi-ld -g -Ttext 0x8030 \
|-o hello_world -e hello_world hello_world.o libstubs.o
\
|-L. -lgcc
| arm-poky-linux-gnueabi-ld: cannot find -lgcc
| make[1]: *** [hello_world] Error 1
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/recipes-bsp/u-boot/u-boot.inc |2 +-
meta/recipes-bsp/u-boot/u-boot_2011.03.bb|2 +-
meta/recipes-bsp/u-boot/u-boot_2011.06.bb|2 +-
meta/recipes-bsp/u-boot/u-boot_2012.04.01.bb |1 +
4 files changed, 4 insertions(+), 3 deletions(-)
Merged to master, thanks.
While trying to migrate the u-boot support for our machine from oe-classic i
hit a problem with this patch. :(
The
EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC=${TARGET_PREFIX}gcc
${TOOLCHAIN_OPTIONS}'
in u-boot.inc leads to compiling problems with some build support tools. The
tools (e.g. bmp_logo) are now compiled with the target compiler
(arm-oe-linux-gnueabi-gcc in our case) instead of the host compiler. This
results in build errors like
| ./bmp_logo logos/denx.bmp
/pm/sledz/oe-core/build/tmp-eglibc/work/hipox-oe-linux-gnueabi/u-boot-v2009.03+git91+e60beb13cf0135dc71c541021487b5ccc4d269cb-r8/git/include/bmp_logo.h
| /bin/sh: ./bmp_logo: cannot execute binary file
Reverting to
EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX}'
seems to fix this problem.
That however will break building from sstate... we might need to patch
u-boot's Makefiles here...
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot.inc: update linker arguments to pass --sysroot arg (BUILD BREAKAGE)
On Mon, Oct 29, 2012 at 9:36 AM, Matthew McClintock m...@freescale.com wrote:
On Mon, Oct 29, 2012 at 4:26 AM, Steffen Sledz sl...@dresearch-fe.de wrote:
On 29.07.2012 11:29, Richard Purdie wrote:
On Thu, 2012-07-26 at 11:21 -0500, Matthew McClintock wrote:
If we are building from sstate-cache it's possible to be building
from another folder on another machine, therefore the linker requires
that a proper --sysroot is passed too it so it can find things like
libgcc.a and avoid errors such as:
| arm-poky-linux-gnueabi-gcc -g -O2 -fno-common -ffixed-r8 -msoft-float
-D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80008000
-I/local/yocto/upstream/label/ubuntu1204-64b/machine/beagleboard/poky/edison/tmp/work/beagleboard-poky-linux-gnueabi/u-boot-v2011.06+git5+b1af6f532e0d348b153d5c148369229d24af361a-r0/git/include
-fno-builtin -ffreestanding -nostdinc -isystem
/local/yocto/upstream/label/ubuntu1204-64b/machine/beagleboard/poky/edison/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/../../lib/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.6.3/include
-pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux
-mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes
-fno-stack-protector -fno-toplevel-reorder -o hello_world.o
hello_world.c -c
| arm-poky-linux-gnueabi-gcc -g -O2 -fno-common -ffixed-r8 -msoft-float
-D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80008000
-I/local/yocto/upstream/label/ubuntu1204-64b/machine/beagleboard/poky/edison/tmp/work/beagleboard-poky-linux-gnueabi/u-boot-v2011.06+git5+b1af6f532e0d348b153d5c148369229d24af361a-r0/git/include
-fno-builtin -ffreestanding -nostdinc -isystem
/local/yocto/upstream/label/ubuntu1204-64b/machine/beagleboard/poky/edison/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/../../lib/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.6.3/include
-pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux
-mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes
-fno-stack-protector -fno-toplevel-reorder -o stubs.o stubs.c -c
| arm-poky-linux-gnueabi-ld -r -o libstubs.o stubs.o
| arm-poky-linux-gnueabi-ld -g -Ttext 0x8030 \
|-o hello_world -e hello_world hello_world.o
libstubs.o \
|-L. -lgcc
| arm-poky-linux-gnueabi-ld: cannot find -lgcc
| make[1]: *** [hello_world] Error 1
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/recipes-bsp/u-boot/u-boot.inc |2 +-
meta/recipes-bsp/u-boot/u-boot_2011.03.bb|2 +-
meta/recipes-bsp/u-boot/u-boot_2011.06.bb|2 +-
meta/recipes-bsp/u-boot/u-boot_2012.04.01.bb |1 +
4 files changed, 4 insertions(+), 3 deletions(-)
Merged to master, thanks.
While trying to migrate the u-boot support for our machine from oe-classic i
hit a problem with this patch. :(
The
EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC=${TARGET_PREFIX}gcc
${TOOLCHAIN_OPTIONS}'
in u-boot.inc leads to compiling problems with some build support tools. The
tools (e.g. bmp_logo) are now compiled with the target compiler
(arm-oe-linux-gnueabi-gcc in our case) instead of the host compiler. This
results in build errors like
| ./bmp_logo logos/denx.bmp
/pm/sledz/oe-core/build/tmp-eglibc/work/hipox-oe-linux-gnueabi/u-boot-v2009.03+git91+e60beb13cf0135dc71c541021487b5ccc4d269cb-r8/git/include/bmp_logo.h
| /bin/sh: ./bmp_logo: cannot execute binary file
Reverting to
EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX}'
seems to fix this problem.
That however will break building from sstate... we might need to patch
u-boot's Makefiles here...
Looking closer you are using a really old u-boot. Can you update? The
Makefile for bmp_logo uses HOSTCC so this should not be an issue with
a recent u-boot.
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Using SSTATE_MIRRORS with sstate subdirectories
On Fri, Oct 19, 2012 at 11:57 AM, Mike Crowe m...@mcrowe.com wrote: On Fri, Oct 19, 2012 at 08:46:23AM -0700, Chris Larson wrote: On Fri, Oct 19, 2012 at 8:38 AM, Mike Crowe m...@mcrowe.com wrote: I'm having trouble using SSTATE_MIRRORS as suggested at https://wiki.yoctoproject.org/wiki/Enable_sstate_cache : SSTATE_MIRRORS ?= file://.* file:///private/sstate-cache/ SSTATE_MIRRORS ?= file://.* file:///private/sstate-cache/PATH Thanks for your reply. Although that works for the simple case, if I try and do something more adventurous like: SSTATE_MIRRORS = \ file://Debian-testing/.* file:///private/sstate-cache/Debian-6.0.6/PATH \n \ file://.* file:///private/sstate-cache/PATH \n \ Then I get paths like: DEBUG: For url file://Debian-testing/8c/sstate-tar-replacement-native-x86_64-linux-1.26-r3-x86_64-2-8cc4342260b064ace38e0aa1acf2f618_populate-sysroot.tgz returning file:///private/sstate-cache/Debian-6.0.6/Debian-testing/8c/sstate-tar-replacement-native-x86_64-linux-1.26-r3-x86_64-2-8cc4342260b064ace38e0aa1acf2f618_populate-sysroot.tgz so I really would like to be able to say: file://Debian-testing/(.*) file:///private/sstate-cache/Debian-6.0.6/\1 Something like this might be what you are looking for: SSTATE_MIRRORS = file://.*/(.*)/(.*) http://linux.freescale.net/yocto/sstate-cache/CentOS-5.8/\1/\2 \n This maps all native sstate-cache to my CentOS-5 box. -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Can we trust to sstate-cache?
On Thu, Oct 18, 2012 at 8:36 AM, Marcin Juszkiewicz marcin.juszkiew...@linaro.org wrote: Today I bumped gcc-linaro from 4.7-r5 to 4.7-r6. First version was plain 2012.10 release while second one was tarball from bzr repository with huge set of ICE related fixes for AArch64 architecture. To do fast clean build I removed TMPDIR and started new build of core-image-minimal target. But then I noticed ugly thing: 0: eglibc-2.16-r18+svnr20393 do_populate_sysroot_setscene (pid 30106) 1: eglibc-2.16-r18+svnr20393 do_package_setscene (pid 30107) 3: eglibc-initial-2.16-r18+svnr20393 do_package_setscene (pid 28921) Why eglibc was taken from sstate-cache instead of being rebuilt (like it was with 'db')? This makes me sad as it shows that I cannot trust sstate-cache so each new build will take hours instead of minutes. Or maybe I am wrong? Did the signatures for eglibc change after making your gcc-linaro change? You can run bitbake -S before and after and see which ones have new stamps. Then you can start using bitbake-diffsigs to back track (or presumably if nothing changed add a proper dependency) -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cryptodev kernel module recipe
On Thu, Oct 18, 2012 at 2:59 PM, Darren Hart dvh...@linux.intel.com wrote:
On 10/18/2012 02:14 AM, Khem Raj wrote:
On Oct 18, 2012, at 2:57 AM, Yashpal Dutta yashpal.du...@freescale.com
wrote:
+-install:
++modules_install:
+make -C $(KERNEL_DIR) SUBDIRS=`pwd` modules_install
+- @echo Installing cryptodev.h in /usr/include/crypto ...
+- @install -D crypto/cryptodev.h /usr/include/crypto/cryptodev.h
++ @echo Installing cryptodev.h in $(PREFIX)/usr/include/crypto ...
++ @install -D crypto/cryptodev.h $(PREFIX)/usr/include/crypto/cryptodev.h
+
why is it installing linux headers under /usr/include shouldn't they be
under usr/include/linux ?
And shouldn't /usr/include be one of those ${*dir} variables?
That's a patch to a Makefile... not a recipe.
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cryptodev kernel module recipe
On Thu, Oct 18, 2012 at 3:16 PM, Darren Hart dvh...@linux.intel.com wrote:
On 10/18/2012 05:57 AM, Yashpal Dutta wrote:
This is a /dev/crypto device driver, equivalent to those in OpenBSD or
FreeBSD.
The main idea is to access of existing ciphers in kernel space from
userspace,
thus enabling re-use of a hardware implementation of a cipher.
Signed-off-by: Yashpal Dutta yashpal.du...@freescale.com
---
meta/recipes-kernel/cryptodev/cryptodev_1.5.bb | 18 +
.../cryptodev/files/makefile_fixup.patch | 26
2 files changed, 44 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-kernel/cryptodev/cryptodev_1.5.bb
create mode 100644 meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
diff --git a/meta/recipes-kernel/cryptodev/cryptodev_1.5.bb
b/meta/recipes-kernel/cryptodev/cryptodev_1.5.bb
new file mode 100644
index 000..5125710
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/cryptodev_1.5.bb
@@ -0,0 +1,18 @@
+SECTION = devel
+SUMMARY = Linux Cryptodev KERNEL MODULE
+DESCRIPTION = The Cryptodev package contains the kernel /dev/crypto module
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263
+
+DEPENDS = virtual/kernel
This DEPENDS in inherited from the module.bbclass, no need to duplicate
+
+inherit module
+
+SRCREV = 1c24a0aa996630518d47826a2e3fea129ea094c7
+
+SRC_URI = git://repo.or.cz/cryptodev-linux.git;protocol=git \
+ file://makefile_fixup.patch
Tabs to indent, spaces to align. Spaces here please.
+
+EXTRA_OEMAKE='KERNEL_DIR=${STAGING_KERNEL_DIR} PREFIX=${D}'
modules.bbclass already sets KERNEL_PATH and KERNEL_SRC, perhaps you
could use one of those?
cryptodev Makefile does not use these it uses KERNEL_DIR in it's
Makefile for whatever reason. Getting an upstream project to change is
more difficult.
If you just use ${includedir} in your install I believe you can skip
PREFIX here and get the /usr part right there.
This is more changes to the upstream Makefile
+
+S = ${WORKDIR}/git
diff --git a/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
b/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
new file mode 100644
index 000..323aacd
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
@@ -0,0 +1,26 @@
+diff --git a/Makefile b/Makefile
+index 2be8825..b36d68c 100644
+--- a/Makefile
b/Makefile
+@@ -1,6 +1,7 @@
+ KBUILD_CFLAGS += -I$(src)
+ KERNEL_DIR = /lib/modules/$(shell uname -r)/build
+ VERSION = 1.5
++PREFIX =
+
+ cryptodev-objs = ioctl.o main.o cryptlib.o authenc.o zc.o util.o
+
+@@ -12,10 +13,10 @@ build: version.h
+ version.h: Makefile
+ @echo #define VERSION \$(VERSION)\ version.h
+
+-install:
++modules_install:
+ make -C $(KERNEL_DIR) SUBDIRS=`pwd` modules_install
Current kernels recommend using M= instead of SUBDIRS=:
SRC := $(shell pwd)
make -C $(KERNEL_SRC) M=$(SRC) modules_install
See the hello-mod example in meta-skeleton/recipes-kernel/hello-mod for
a minimal example.
+-@echo Installing cryptodev.h in /usr/include/crypto ...
+-@install -D crypto/cryptodev.h /usr/include/crypto/cryptodev.h
++@echo Installing cryptodev.h in $(PREFIX)/usr/include/crypto ...
++@install -D crypto/cryptodev.h $(PREFIX)/usr/include/crypto/cryptodev.h
Use ${includedir} here
You can't use this bitbake variable in a Makefile... or am I missing
something? We are making small changes the Makefile for things like
prefix so we can install to locations other than the hosts
/usr/include which is hard coded.
-M
+
+ clean:
+ make -C $(KERNEL_DIR) SUBDIRS=`pwd` clean
M=
Is changing upstream cryptodev is one thing (e.g. SUBDIR= vs. M=), how
far do you want a patch to a Makefile to change the way a project
builds?
-M
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
___
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] cryptodev kernel module recipe
On Thu, Oct 18, 2012 at 3:38 PM, Darren Hart dvh...@linux.intel.com wrote:
+EXTRA_OEMAKE='KERNEL_DIR=${STAGING_KERNEL_DIR} PREFIX=${D}'
modules.bbclass already sets KERNEL_PATH and KERNEL_SRC, perhaps you
could use one of those?
cryptodev Makefile does not use these it uses KERNEL_DIR in it's
Makefile for whatever reason. Getting an upstream project to change is
more difficult.
I think this is the second reference to KERNEL_DIR in an external module,
perhaps module.bbclass should add that to it's list of predefined names for
the STAGING_KERNEL_DIR.
Fine with me, but not sure how its worth it quite yet...
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Recipes with disabled parallel make
On Thu, Mar 8, 2012 at 7:34 AM, Andreas Oberritter o...@opendreambox.org wrote: On 02.03.2012 23:29, Yury Bushmelev wrote: 2012/2/10 Khem Raj raj.k...@gmail.com: Hi Just grepped for the occurances of disabled parallel make and I see around 40 cases on oe-core git grep PARALLEL_MAKE.*=.*\\ recipes* | grep -v # If someone has time to kill then it would help to see if some of these are fixed by time or can be fixed it can help in paralleling the build a bit more. Well, I have some first results! :) 1. Recipes (files) confirmed to fail with P_M enabled (need to have P_M disabled as it is now): meta/recipes-connectivity/bind/bind_9.8.1.bb meta/recipes-extended/slang/slang_2.2.4.bb meta/recipes-extended/tcp-wrappers/tcp-wrappers_7.6.bb meta/recipes-support/js/js_1.7.0+1.8.0rc1.bb meta/recipes-support/pth/pth_2.0.7.bb meta/recipes-devtools/libtool/libtool_2.4.2.bb might need disabled P_M, too: | ./mipsel-oe-linux-libtool --tag=CC --mode=compile ccache mipsel-oe-linux-gcc -mel -mabi=32 -mhard-float -march=mips32 --sysroot=.../tmp/sysroots/dm7020hd -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl -DLT_CONFIG_H='config.h' -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -Os -pipe -g -feliminate-unused-debug-types -c -o libltdl/libltdl_libltdl_la-slist.lo `test -f 'libltdl/slist.c' || echo './'`libltdl/slist.c | /bin/sh: ./mipsel-oe-linux-libtool: /bin/sh: bad interpreter: Text file busy | make[2]: *** [libltdl/libltdl_libltdl_la-slist.lo] Error 126 | make[2]: *** Waiting for unfinished jobs This was a fresh build with clean tmp and sstate-cache. I've just seen this failue for the first time. BB_NUMBER_THREADS = 4 PARALLEL_MAKE = -j 4 I'm seeing this on denzil on Ubuntu 10.04.2 LTS 32-bit. -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] denzil pull request 3
On Fri, Oct 5, 2012 at 2:52 PM, Scott Garman scott.a.gar...@intel.com wrote: nightly-ppc-lsb: kernel compile failure http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc-lsb/builds/82 kernel do_compile failure for mpc8315e_rdb-poky-linux: | BOOTCC arch/powerpc/boot/cuboot-pq2.o | In file included from /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-ppc-lsb/build/build/tmp/work/mpc8315e_rdb-poky-linux/linux-yocto-3.0.32+git1+34e0d2b4b4e9778b31f9ea99ca43f0dc71a7ee23_1+83f422f718cf15633cb4c2d309aa041c3c354f65-r4/linux/arch/powerpc/boot/epapr.c:20:0: | arch/powerpc/boot/libfdt.h:854:1: error: unterminated comment | arch/powerpc/boot/libfdt.h:1:0: error: unterminated #ifndef | BOOTCC arch/powerpc/boot/cuboot-sequoia.o | make[3]: *** [arch/powerpc/boot/epapr.o] Error 1 | make[3]: *** Waiting for unfinished jobs | make[2]: *** [uImage] Error 2 | make[1]: *** [sub-make] Error 2 | make: *** [all] Error 2 | ERROR: oe_runmake failed NOTE: package linux-yocto-3.0.32+git1+34e0d2b4b4e9778b31f9ea99ca43f0dc71a7ee23_1+83f422f718cf15633cb4c2d309aa041c3c354f65-r4: task do_compile: Failed I heard from Matthew McClintock that a fix for this has been sent upstream, sounds like we need to get this merged to our kernel tree. FYI, http://patchwork.ozlabs.org/patch/182260/ -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Secondary Toolchain
On Thu, Oct 4, 2012 at 1:02 PM, Mark Hatle mark.ha...@windriver.com wrote:
We have an issue where we'd like to have an alternative toolchain
(assembler, linker, compiler) available for our customers to selectively
use. However, before we just go off and implement something, I'd like at
least some basic consensus on what the best practice is for doing this work.
Below is my attempt at an early proposal.
Background
Many companies have commercial / highly optimized toolchains for specific
purpose, such as ICC from Intel, LLVM, ARM specific toolchain, etc.. For
(potentially) better performance with some applications a mechanism to both
provide the hooks for the alternative toolchain as well as a way to active
it per-package is desired.
This work assumes that the third party toolchain is generally compatible
with the idea of sysroots, linking to the libc provided by OE, and generally
compatible with GNU conventions.
However, as part of the third party toolchain, it may not be GNU compatible.
This means many Open Source applications simply may not work with this
toolchain. That means that we need to have a way for a toolchain to
blacklist (or whitelist) specific recipes. This way only supported
components can be built by the user, avoiding numerous complaints.
Currently OE has a method to generate an SDK based on the GNU toolchain. We
would like to be able to also export the external toolchain along with the
SDK, effectively providing both the GNU toolchain and the third party
toolchain using the common sysroot.
We need a way to active the third party toolchain on a per-package basis.
This activation will need to use the existing sysroot, but be able to pass
different C, C++, LD, AS and other flags as specified by the third party
toolchain.
Finally third party toolchains should be implemented as layers that can
easily plug into OE.
Implementation
-
Add an OVERRIDE to specify the alternative toolchain. Can this be done
within the layer by doing something like:
OVERRIDE_append = :toolchain-${TOOLCHAIN}
TOOLCHAIN = gnu (or icc)
To activate the toolchain you would use things like:
TOOLCHAIN_pn-bash = 'icc'
To define the correct behavior for the toolchain, the following would need
to be defined (with _toolchain-toolchain):
TARGET_CPPFLAGS
TARGET_CFLAGS
TARGET_CXXFLAGS
TARGET_LDFLAGS
CC
CXX
F77
CPP
LD
CCLD
AR
AS
RANLIB
STRIP
OBJCOPY
OBJDUMP
NM
FULL_OPTIMIZATIONS
DEBUG_OPTIMIZATION
Is anyone aware of any other items that may require additional items? Will
the above actually work? Using the override of the TOOLCHAIN_… will that
actually change the override values or do we get stuck?
This seems orthogonal to actually implementing the recipe which would
procide 'icc'?
-M
Comments/suggestions appreciated!
--Mark
___
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 v2 10/10] libx11.inc: fix build issues for older CentOS distros
On Fri, Sep 28, 2012 at 10:03 AM, Matthew McClintock m...@freescale.com wrote: On Fri, Sep 28, 2012 at 9:52 AM, Burton, Ross ross.bur...@intel.com wrote: On 28 September 2012 02:33, Matthew McClintock m...@freescale.com wrote: Fixes these sorts of issues present on older gcc (CentOS 5.x in this case) | cc1: error: unrecognized command line option -Werror=implicit | cc1: error: unrecognized command line option -Werror=nonnull Took me a minute to realise why this happens. This happens when cross-building because although configure is checking that the flags it uses are supported by the compiler, it's only doing that for the cross and not the host compiler. Right? (upstream bug alert) Yea, I suppose the the host compiler should be checked by autotools if it supports these warning flags. Should this block applying this patch to oe-core or will there be upstream fixes before 1.3? -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] chrpath: We should provide chrpath-replacement-native and install into a native specific directory
Docs need to be updated, there was also a build warning if it was not
installed - did that get removed too?
-M
On Tue, Oct 2, 2012 at 8:13 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
chrpath is assumed to be provided by the build host system. This means
we need to provide a replacement version and install into a specific directory
to avoid races.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-devtools/chrpath/chrpath_0.14.bb
b/meta/recipes-devtools/chrpath/chrpath_0.14.bb
index 679f1aa..bb9b4b6 100644
--- a/meta/recipes-devtools/chrpath/chrpath_0.14.bb
+++ b/meta/recipes-devtools/chrpath/chrpath_0.14.bb
@@ -20,4 +20,7 @@ inherit autotools
# relocatable, so use the one we've just built
CHRPATH_BIN_virtclass-native = ${S}/chrpath
+PROVIDES_append_virtclass-native = chrpath-replacement-native
+NATIVE_PACKAGE_PATH_SUFFIX = /${PN}
+
BBCLASSEXTEND = native nativesdk
___
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] chrpath: We should provide chrpath-replacement-native and install into a native specific directory
On Tue, Oct 2, 2012 at 11:29 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Tue, 2012-10-02 at 16:22 +, McClintock Matthew-B29882 wrote: Docs need to be updated, there was also a build warning if it was not installed - did that get removed too? You still need chrpath installed, this just avoids a different set of problems in nativesdk and corrected ASSUME_PROVIDED. You still need it installed on your host? -M 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] sstate: Add detail to shared area warning
On Tue, Oct 2, 2012 at 5:22 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Wed, 2012-10-03 at 00:11 +0200, Martin Jansa wrote:
On Tue, Oct 02, 2012 at 11:00:53PM +0100, Phil Blundell wrote:
On Tue, 2012-10-02 at 15:00 -0700, Saul Wold wrote:
-bb.warn(The recipe is trying to install files into a shared
area when those files already exist. Those files are:\n %s % \n
.join(match))
+bb.warn(The %s recipe is trying to install files into a shared
area when those files already exist (please fix %s). Those files are:\n
%s % (d.getVar('PN', True), d.getVar('FILE', True), \n
.join(match)))
That seems potentially misleading: the file that needs fixing isn't
necessarily the one that triggers this warning. What would be ideal
would be to have it output the names of all recipes that have tried to
stage the files in question so that the user can make an informed
decision about which one ought to be putting them there.
Maybe something like master.list was before
http://git.openembedded.org/openembedded-core/commit/?id=603daf343ad3f18c8adb799e3625ae2a18d94f56
with added recipe name, but that doesn't detect files already
We can list any sstate manifest files (tmp/sstate-control) also adding
that file which may or may not have a listing of it. We might as well
just grep those files and print matches.
We are not going back to a master.list file, its a performance headache.
I had to do this manually recently, so this error would be very useful ;)
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 09/10] binutils.inc: add vardep on multiarch DISTRO_FEATURE
On Fri, Sep 28, 2012 at 5:32 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Thu, 2012-09-27 at 20:33 -0500, Matthew McClintock wrote:
binutils will build differently if this feature is enabled, so
make the do_configure step depend on it
Signed-off-by: Matthew McClintock m...@freescale.com
---
Not sure if we should try to fix via configure options
v2: update commit message a bit
meta/recipes-devtools/binutils/binutils.inc |2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/binutils/binutils.inc
b/meta/recipes-devtools/binutils/binutils.inc
index ee748a4..ff64882 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -80,6 +80,8 @@ export CC_FOR_BUILD = LD_LIBRARY_PATH= ${BUILD_CC}
export CPP_FOR_BUILD = ${BUILD_CPP}
export CFLAGS_FOR_BUILD = ${BUILD_CFLAGS}
+MULTIARCH := ${@bb.utils.contains(DISTRO_FEATURES, multiarch, yes,
no, d)}
+do_configure[vardeps] += MULTIARCH
do_configure () {
(cd ${S}; gnu-configize) || die Failed to run gnu-configize
oe_runconf
This doesn't make sense. oe_runconf should depend on EXTRA_OECONF and
that should depend on DISTRO_FEATURES so the dependency should already
exist?
OK, maybe... let me just explain what I did to see an issue.
Let's say I did a build without MULTIARCH and everything went fine.
Then I went back and added mutliarch. binutils would not rebuild with
the new features and things would break. With this patch, after added
multiarch binutils would rebuild and the the build work OK.
As you say though, if this was an actual dep it should have rebuilt
already? Has anything changed in this area very recently?
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 10/10] libx11.inc: fix build issues for older CentOS distros
On Fri, Sep 28, 2012 at 9:52 AM, Burton, Ross ross.bur...@intel.com wrote: On 28 September 2012 02:33, Matthew McClintock m...@freescale.com wrote: Fixes these sorts of issues present on older gcc (CentOS 5.x in this case) | cc1: error: unrecognized command line option -Werror=implicit | cc1: error: unrecognized command line option -Werror=nonnull Took me a minute to realise why this happens. This happens when cross-building because although configure is checking that the flags it uses are supported by the compiler, it's only doing that for the cross and not the host compiler. Right? (upstream bug alert) Yea, I suppose the the host compiler should be checked by autotools if it supports these warning flags. -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 09/10] binutils.inc: add vardep on multiarch DISTRO_FEATURE
On Fri, Sep 28, 2012 at 10:06 AM, Matthew McClintock m...@freescale.com wrote:
On Fri, Sep 28, 2012 at 5:32 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Thu, 2012-09-27 at 20:33 -0500, Matthew McClintock wrote:
binutils will build differently if this feature is enabled, so
make the do_configure step depend on it
Signed-off-by: Matthew McClintock m...@freescale.com
---
Not sure if we should try to fix via configure options
v2: update commit message a bit
meta/recipes-devtools/binutils/binutils.inc |2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/binutils/binutils.inc
b/meta/recipes-devtools/binutils/binutils.inc
index ee748a4..ff64882 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -80,6 +80,8 @@ export CC_FOR_BUILD = LD_LIBRARY_PATH= ${BUILD_CC}
export CPP_FOR_BUILD = ${BUILD_CPP}
export CFLAGS_FOR_BUILD = ${BUILD_CFLAGS}
+MULTIARCH := ${@bb.utils.contains(DISTRO_FEATURES, multiarch, yes,
no, d)}
+do_configure[vardeps] += MULTIARCH
do_configure () {
(cd ${S}; gnu-configize) || die Failed to run gnu-configize
oe_runconf
This doesn't make sense. oe_runconf should depend on EXTRA_OECONF and
that should depend on DISTRO_FEATURES so the dependency should already
exist?
OK, maybe... let me just explain what I did to see an issue.
Let's say I did a build without MULTIARCH and everything went fine.
Then I went back and added mutliarch. binutils would not rebuild with
the new features and things would break. With this patch, after added
multiarch binutils would rebuild and the the build work OK.
As you say though, if this was an actual dep it should have rebuilt
already? Has anything changed in this area very recently?
Looking closer it seems like EXTRA_OECONF does not do this quite right
when resolving base_contains parameters:
List of dependencies for variable EXTRA_OECONF is
set(['gettext_oeconf', 'STAGING_DIR_TARGET', 'base_contains',
'TARGET_PREFIX'])
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc-common.inc: Consider multilib when renaming libgcc for debian'ness
On Wed, Sep 26, 2012 at 5:55 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Tue, 2012-09-25 at 18:07 +, McClintock Matthew-B29882 wrote: This should probably go in denzil as well. Lets hold off that as I think we need to fix this in a better way at the core level... This? Where there follow up fixes also? -M commit 42e8c8056719326b68b1602e0699eba00a924d2b Author: Richard Purdie richard.pur...@linuxfoundation.org Date: Wed Sep 26 12:56:58 2012 +0100 packagedata/multilib: Fix search patch for multilib builds The current multilib search path code for packagedata is flawed since it doesn't correctly handle changes in the TARGET_VENDOR/TARGET_OS that multilib may make. This patch enhances the code to correctly build the search paths so multilib packagedata is found correctly. (From OE-Core rev: f50c5d36b2da9b36d56d95a7d89404509a1a3e9b) Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org 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] autotools.bbclass: Add functionality to force a clean of ${B} when reconfiguring (and ${S} != ${B})
On Fri, Sep 28, 2012 at 8:23 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2012-09-26 at 18:07 +0100, Phil Blundell wrote: On Tue, 2012-09-11 at 15:22 +0100, Richard Purdie wrote: Unfortunately whilst rerunning configure and make against a project will mostly work there are situations where it does not correctly do the right thing. In particular, eglibc and gcc will fail out with errors where settings do not match a previously built configuration. It could be argued they are broken but the situation is what it is. There is the possibility of more subtle errors too. FWIW, I just encountered another instance of what appears to be a similar problem (with this patch applied). I had changed my CFLAGS to work around a compiler problem and then just reran the build, which led eventually to: ERROR: Function failed: do_siteconfig_gencache (see /tmp-eglibc/work/mips32el-oe-linux/eglibc/2.16-r11.micro1 +svnr20393/temp/log.do_populate_sysroot.6005 for further information) ERROR: Logfile of failure stored in: /tmp-eglibc/work/mips32el-oe-linux/eglibc/2.16-r11.micro1 +svnr20393/temp/log.do_populate_sysroot.6005 Log data follows: | DEBUG: Executing python function sstate_task_prefunc [...] | DEBUG: Executing shell function do_siteconfig_gencache | configure: WARNING: unrecognized options: --disable-silent-rules, --disable-dependency-tracking, --with-libtool-sysroot | configure: loading cache eglibc_cache | configure: error: `CFLAGS' has changed since the previous run: | configure: former value: `...' | configure: current value: `...' | configure: error: in `/.../tmp-eglibc/work/mips32el-oe-linux/eglibc/2.16-r11.micro1 +svnr20393/site_config_cheetah': | configure: error: changes in the environment can compromise the build | configure: error: run `make distclean' and/or `rm eglibc_cache' and start over | DEBUG: Python function siteconfig_do_siteconfig finished | DEBUG: Python function autotools_do_siteconfig finished | DEBUG: Python function do_siteconfig finished | DEBUG: Python function sstate_task_postfunc finished ERROR: Task 30 (.../oe-core/meta/recipes-core/eglibc/eglibc_2.16.bb, do_populate_sysroot) failed with exit code '1' I also ran into this and have posted a fix (to siteconfig.bbclass) which once applied let my build continue. I've seen this now: ERROR: Logfile of failure stored in: /local/yocto/upstream/label/fedora17-64b/machine/beagleboard/poky/master/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/flex-2.5.35-r3/temp/log.do_configure.26311 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Removing manifest: /local/yocto/upstream/label/fedora17-64b/machine/beagleboard/poky/master/tmp/sysroots/beagleboard/usr/include/FlexLexer.h | DEBUG: Removing manifest: /local/yocto/upstream/label/fedora17-64b/machine/beagleboard/poky/master/tmp/sysroots/beagleboard/usr/lib/libfl.a | DEBUG: Removing manifest: /local/yocto/upstream/label/fedora17-64b/machine/beagleboard/poky/master/tmp/sysroots/beagleboard/usr/lib/libfl_pic.a | DEBUG: Removing manifest: /local/yocto/upstream/label/fedora17-64b/machine/beagleboard/poky/master/tmp/sysroots/beagleboard/usr/include/ | DEBUG: Removing manifest: /local/yocto/upstream/label/fedora17-64b/machine/beagleboard/poky/master/tmp/sysroots/beagleboard/usr/share/ | DEBUG: Removing manifest: /local/yocto/upstream/label/fedora17-64b/machine/beagleboard/poky/master/tmp/sysroots/beagleboard/usr/lib/ | DEBUG: Removing manifest: /local/yocto/upstream/label/fedora17-64b/machine/beagleboard/poky/master/tmp/sysroots/beagleboard/usr/ | DEBUG: Python function sysroot_cleansstate finished | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common'] | DEBUG: Executing shell function autotools_preconfigure | DEBUG: Shell function autotools_preconfigure finished | DEBUG: Executing shell function do_configure | automake (GNU automake) 1.12.3 | Copyright (C) 2012 Free Software Foundation, Inc. | License GPLv2+: GNU GPL version 2 or later http://gnu.org/licenses/gpl-2.0.html | This is free software: you are free to change and redistribute it. | There is NO WARRANTY, to the extent permitted by law. | | Written by Tom Tromey tro...@redhat.com |and Alexandre Duret-Lutz a...@gnu.org. | AUTOV is 1.12 | NOTE: Executing autoreconf --verbose --install --force --exclude=autopoint -I /local/yocto/upstream/label/fedora17-64b/machine/beagleboard/poky/master/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/flex-2.5.35-r3/flex-2.5.35/m4/ -I/local/yocto/upstream/label/fedora17-64b/machine/beagleboard/poky/master/tmp/sysroots/x86_64-linux/usr/share/aclocal-1.12 -I /local/yocto/upstream/label/fedora17-64b/machine/beagleboard/poky/master/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/flex-2.5.35-r3/flex-2.5.35/aclocal-copy/ | autoreconf: Entering directory `.' | autoreconf: running: aclocal -I
Re: [OE-core] perl install error
Khem, I'm just not looking at a similiar issue. Do this: cat tmp/sstate-control/manifest-* | grep usr/lib/perl5 And see which recipe is making this folder. It should be the perl recipe, first not some other recipe... Side question are you using FSL layers? -M On Thu, Sep 27, 2012 at 10:28 PM, Khem Raj raj.k...@gmail.com wrote: On Sep 27, 2012, at 8:22 PM, Khem Raj raj.k...@gmail.com wrote: Hi On ppc64 I am getting | Warning: perl appears in your path in the following locations beyond where | we just installed it: | /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/perl-native/perl | | make[1]: Nothing to be done for `install.man'. | make[1]: Leaving directory `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/perl-5.14.2' | ln: failed to create symbolic link `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/image//usr/lib64/perl5': No such file or directory | ERROR: Function failed: do_install (see /work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/temp/log.do_install.6656 for further information) ERROR: Task 1679 (/work/yocto/poky/meta/recipes-devtools/perl/perl_5.14.2.bb, do_install) failed with exit code '1' NOTE: Tasks Summary: Attempted 4082 tasks of which 4057 didn't need to be rerun and 1 failed. It was working fine yesterday anyone else seeing it ? If I revert perl: Fix nativesdk install path Commit 38234f2e276356b1d77a87ceabc486107e336d19 tried to fix the sed expressions by anchoring the left side of the search regexp to prevent $prefix$prefix type expression in the perl config. For nativesdk this is not enough. Adding anchors on both side fixes this. Signed-off-by: Christian Glindkamp christian.glindk...@taskit.de Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org It works again Thanks -Khem ___ 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] perl install error
On Thu, Sep 27, 2012 at 11:18 PM, Khem Raj raj.k...@gmail.com wrote: On Sep 27, 2012, at 8:52 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: On Thu, Sep 27, 2012 at 10:43 PM, Khem Raj raj.k...@gmail.com wrote: On Sep 27, 2012, at 8:40 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: Khem, I'm just not looking at a similiar issue. Do this: just 'not' or just 'now' ? cat tmp/sstate-control/manifest-* | grep usr/lib/perl5 And see which recipe is making this folder. It should be the perl recipe, first not some other recipe… cat sstate-control/manifest-* | grep usr/lib/perl5 return nothing Maybe this is not the same root cause then. reverting that commit fixed it. before that I tried to cleans state clean all perl and perl-native to no avail. OK, well we got the same error and ours was from another sstate-cache installing files in /usr/lib/perl5 before perl installed it's own symlink. cleaning cache for perl did not help either. Reverting that patch could have causes rebuilds and change of ordering (possibly) that might mask the error a little longer. If ours are related. -M Side question are you using FSL layers? yes Is libhugetlbfs getting built? No ___ 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] perl install error
On Thu, Sep 27, 2012 at 11:38 PM, Khem Raj raj.k...@gmail.com wrote: On Sep 27, 2012, at 9:23 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: On Thu, Sep 27, 2012 at 11:18 PM, Khem Raj raj.k...@gmail.com wrote: On Sep 27, 2012, at 8:52 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: On Thu, Sep 27, 2012 at 10:43 PM, Khem Raj raj.k...@gmail.com wrote: On Sep 27, 2012, at 8:40 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: Khem, I'm just not looking at a similiar issue. Do this: just 'not' or just 'now' ? cat tmp/sstate-control/manifest-* | grep usr/lib/perl5 And see which recipe is making this folder. It should be the perl recipe, first not some other recipe… cat sstate-control/manifest-* | grep usr/lib/perl5 return nothing Maybe this is not the same root cause then. reverting that commit fixed it. before that I tried to cleans state clean all perl and perl-native to no avail. OK, well we got the same error and ours was from another sstate-cache installing files in /usr/lib/perl5 before perl installed it's own symlink. cleaning cache for perl did not help either. Reverting that patch could have causes rebuilds and change of ordering (possibly) that might mask the error a little longer. If ours are related. Does it mean that if I invalidate whole state it will work ? thats kind of gross I think just making sure perl is deployed to sysroot first fixes this issue. For us we were simply missing a 'DEPENDS = perl' for a recipe which installed stuff in /usr/lib/perl5 - if perl is deployed to sysroot first the symlink is always in place properly. -M -M Side question are you using FSL layers? yes Is libhugetlbfs getting built? No ___ 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 2/2] libx11: fix nativesdk build on older distros
On Wed, Sep 26, 2012 at 4:30 AM, Burton, Ross ross.bur...@intel.com wrote:
On 26 September 2012 00:11, Daniel Stone dan...@fooishbar.org wrote:
The best fix is to just #define _GNU_SOURCE at the top of makekeys
then, and push that upstream (mail patch to xorg-de...@lists.x.org).
Actually, it isn't, as that breaks non-glibc badly. glibc takes
_GNU_SOURCE to mean 'please add useful GNU extensions to this POSIX
wasteland', whereas BSD and/or Solaris take it to mean 'please make
this only GNU and don't use any other extensions at all'. So we have
to do whatever AC_USE_SYSTEM_EXTENSIONS does, because that really is
the only thing that actually works.
What do you mean non-glibc? :)
Ignoring Minix as a build host (I think that's reasonable),
AC_USE_SYSTEM_EXTENSIONS defines _ALL_SOURCE _GNU_SOURCE
_POSIX_PTHREAD_SEMANTICS _TANDEM_SOURCE, and does a compile-time
sanity test of __EXTENSIONS__ (because it's possible that some
combination of these defines make the system headers unusable on
Solaris).
This is annoying. How about for oe-core we patch in -D_GNU_SOURCE to
src/util/Makefile.am's CPPFLAGS definition and I'll discuss with
xorg-dev for a proper fix?
Would this be OK for now in libx11.inc?
-export CFLAGS_FOR_BUILD = ${BUILD_CFLAGS}
+export CFLAGS_FOR_BUILD = ${BUILD_CFLAGS} -D_GNU_SOURCE
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] libx11: fix nativesdk build on older distros
On Tue, Sep 25, 2012 at 11:48 AM, Burton, Ross ross.bur...@intel.com wrote: Whoops, I dropped oe-core. On 25 September 2012 16:38, McClintock Matthew-B29882 b29...@freescale.com wrote: Older libc do not have this defined, we can use the -D_GNU_SOURCE to the compiler to prevent generating calls to this function and make linking work Why isn't this from configure.ac working? # Set common system defines for POSIX extensions, such as _GNU_SOURCE # Must be called before any macros that run the compiler (like AC_PROG_LIBTOOL) # to avoid autoconf errors. AC_USE_SYSTEM_EXTENSIONS Do these make it to CC_FOR_BUILD? Here is what it looks like before: AC_USE_SYSTEM_EXTENSIONS sets _GNU_SOURCE (and more) using AC_DEFINE, so they end up in config.h... which isn't being included in makekeys.c. So the correct and upstreamable fix is to include config.h from makekeys.c. I read somewhere (very informative - I know - but I've forgot where) that you are not supposed to include config.h for CC_FOR_BUILD targets? I'm not expert and just double checking on this bit as the correct solution. --M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc-common.inc: Consider multilib when renaming libgcc for debian'ness
This should probably go in denzil as well. -M On Tue, Sep 25, 2012 at 4:42 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Mon, 2012-09-24 at 15:24 -0700, Khem Raj wrote: When doing multilib builds rpm does not find libgcc1 for lib32 multilib because its not honoring the debian renaming scheme for libgcc-multilib. Lets add MLPREFIX to fix it. Signed-off-by: Khem Raj raj.k...@gmail.com --- meta/recipes-devtools/gcc/gcc-common.inc |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Merged to master, thanks. 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] kexec-tools: admit mips as a COMPATIBLE_HOST
On Mon, Sep 24, 2012 at 1:28 PM, Khem Raj raj.k...@gmail.com wrote: On Mon, Sep 24, 2012 at 4:49 AM, Phil Blundell ph...@gnu.org wrote: -COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-(linux|freebsd.*)' +COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*|mips.*)-(linux|freebsd.*)' I wonder if this expression should be removed completely now that mips is added we dont have any supported arch left. All the powerpc64 target still won't work (the Freescale ones at least). -M ___ 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] libx11.inc: disable warnings that don't work on certain compilers
On Mon, Sep 24, 2012 at 3:00 PM, Martin Jansa martin.ja...@gmail.com wrote:
On Mon, Sep 24, 2012 at 02:55:45PM -0500, Matthew McClintock wrote:
Fixes these sorts of issues present on older gcc (CentOS 5.x in this case)
| cc1: error: unrecognized command line option -Werror=implicit
| cc1: error: unrecognized command line option -Werror=nonnull
| cc1: error: unrecognized command line option -Werror=init-self
| cc1: error: unrecognized command line option -Werror=main
| cc1: error: unrecognized command line option -Werror=missing-braces
| cc1: error: unrecognized command line option -Werror=sequence-point
| cc1: error: unrecognized command line option -Werror=return-type
| cc1: error: unrecognized command line option -Werror=trigraphs
| cc1: error: unrecognized command line option -Werror=array-bounds
| cc1: error: unrecognized command line option -Werror=write-strings
| cc1: error: unrecognized command line option -Werror=address
| cc1: error: unrecognized command line option -Werror=int-to-pointer-cast
| cc1: error: unrecognized command line option -Werror=pointer-to-int-cast
Shouldn't it be applied only for -native? version?
That's reasonable. But, suppressing warnings to compile logs also did
not seem to matter much since we don't go line by line on warnings in
compile logs (does anyone?). I'll go with the consensus though.
-M
Cheers,
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/recipes-graphics/xorg-lib/libx11.inc |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/xorg-lib/libx11.inc
b/meta/recipes-graphics/xorg-lib/libx11.inc
index 3ecd9e5..0e99442 100644
--- a/meta/recipes-graphics/xorg-lib/libx11.inc
+++ b/meta/recipes-graphics/xorg-lib/libx11.inc
@@ -11,7 +11,7 @@ inherit siteinfo
FILESPATH = ${FILE_DIRNAME}/libx11
PE = 1
-INC_PR = r8
+INC_PR = r9
PROVIDES = virtual/libx11
@@ -23,6 +23,7 @@ DEPENDS += xproto xextproto xtrans libxcb kbproto
inputproto
DEPENDS += xproto-native
EXTRA_OECONF += --with-keysymdefdir=${STAGING_INCDIR}/X11/
+EXTRA_OEMAKE = '-e CWARNFLAGS='
# Let people with incredibly archaic requirements enable Xcms and BigFont,
but
# disable them by default.
--
1.7.9.7
___
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
___
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 2/2] libx11: fix nativesdk build on older distros
On Mon, Sep 24, 2012 at 2:55 PM, Matthew McClintock m...@freescale.com wrote:
makekeys-makekeys.o: In function `main':
makekeys.c:(.text+0x85): undefined reference to `__isoc99_sscanf'
makekeys.c:(.text+0xa7): undefined reference to `__isoc99_sscanf'
collect2: ld returned 1 exit status
make: *** [makekeys] Error 1
Older libc do not have this defined, we can use the -D_GNU_SOURCE
to the compiler to prevent generating calls to this function and
make linking work
Signed-off-by: Matthew McClintock m...@freescale.com
---
.../xorg-lib/libx11/use_host_cc_for_utils.patch| 12
meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb |3 ++-
2 files changed, 14 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-graphics/xorg-lib/libx11/use_host_cc_for_utils.patch
diff --git
a/meta/recipes-graphics/xorg-lib/libx11/use_host_cc_for_utils.patch
b/meta/recipes-graphics/xorg-lib/libx11/use_host_cc_for_utils.patch
new file mode 100644
index 000..08ba39a
--- /dev/null
+++ b/meta/recipes-graphics/xorg-lib/libx11/use_host_cc_for_utils.patch
@@ -0,0 +1,12 @@
+Index: libX11-1.5.0/src/Makefile.am
+===
+--- libX11-1.5.0.orig/src/Makefile.am
libX11-1.5.0/src/Makefile.am
+@@ -420,6 +420,6 @@ ks_tables.h: $(KEYSYMDEFS) $(top_builddi
+ mv ks_tables_h $@
+
+ $(top_builddir)/src/util/makekeys$(EXEEXT): force
+- cd util $(MAKE)
++ cd util $(MAKE) CC=gcc CCLD=gcc LDFLAGS= CFLAGS=-D_GNU_SOURCE
I kicked off a build right after testing on one machine, and this is
not quite right. Mostly I think I Need more CFLAGS to build 32 or 64
bit native binaries so they can run on the target system properly.
E.g. if I don't have:
/lib/ld.so.1: No such file or directory
-M
+
+ force:
diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
index 94e2051..3e00dd8 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
@@ -1,11 +1,12 @@
require libx11.inc
inherit gettext
-PR = ${INC_PR}.2
+PR = ${INC_PR}.3
BBCLASSEXTEND = native nativesdk
SRC_URI += file://keysymdef_include.patch
+SRC_URI_append_virtclass-nativesdk += file://use_host_cc_for_utils.patch
SRC_URI[md5sum] = 78b4b3bab4acbdf0abcfca30a8c70cc6
SRC_URI[sha256sum] =
c382efd7e92bfc3cef39a4b7f1ecf2744ba4414a705e3bc1e697f75502bd4d86
--
1.7.9.7
___
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 4/9] rpm: Use link time check for libssp
On Fri, Jun 15, 2012 at 1:12 AM, Khem Raj raj.k...@gmail.com wrote: -fstack-protector needs libssp to link with so when checking for this option support we need to find if libssp is staged in root file system Won't this still break on systems without libssp where sstate-cache was built on systems with libssp? -M Signed-off-by: Khem Raj raj.k...@gmail.com --- .../rpm/rpm/fstack-protector-configure-check.patch | 13 + meta/recipes-devtools/rpm/rpm_5.4.9.bb |1 + 2 files changed, 14 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-devtools/rpm/rpm/fstack-protector-configure-check.patch diff --git a/meta/recipes-devtools/rpm/rpm/fstack-protector-configure-check.patch b/meta/recipes-devtools/rpm/rpm/fstack-protector-configure-check.patch new file mode 100644 index 000..84d0430 --- /dev/null +++ b/meta/recipes-devtools/rpm/rpm/fstack-protector-configure-check.patch @@ -0,0 +1,13 @@ +Index: rpm-5.4.0/configure.ac +=== +--- rpm-5.4.0.orig/configure.ac2012-06-01 11:41:19.741480143 -0700 rpm-5.4.0/configure.ac 2012-06-01 11:41:51.773481676 -0700 +@@ -193,7 +193,7 @@ + my_save_cflags=$CFLAGS + CFLAGS=$c + AC_MSG_CHECKING([whether GCC supports $c]) +- AC_COMPILE_IFELSE([AC_LANG_PROGRAM([])], ++ AC_LINK_IFELSE([AC_LANG_PROGRAM([])], + [AC_MSG_RESULT([yes])] + [my_cflags=$c], + [AC_MSG_RESULT([no])] diff --git a/meta/recipes-devtools/rpm/rpm_5.4.9.bb b/meta/recipes-devtools/rpm/rpm_5.4.9.bb index 404916a..ccf015a 100644 --- a/meta/recipes-devtools/rpm/rpm_5.4.9.bb +++ b/meta/recipes-devtools/rpm/rpm_5.4.9.bb @@ -74,6 +74,7 @@ SRC_URI = http://www.rpm5.org/files/rpm/rpm-5.4/rpm-5.4.9-0.20120508.src.rpm;ex file://rpm-pkgconfigdeps.patch \ file://uclibc-support.patch \ file://rpmatch.patch \ + file://fstack-protector-configure-check.patch \ SRC_URI[md5sum] = 60d56ace884340c1b3fcac6a1d58e768 -- 1.7.5.4 ___ 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] libx11.inc: disable warnings that don't work on certain compilers
On Mon, Sep 24, 2012 at 3:06 PM, Matthew McClintock m...@freescale.com wrote:
On Mon, Sep 24, 2012 at 3:00 PM, Martin Jansa martin.ja...@gmail.com wrote:
On Mon, Sep 24, 2012 at 02:55:45PM -0500, Matthew McClintock wrote:
Fixes these sorts of issues present on older gcc (CentOS 5.x in this case)
| cc1: error: unrecognized command line option -Werror=implicit
| cc1: error: unrecognized command line option -Werror=nonnull
| cc1: error: unrecognized command line option -Werror=init-self
| cc1: error: unrecognized command line option -Werror=main
| cc1: error: unrecognized command line option -Werror=missing-braces
| cc1: error: unrecognized command line option -Werror=sequence-point
| cc1: error: unrecognized command line option -Werror=return-type
| cc1: error: unrecognized command line option -Werror=trigraphs
| cc1: error: unrecognized command line option -Werror=array-bounds
| cc1: error: unrecognized command line option -Werror=write-strings
| cc1: error: unrecognized command line option -Werror=address
| cc1: error: unrecognized command line option -Werror=int-to-pointer-cast
| cc1: error: unrecognized command line option -Werror=pointer-to-int-cast
Shouldn't it be applied only for -native? version?
That's reasonable. But, suppressing warnings to compile logs also did
not seem to matter much since we don't go line by line on warnings in
compile logs (does anyone?). I'll go with the consensus though.
Actually, this makes sense now because I'm seeing issues with
non-nativesdk packages with the '-e' I've added... thought I build
tested that... ;(
-M
-M
Cheers,
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/recipes-graphics/xorg-lib/libx11.inc |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/xorg-lib/libx11.inc
b/meta/recipes-graphics/xorg-lib/libx11.inc
index 3ecd9e5..0e99442 100644
--- a/meta/recipes-graphics/xorg-lib/libx11.inc
+++ b/meta/recipes-graphics/xorg-lib/libx11.inc
@@ -11,7 +11,7 @@ inherit siteinfo
FILESPATH = ${FILE_DIRNAME}/libx11
PE = 1
-INC_PR = r8
+INC_PR = r9
PROVIDES = virtual/libx11
@@ -23,6 +23,7 @@ DEPENDS += xproto xextproto xtrans libxcb kbproto
inputproto
DEPENDS += xproto-native
EXTRA_OECONF += --with-keysymdefdir=${STAGING_INCDIR}/X11/
+EXTRA_OEMAKE = '-e CWARNFLAGS='
# Let people with incredibly archaic requirements enable Xcms and BigFont,
but
# disable them by default.
--
1.7.9.7
___
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
___
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 4/9] rpm: Use link time check for libssp
On Mon, Sep 24, 2012 at 4:18 PM, Khem Raj raj.k...@gmail.com wrote: On Mon, Sep 24, 2012 at 1:36 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: Won't this still break on systems without libssp where sstate-cache was built on systems with libssp? these two systems are not same IMO so native sstate should not be shared here it will break more than rpm. If you build a binary and it depends on libssp it's its going to break if that changes between builds. Can we just always disable libssp? -M ___ 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] libx11.inc: disable warnings that don't work on certain compilers
On Mon, Sep 24, 2012 at 4:07 PM, Chris Larson clar...@kergoth.com wrote: On Mon, Sep 24, 2012 at 1:43 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: On Mon, Sep 24, 2012 at 3:06 PM, Matthew McClintock m...@freescale.com wrote: On Mon, Sep 24, 2012 at 3:00 PM, Martin Jansa martin.ja...@gmail.com wrote: On Mon, Sep 24, 2012 at 02:55:45PM -0500, Matthew McClintock wrote: Fixes these sorts of issues present on older gcc (CentOS 5.x in this case) | cc1: error: unrecognized command line option -Werror=implicit | cc1: error: unrecognized command line option -Werror=nonnull | cc1: error: unrecognized command line option -Werror=init-self | cc1: error: unrecognized command line option -Werror=main | cc1: error: unrecognized command line option -Werror=missing-braces | cc1: error: unrecognized command line option -Werror=sequence-point | cc1: error: unrecognized command line option -Werror=return-type | cc1: error: unrecognized command line option -Werror=trigraphs | cc1: error: unrecognized command line option -Werror=array-bounds | cc1: error: unrecognized command line option -Werror=write-strings | cc1: error: unrecognized command line option -Werror=address | cc1: error: unrecognized command line option -Werror=int-to-pointer-cast | cc1: error: unrecognized command line option -Werror=pointer-to-int-cast Shouldn't it be applied only for -native? version? That's reasonable. But, suppressing warnings to compile logs also did not seem to matter much since we don't go line by line on warnings in compile logs (does anyone?). I'll go with the consensus though. Actually, this makes sense now because I'm seeing issues with non-nativesdk packages with the '-e' I've added... thought I build tested that... ;( Why is -e being added? It's almost always better to add the vars you need explicitly, imo. I wish we could change the default EXTRA_OEMAKE to drop it, personally. It can cause odd unintended consequences. I think this was a holdover from trying to fix the issue fixed by patch 2/2. I don't think it belogs - I was working on this Friday and forgot everything today ;) -M -- Christopher Larson ___ 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 2/2] libx11: fix nativesdk build on older distros
On Mon, Sep 24, 2012 at 4:08 PM, Chris Larson clar...@kergoth.com wrote: On Mon, Sep 24, 2012 at 1:13 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: On Mon, Sep 24, 2012 at 2:55 PM, Matthew McClintock m...@freescale.com wrote: makekeys-makekeys.o: In function `main': makekeys.c:(.text+0x85): undefined reference to `__isoc99_sscanf' makekeys.c:(.text+0xa7): undefined reference to `__isoc99_sscanf' collect2: ld returned 1 exit status make: *** [makekeys] Error 1 Older libc do not have this defined, we can use the -D_GNU_SOURCE to the compiler to prevent generating calls to this function and make linking work Signed-off-by: Matthew McClintock m...@freescale.com --- .../xorg-lib/libx11/use_host_cc_for_utils.patch| 12 meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb |3 ++- 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-graphics/xorg-lib/libx11/use_host_cc_for_utils.patch diff --git a/meta/recipes-graphics/xorg-lib/libx11/use_host_cc_for_utils.patch b/meta/recipes-graphics/xorg-lib/libx11/use_host_cc_for_utils.patch new file mode 100644 index 000..08ba39a --- /dev/null +++ b/meta/recipes-graphics/xorg-lib/libx11/use_host_cc_for_utils.patch @@ -0,0 +1,12 @@ +Index: libX11-1.5.0/src/Makefile.am +=== +--- libX11-1.5.0.orig/src/Makefile.am libX11-1.5.0/src/Makefile.am +@@ -420,6 +420,6 @@ ks_tables.h: $(KEYSYMDEFS) $(top_builddi + mv ks_tables_h $@ + + $(top_builddir)/src/util/makekeys$(EXEEXT): force +- cd util $(MAKE) ++ cd util $(MAKE) CC=gcc CCLD=gcc LDFLAGS= CFLAGS=-D_GNU_SOURCE Isn't the makekeys build already using CC_FOR_BUILD? That's what is implied by the libx11.inc export of those variables. So it seems a bit unnecessary to pass in gcc expliciltly. I think this is probably what I was looking for... will try to respin. -M -- Christopher Larson ___ 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 2/2] libx11: fix nativesdk build on older distros
On Mon, Sep 24, 2012 at 4:52 PM, Saul Wold s...@linux.intel.com wrote:
On 09/24/2012 12:55 PM, Matthew McClintock wrote:
makekeys-makekeys.o: In function `main':
makekeys.c:(.text+0x85): undefined reference to `__isoc99_sscanf'
makekeys.c:(.text+0xa7): undefined reference to `__isoc99_sscanf'
collect2: ld returned 1 exit status
make: *** [makekeys] Error 1
Older libc do not have this defined, we can use the -D_GNU_SOURCE
to the compiler to prevent generating calls to this function and
make linking work
Signed-off-by: Matthew McClintock m...@freescale.com
---
.../xorg-lib/libx11/use_host_cc_for_utils.patch| 12
meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb |3 ++-
2 files changed, 14 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-graphics/xorg-lib/libx11/use_host_cc_for_utils.patch
diff --git
a/meta/recipes-graphics/xorg-lib/libx11/use_host_cc_for_utils.patch
b/meta/recipes-graphics/xorg-lib/libx11/use_host_cc_for_utils.patch
new file mode 100644
index 000..08ba39a
--- /dev/null
+++ b/meta/recipes-graphics/xorg-lib/libx11/use_host_cc_for_utils.patch
This patch needs a header!
Yes!
@@ -0,0 +1,12 @@
+Index: libX11-1.5.0/src/Makefile.am
+===
+--- libX11-1.5.0.orig/src/Makefile.am
libX11-1.5.0/src/Makefile.am
+@@ -420,6 +420,6 @@ ks_tables.h: $(KEYSYMDEFS) $(top_builddi
+ mv ks_tables_h $@
+
+ $(top_builddir)/src/util/makekeys$(EXEEXT): force
+- cd util $(MAKE)
++ cd util $(MAKE) CC=gcc CCLD=gcc LDFLAGS= CFLAGS=-D_GNU_SOURCE
Is hardcoding 'gcc' here really the right thing to do?
Probably not, Chris has made some other suggestions so I will look at
a better v2.
-M
+
+ force:
diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
index 94e2051..3e00dd8 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
@@ -1,11 +1,12 @@
require libx11.inc
inherit gettext
-PR = ${INC_PR}.2
+PR = ${INC_PR}.3
BBCLASSEXTEND = native nativesdk
SRC_URI += file://keysymdef_include.patch
+SRC_URI_append_virtclass-nativesdk +=
file://use_host_cc_for_utils.patch
SRC_URI[md5sum] = 78b4b3bab4acbdf0abcfca30a8c70cc6
SRC_URI[sha256sum] =
c382efd7e92bfc3cef39a4b7f1ecf2744ba4414a705e3bc1e697f75502bd4d86
___
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] libx11.inc: disable warnings that don't work on certain compilers
On Mon, Sep 24, 2012 at 3:52 PM, Burton, Ross ross.bur...@intel.com wrote: On 24 September 2012 21:06, McClintock Matthew-B29882 b29...@freescale.com wrote: Shouldn't it be applied only for -native? version? That's reasonable. But, suppressing warnings to compile logs also did not seem to matter much since we don't go line by line on warnings in compile logs (does anyone?). I'll go with the consensus though. I'd prefer this to be a -native only thing too. I think the CWARNFLAGS needs to be on all the though (native, nativesdk, etc), '-e' can go away entirely. -M Ross ___ 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] multilib errors
On Wed, Sep 19, 2012 at 6:03 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: I have seen these errors as well. It definitely should be doing these checks Even for lib64-nativesdk-libtool? It's doing multilib processing on nativesdk recipes? -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tune-ppce6500.inc: add e6500 tune files
On Tue, Sep 18, 2012 at 5:19 PM, Khem Raj raj.k...@gmail.com wrote: On Tue, Sep 18, 2012 at 3:08 PM, Matthew McClintock m...@freescale.com wrote: Also supports a new altivec TUNE_FEATURE is altivec feature specific to e6500 ? I thought there should be more tunes using it Nothing else AFAIK... other layers could be doing interesting things here. 86xx parts were the last to have Altivec and those don't build within Yocto.. they can use this TUNE_FEATURE :) -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eglibc_2.16.bb: replace patch with updated version that supportds e6500
On Tue, Sep 18, 2012 at 5:30 PM, Khem Raj raj.k...@gmail.com wrote: On Tue, Sep 18, 2012 at 3:23 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: It's just renaming the patch, so it's replacing ppc-sqrt.patch with glibc.fix_sqrt2.patch - and these are not authored by me... which I realize I forgot to add upstream-status as well. OK now I see. The shadowing is there. I dont like renaming the patch. Is there any reason why its renamed to glibc.fix_sqrt2.patch ? its easy to spot changes if it was not renamed Internal patch name. I can change it if needed. But, then I have to track patch names differences between internal and external. -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eglibc_2.16.bb: replace patch with updated version that supportds e6500
On Tue, Sep 18, 2012 at 5:33 PM, Khem Raj raj.k...@gmail.com wrote: On Tue, Sep 18, 2012 at 3:32 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: Internal patch name. I can change it if needed. But, then I have to track patch names differences between internal and external. Not that I am opposed to it but its hard to review as I said. cant internal be changed ? Ha ha ha... ;) -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] insane.bbclass: skip checking arch (machine/bits) for powerpc kernel recipe
On Tue, Sep 18, 2012 at 5:44 PM, Khem Raj raj.k...@gmail.com wrote: On Tue, Sep 18, 2012 at 3:08 PM, Matthew McClintock m...@freescale.com wrote: For a 32-bit machine, we still might always (or optionally) want to build a 64-bit kernel so we add an exception. Signed-off-by: Matthew McClintock m...@freescale.com --- Not sure if we should just skip for all virtual/kernel's? meta/classes/insane.bbclass |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass index e74eb3f..2ca1b49 100644 --- a/meta/classes/insane.bbclass +++ b/meta/classes/insane.bbclass @@ -366,11 +366,13 @@ def package_qa_check_arch(path,name,d, elf, messages): # Check the architecture and endiannes of the binary if not ((machine == elf.machine()) or \ - (virtual/kernel in provides) and (target_os == linux-gnux32)): + (virtual/kernel in provides) and (target_os == linux-gnux32) or \ + (virtual/kernel in provides) and (target_arch == powerpc)): I feel using powerpc target_arch here is a broad brush. Can there be some other variable in metadata that could indicate 64bit kernel and a 32bit ppc userspace combo of some sort ? or may be a variable stating that this machine's kernel is 64bit and use that here instead. I added BUILD_64BIT_KERNEL in my layer for building a 64-bit kernel on a 32-bit machine, we could use this (or another better name) -M messages.append(Architecture did not match (%d to %d) on %s % \ (machine, elf.machine(), package_qa_clean_path(path,d))) elif not ((bits == elf.abiSize()) or \ - (virtual/kernel in provides) and (target_os == linux-gnux32)): + (virtual/kernel in provides) and (target_os == linux-gnux32) or \ + (virtual/kernel in provides) and (target_arch == powerpc)): messages.append(Bit size did not match (%d to %d) %s on %s % \ (bits, elf.abiSize(), bpn, package_qa_clean_path(path,d))) elif not littleendian == elf.isLittleEndian(): -- 1.7.9.7 ___ 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
[OE-core] multilib errors
Is anyone else seeing: WARNING: Unable to get checksum for lib64-nativesdk-libtool SRC_URI entry trailingslash.patch: file could not be found WARNING: Unable to get checksum for lib64-nativesdk-libtool SRC_URI entry prefix-manpage-fix.patch: file could not be found WARNING: Unable to get checksum for lib64-nativesdk-libtool SRC_URI entry rename-with-sysroot.patch: file could not be found WARNING: Unable to get checksum for lib64-nativesdk-libtool SRC_URI entry use-sysroot-in-libpath.patch: file could not be found WARNING: Unable to get checksum for lib64-nativesdk-libtool SRC_URI entry fix-final-rpath.patch: file could not be found WARNING: Unable to get checksum for lib64-nativesdk-libtool SRC_URI entry avoid_absolute_paths_for_general_utils.patch: file could not be found WARNING: Unable to get checksum for lib64-nativesdk-libtool SRC_URI entry fix-rpath.patch: file could not be found WARNING: Unable to get checksum for lib64-nativesdk-libtool SRC_URI entry respect-fstack-protector.patch: file could not be found WARNING: Unable to get checksum for lib64-nativesdk-libtool SRC_URI entry norm-rpath.patch: file could not be found WARNING: Unable to get checksum for lib64-nativesdk-libtool SRC_URI entry prefix.patch: file could not be found WARNING: Unable to get checksum for lib64-nativesdk-libtool SRC_URI entry fixinstall.patch: file could not be found WARNING: Unable to get checksum for lib64-build-appliance-image SRC_URI entry Yocto_Build_Appliance.vmx: file could not be found WARNING: Unable to get checksum for lib64-build-appliance-image SRC_URI entry Yocto_Build_Appliance.vmxf: file could not be found With multilib enabled? Have not debuged but it looks like something is parsing SRC_URI for recipes under multilib when it should not be. -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eglibc_2.16.bb: replace patch with updated version that supportds e6500
On Tue, Sep 18, 2012 at 5:35 PM, Matthew McClintock m...@freescale.com wrote: On Tue, Sep 18, 2012 at 5:33 PM, Khem Raj raj.k...@gmail.com wrote: On Tue, Sep 18, 2012 at 3:32 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: Internal patch name. I can change it if needed. But, then I have to track patch names differences between internal and external. Not that I am opposed to it but its hard to review as I said. cant internal be changed ? Ha ha ha... Please hold off on this patch - I believe I've found some more issues (besides the sign-off and upstream-status on the patch) -M ;) -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eglibc_2.16.bb: refresh ppc_slow_ieee754_sqrt.patch for e6500
On Tue, Sep 18, 2012 at 5:08 PM, Matthew McClintock m...@freescale.com wrote:
Make same changes for e6500 fpu as done with others
This patch was the problem, I needed to update this for e500mc as well
since the glibc.fix_sqrt2.patch updates it as well. Will submit v2 of
both of the patches.
-M
Signed-off-by: Matthew McClintock m...@freescale.com
---
.../eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch | 101
meta/recipes-core/eglibc/eglibc_2.16.bb|2 +-
2 files changed, 84 insertions(+), 19 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch
b/meta/recipes-core/eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch
index 9a932ff..f432b72 100644
--- a/meta/recipes-core/eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch
+++ b/meta/recipes-core/eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch
@@ -5,9 +5,9 @@ Signed-off-by: Khem Raj raj.k...@gmail.com
Upstream-Status: Pending
Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
===
libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c 2012-07-03
22:36:01.172386436 -0700
-+++ libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c 2012-07-03
23:04:37.396469515 -0700
-@@ -40,7 +40,7 @@
+--- libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
+@@ -40,7 +40,7 @@ static const float half = 0.5;
simultaneously. */
double
@@ -16,7 +16,7 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
{
if (__builtin_expect (b 0, 1))
{
-@@ -77,7 +77,7 @@
+@@ -77,7 +77,7 @@ __ieee754_sqrt (double b)
/* Handle small numbers by scaling. */
if (__builtin_expect ((u.parts.msw 0x7ff0) = 0x0200,
0))
@@ -25,7 +25,7 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
#define FMADD(a_, c_, b_) \
({ double __r;\
-@@ -126,4 +126,12 @@
+@@ -126,4 +126,12 @@ __ieee754_sqrt (double b)
}
return f_wash (b);
}
@@ -40,9 +40,9 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
strong_alias (__ieee754_sqrt, __sqrt_finite)
Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
===
libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c 2012-07-03
22:36:01.172386436 -0700
-+++ libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c 2012-07-03
23:07:06.260476775 -0700
-@@ -38,7 +38,7 @@
+--- libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
+@@ -38,7 +38,7 @@ static const float threehalf = 1.5;
square root. */
float
@@ -51,7 +51,7 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
{
if (__builtin_expect (b 0, 1))
{
-@@ -93,4 +93,10 @@
+@@ -93,4 +93,10 @@ __ieee754_sqrtf (float b)
}
return f_washf (b);
}
@@ -64,9 +64,9 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
strong_alias (__ieee754_sqrtf, __sqrtf_finite)
Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
===
libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c 2012-07-03
22:36:01.176386435 -0700
-+++ libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c 2012-07-03
23:14:16.328497458 -0700
-@@ -40,7 +40,7 @@
+--- libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
+@@ -40,7 +40,7 @@ static const float half = 0.5;
simultaneously. */
double
@@ -75,7 +75,7 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
{
if (__builtin_expect (b 0, 1))
{
-@@ -77,7 +77,7 @@
+@@ -77,7 +77,7 @@ __ieee754_sqrt (double b)
/* Handle small numbers by scaling. */
if (__builtin_expect ((u.parts.msw 0x7ff0) = 0x0200,
0))
@@ -84,7 +84,7 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
#define FMADD(a_, c_, b_) \
({ double __r;\
-@@ -126,4 +126,12 @@
+@@ -126,4 +126,12 @@ __ieee754_sqrt (double b)
}
return f_wash (b);
}
@@ -99,9 +99,9 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
strong_alias (__ieee754_sqrt, __sqrt_finite)
Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c
===
libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c2012-07-03
22:36:01.176386435 -0700
-+++ libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c 2012-07-03
23:13:52.732496373 -0700
-@@ -38,7 +38,7 @@
+--- libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c
Re: [OE-core] [PATCH] binutils.inc: binutils will build differently if this feature is enabled, so add a dependency
On Tue, Sep 18, 2012 at 11:35 PM, Burton, Ross ross.bur...@intel.com wrote: this feature? Please use descriptive commit logs, so s/this feature/mulitarch/. I will update this and send a v2, after I wait a bit for more comments. -M Ross ___ 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] [bitbake-devel] [PATCH 1/4] gcc: Switch SRC_URI to use svn
On Fri, Sep 14, 2012 at 8:25 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Fri, Sep 14, 2012 at 10:23 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Fri, 2012-09-14 at 09:36 -0300, Otavio Salvador wrote: On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg b...@enea.com wrote: Khem Raj wrote: I agree but then 1.7 GB is noticeably huge too and it will only become larger in future so I don't think fetching from git will be a good solution for gcc ever. Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. I did not check if the fetcher has this support but it would be a nice solution. Shallow clones won't be able to support SRCREV properly, as you can only clone shallowly from HEAD, not from an arbitrary point in history, AFAIK. Right, shallow clones are a can of worms from a variety of angles. My current thinking is a ;allowsinglerev=1 parameter to the git fetcher which: a) Generates tarballs of single git revisions if tarball generation is turned on b) Searches for single revision tarballs before trying the main checkout approach. This would mean that WORKDIR may or may not have a .git directory for any SRC_URI marked with this. I think we should all be able to live with that and it shouldn't break too much? We'll end with multiple tarballs, aren't we? Yes. I'm not seeing that as a big problem for most of the usecases where we'd use this feature. You could skip shipping the big tarball of the whole repo at distribution time. By the way, there're any tool to clean the repo? (as we do for sstate-cache)? scripts/clean-workdir cleans tmp/ - not sure about downloads -M -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ bitbake-devel mailing list bitbake-de...@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core v2] valgrind: fix debug info reading error when do memcheck on ppc targets
On Wed, Sep 12, 2012 at 3:20 AM, b19...@freescale.com wrote:
From: Zhenhua Luo b19...@freescale.com
following is the error message:
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/ld-2.13.so:
--2263-- Can't make sense of .got section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /home/root/lzh:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/libc-2.13.so:
--2263-- Can't make sense of .data section mapping
Signed-off-by: Zhenhua Luo b19...@freescale.com
Scott,
I've added this to my denzil branch. Please pick it up for denzil-next
when you are working on it again.
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil
Thanks,
Matthew
---
...ind-3.7.0-fix-error-of-reading-debug-info.patch | 33
meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |5 ++-
2 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
diff --git
a/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
new file mode 100644
index 000..b1626f0
--- /dev/null
+++
b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
@@ -0,0 +1,33 @@
+Upstream-Status: Pending
+
+fix debug info reading error when do memcheck on ppc targets
+following is the error message:
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /lib/ld-2.13.so:
+--2263-- Can't make sense of .got section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /home/root/lzh:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /lib/libc-2.13.so:
+--2263-- Can't make sense of .data section mapping
+
+Signed-off-by: Zhenhua Luo b19...@freescale.com
+
+--- a/coregrind/m_debuginfo/readelf.c 2012-09-11 21:45:36.696462313 -0500
b/coregrind/m_debuginfo/readelf.c 2012-09-11 21:45:49.913463615 -0500
+@@ -1539,7 +1539,7 @@
+ phdr-p_offset di-fsm.rw_map_foff +
di-fsm.rw_map_size
+ phdr-p_offset + phdr-p_filesz
+= di-fsm.rw_map_foff + di-fsm.rw_map_size
+- (phdr-p_flags (PF_R | PF_W | PF_X)) == (PF_R | PF_W))
{
++ (phdr-p_flags (PF_R | PF_W | PF_X)) = (PF_R | PF_W))
{
+if (n_rw == N_RX_RW_AREAS) {
+ ML_(symerr)(di, True,
+ N_RX_RW_AREAS is too low;
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
index abda7a6..651ae60 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c46082167a314d785d012a244748d803 \
X11DEPENDS = virtual/libx11
DEPENDS = ${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '',
d)}
-PR = r5
+PR = r6
SRC_URI = http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://fix_issue_caused_by_ccache.patch \
@@ -21,6 +21,9 @@ SRC_URI =
http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://configure-with-glibc-2.16.patch \
+SRC_URI_append_powerpc =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
+SRC_URI_append_powerpc64 =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
+
Re: [OE-core] [PATCH] autotools.bbclass: Add functionality to force a clean of ${B} when reconfiguring (and ${S} != ${B})
On Wed, Sep 12, 2012 at 9:16 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2012-09-11 at 19:01 +, McClintock Matthew-B29882 wrote:
On Tue, Sep 11, 2012 at 9:22 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
Unfortunately whilst rerunning configure and make against a project will
mostly
work there are situations where it does not correctly do the right thing.
In particular, eglibc and gcc will fail out with errors where settings
do not match a previously built configuration. It could be argued they are
broken but the situation is what it is. There is the possibility of more
subtle
errors too.
This patch adds removal of the build directory (${B}) when configure is
rerunning, the sstate checksum for do_configure has changed and ${S} !=
${B}.
We could simply use a stamp but saving out the previous configuration
checksum
adds some data at no real overhead.
If we find there are things where we want to disable this behaviour with
CONFIGURESTAMPFILE = in the recipe, or users could disable it globally.
[YOCTO #2774]
[YOCTO #2848]
This is particularly helpful for eglibc and gcc which use split builds by
default and
are a particular source of reconfigure type problems.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
Is it feasible to back port this to denzil? I've encountered what I
think are similar issues reconfiguring gcc for example.
One of the bugs above is open against denzil and the issue certainly
exists there. The patch should apply equally well there.
I'd suggest we let this settle in master for a week or two and then add
it to the backport queue if no problems arise.
Cc'ing Scott so he's aware of this.
I've added this to my denzil branch and will start doing build testing.
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil
-M
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] [oe-core v2] valgrind: fix debug info reading error when do memcheck on ppc targets
On Wed, Sep 12, 2012 at 3:20 AM, b19...@freescale.com wrote:
From: Zhenhua Luo b19...@freescale.com
following is the error message:
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/ld-2.13.so:
--2263-- Can't make sense of .got section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /home/root/lzh:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/libc-2.13.so:
--2263-- Can't make sense of .data section mapping
Signed-off-by: Zhenhua Luo b19...@freescale.com
---
...ind-3.7.0-fix-error-of-reading-debug-info.patch | 33
meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |5 ++-
2 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
diff --git
a/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
new file mode 100644
index 000..b1626f0
--- /dev/null
+++
b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
@@ -0,0 +1,33 @@
+Upstream-Status: Pending
+
+fix debug info reading error when do memcheck on ppc targets
+following is the error message:
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /lib/ld-2.13.so:
+--2263-- Can't make sense of .got section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /home/root/lzh:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /lib/libc-2.13.so:
+--2263-- Can't make sense of .data section mapping
+
+Signed-off-by: Zhenhua Luo b19...@freescale.com
+
+--- a/coregrind/m_debuginfo/readelf.c 2012-09-11 21:45:36.696462313 -0500
b/coregrind/m_debuginfo/readelf.c 2012-09-11 21:45:49.913463615 -0500
+@@ -1539,7 +1539,7 @@
+ phdr-p_offset di-fsm.rw_map_foff +
di-fsm.rw_map_size
+ phdr-p_offset + phdr-p_filesz
+= di-fsm.rw_map_foff + di-fsm.rw_map_size
+- (phdr-p_flags (PF_R | PF_W | PF_X)) == (PF_R | PF_W))
{
++ (phdr-p_flags (PF_R | PF_W | PF_X)) = (PF_R | PF_W))
{
+if (n_rw == N_RX_RW_AREAS) {
+ ML_(symerr)(di, True,
+ N_RX_RW_AREAS is too low;
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
index abda7a6..651ae60 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c46082167a314d785d012a244748d803 \
X11DEPENDS = virtual/libx11
DEPENDS = ${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '',
d)}
-PR = r5
+PR = r6
SRC_URI = http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://fix_issue_caused_by_ccache.patch \
@@ -21,6 +21,9 @@ SRC_URI =
http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://configure-with-glibc-2.16.patch \
+SRC_URI_append_powerpc =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
+SRC_URI_append_powerpc64 =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
Did you not build test this? There is a type here. Sent a fix already.
-M
+
SRC_URI[md5sum] = a855fda56edf05614f099dca316d1775
SRC_URI[sha256sum] =
Re: [OE-core] [PATCH 11/32] sysvinit-inittab_2.88dsf.bb: Allow multiple serial port consoles to be defined
On Tue, Sep 11, 2012 at 6:49 AM, Phil Blundell ph...@gnu.org wrote:
On Mon, 2012-08-13 at 14:14 -0700, Scott Garman wrote:
+pkg_postinst_${PN} () {
+# run this on the target
+if [ x$D == x ]; then
By the way, == is a bashism; that should just be = for portability.
Or you can use '-z $D' which is also portable.
Ok - will send a v3 shortly.
-M
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
Re: [OE-core] [CONSOLIDATED REQUEST 00/13] Misc Fixes (cover only)
On Tue, Sep 11, 2012 at 11:19 AM, Saul Wold s...@linux.intel.com wrote:
On 09/11/2012 09:14 AM, Saul Wold wrote:
The following changes since commit
48169c6bc44c546cecaa06207b6c36da558b81f7:
classes/packageinfo: use better method to check if package exists
(2012-09-10 21:52:37 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/stage
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
Bruce Ashfield (1):
linux-yocto/3.4: v3.4.10 and uprobes/kprobes configuration updates
Khem Raj (2):
gcc-4.7: Fix build for armv4/EABI and ppc/Os
gcc-4.7: Backport libgcc fixes to appease the new build sequence
Mark Asselstine (1):
base-files: provide a mechanism to skip creation of the hostname file
Mark Hatle (3):
image.bbclass: Enable the complementary install to be called w/
globbing params
package_rpm.bbclass: Avoid unnecessary installs in complementary pass
qt4: Update qt4.inc to remove staticdev deps in -dbg packages
Matthew McClintock (1):
sysvinit-inittab_2.88dsf.bb: only run serial checks at boot if we
have items to check
Scratch this one, I missed the v2 posted while I was heads down prepping
this!
v3 now!
-M
Sau!
Phil Blundell (3):
perl-native: PROVIDE libmodule-build-perl-native for consistency with
non-native perl
shadow: Fix various invalid assumptions about directory layout
shadow-native: Ensure that ${sbindir} and ${base_sbindir} are
respected
Ross Burton (2):
webkit-gtk: work around Make bug by re-running make
telepathy-idle: fix parallel build
meta/classes/image.bbclass |4 +-
meta/classes/package_rpm.bbclass |9 ++-
.../build-fix-for-make-j-safety.patch | 39
.../fix-svc-gtk-doc.h-target.patch | 24 +-
.../telepathy/telepathy-idle_0.1.12.bb |5 +-
meta/recipes-core/base-files/base-files_3.0.14.bb | 14 ++--
.../sysvinit/sysvinit-inittab_2.88dsf.bb |6 +-
meta/recipes-devtools/gcc/gcc-4.7.inc |6 +-
...-vis_hide-gen-hide-list-Do-not-make-defin.patch | 93
...USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch | 49 ++
.../gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch| 31 +++
.../gcc/gcc-4.7/ppc_no_crtsavres.patch | 72
+++
meta/recipes-devtools/perl/perl-native_5.14.2.bb |3 +
.../shadow/shadow-native_4.1.4.3.bb| 11 ++-
meta/recipes-extended/shadow/shadow_4.1.4.3.bb | 17 +++-
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb|8 +-
meta/recipes-kernel/linux/linux-yocto_3.4.bb | 16 ++--
meta/recipes-qt/qt4/qt4-embedded.inc |2 +-
meta/recipes-qt/qt4/qt4-x11-free.inc |2 +-
meta/recipes-qt/qt4/qt4.inc|2 +-
meta/recipes-sato/webkit/webkit-gtk_1.8.2.bb | 22 +
21 files changed, 380 insertions(+), 55 deletions(-)
create mode 100644
meta/recipes-connectivity/telepathy/telepathy-idle-0.1.12/build-fix-for-make-j-safety.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/0001-Makefile.in-vis_hide-gen-hide-list-Do-not-make-defin.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/0001-crtstuff.c-USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch
___
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] autotools.bbclass: Add functionality to force a clean of ${B} when reconfiguring (and ${S} != ${B})
On Tue, Sep 11, 2012 at 9:22 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
Unfortunately whilst rerunning configure and make against a project will
mostly
work there are situations where it does not correctly do the right thing.
In particular, eglibc and gcc will fail out with errors where settings
do not match a previously built configuration. It could be argued they are
broken but the situation is what it is. There is the possibility of more
subtle
errors too.
This patch adds removal of the build directory (${B}) when configure is
rerunning, the sstate checksum for do_configure has changed and ${S} != ${B}.
We could simply use a stamp but saving out the previous configuration checksum
adds some data at no real overhead.
If we find there are things where we want to disable this behaviour with
CONFIGURESTAMPFILE = in the recipe, or users could disable it globally.
[YOCTO #2774]
[YOCTO #2848]
This is particularly helpful for eglibc and gcc which use split builds by
default and
are a particular source of reconfigure type problems.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
Is it feasible to back port this to denzil? I've encountered what I
think are similar issues reconfiguring gcc for example.
-M
---
diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index 4c4bf87..a5997c5 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -89,6 +89,27 @@ oe_runconf () {
AUTOTOOLS_AUXDIR ?= ${S}
+CONFIGURESTAMPFILE = ${WORKDIR}/configure.sstate
+
+autotools_preconfigure() {
+ if [ -n ${CONFIGURESTAMPFILE} -a -e ${CONFIGURESTAMPFILE} ]; then
+ if [ `cat ${CONFIGURESTAMPFILE}` != ${BB_TASKHASH} -a
${S} != ${B} ]; then
+ echo Previously configured separate build directory
detected, cleaning ${B}
+ rm -rf ${B}
+ mkdir ${B}
+ fi
+ fi
+}
+
+autotools_postconfigure(){
+ if [ -n ${CONFIGURESTAMPFILE} ]; then
+ echo ${BB_TASKHASH} ${CONFIGURESTAMPFILE}
+ fi
+}
+
+do_configure[prefuncs] += autotools_preconfigure
+do_configure[postfuncs] += autotools_postconfigure
+
autotools_do_configure() {
case ${PN} in
autoconf*)
___
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] [oe-core] valgrind: fix debug info reading error when do memcheck on ppc targets
On Tue, Sep 11, 2012 at 10:44 PM, b19...@freescale.com wrote:
From: Zhenhua Luo b19...@freescale.com
following is the error message:
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/ld-2.13.so:
--2263-- Can't make sense of .got section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /home/root/lzh:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/libc-2.13.so:
--2263-- Can't make sense of .data section mapping
Signed-off-by: Zhenhua Luo b19...@freescale.com
---
...ind-3.7.0-fix-error-of-reading-debug-info.patch | 11 +++
meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |5 -
2 files changed, 15 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
diff --git
a/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
Patch needs Upstream-Status:
-M
new file mode 100644
index 000..c3ebd67
--- /dev/null
+++
b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
@@ -0,0 +1,11 @@
+--- a/coregrind/m_debuginfo/readelf.c 2012-09-11 21:45:36.696462313 -0500
b/coregrind/m_debuginfo/readelf.c 2012-09-11 21:45:49.913463615 -0500
+@@ -1539,7 +1539,7 @@
+ phdr-p_offset di-fsm.rw_map_foff +
di-fsm.rw_map_size
+ phdr-p_offset + phdr-p_filesz
+= di-fsm.rw_map_foff + di-fsm.rw_map_size
+- (phdr-p_flags (PF_R | PF_W | PF_X)) == (PF_R | PF_W))
{
++ (phdr-p_flags (PF_R | PF_W | PF_X)) = (PF_R | PF_W))
{
+if (n_rw == N_RX_RW_AREAS) {
+ ML_(symerr)(di, True,
+ N_RX_RW_AREAS is too low;
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
index abda7a6..651ae60 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c46082167a314d785d012a244748d803 \
X11DEPENDS = virtual/libx11
DEPENDS = ${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '',
d)}
-PR = r5
+PR = r6
SRC_URI = http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://fix_issue_caused_by_ccache.patch \
@@ -21,6 +21,9 @@ SRC_URI =
http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://configure-with-glibc-2.16.patch \
+SRC_URI_append_powerpc =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
+SRC_URI_append_powerpc64 =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
Is it safe to apply this to everything? I can't image an elf issue
would be powerpc specific.
-M
+
SRC_URI[md5sum] = a855fda56edf05614f099dca316d1775
SRC_URI[sha256sum] =
5d62c0330f1481fe2c593249192fa68ff454c19c34343978cc9ce91aa324cbf6
--
1.7.9.5
___
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 11/32] sysvinit-inittab_2.88dsf.bb: Allow multiple serial port consoles to be defined
On Sat, Sep 8, 2012 at 4:21 PM, Phil Blundell ph...@gnu.org wrote:
On Mon, 2012-08-13 at 14:14 -0700, Scott Garman wrote:
+pkg_postinst_${PN} () {
+# run this on the target
+if [ x$D == x ]; then
+ tmp=${SERIAL_CONSOLES_CHECK}
+ for i in $tmp
+ do
+ j=`echo ${i} | sed s/^.*\;//g`
+ if [ -z `cat /proc/consoles | grep ${j}` ]; then
+ sed -i /^.*${j}$/d /etc/inittab
+ fi
+ done
+ kill -HUP 1
+else
+ exit 1
+fi
+}
This makes the package uninstallable, even if SERIAL_CONSOLES_CHECK is
empty, on a READ_ONLY_ROOTFS.
What do you mean uninstallable? I could see this generating an error
message at each boot, but not sure what you mean about uninstallable.
-M
___
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] conf/tune: add tune-ppce300c3
On Thu, Sep 6, 2012 at 6:07 PM, Mark Hatle mark.ha...@windriver.com wrote:
On 9/6/12 5:59 PM, Richard Purdie wrote:
On Thu, 2012-09-06 at 17:35 -0500, Mark Hatle wrote:
On 9/6/12 5:20 PM, Bruce Ashfield wrote:
On 12-09-06 6:19 PM, Richard Purdie wrote:
On Thu, 2012-09-06 at 14:43 -0400, Bruce Ashfield wrote:
It has been pointed out several times that the yocto mpc8315e-rdb
reference was using the wrong tuning (603e), since it is actually
a e300c3 board.
This commit creates a e300c3 tune file based on the e300c2 variant
already in oe-core.
This commit also inhibits altivec in flac when this new tuning is
enabled. It was also noticed that the existing tune based overrides
in the flac package would not be triggered since DEFAULTTUNE is not
in the overrides list. To avoid doing per-board disabling of altivec
DEFAULTTUNE is added to the local package OVERRIDES and then used
to disable altivec.
[YOCTO #1192]
Signed-off-by: Bruce Ashfieldbruce.ashfi...@windriver.com
asdfkljds
Signed-off-by: Bruce Ashfieldbruce.ashfi...@windriver.com
---
meta/conf/machine/include/tune-ppce300c3.inc | 11 +++
meta/recipes-multimedia/flac/flac_1.2.1.bb |5 +
2 files changed, 16 insertions(+), 0 deletions(-)
create mode 100644 meta/conf/machine/include/tune-ppce300c3.inc
diff --git a/meta/conf/machine/include/tune-ppce300c3.inc
b/meta/conf/machine/include/tune-ppce300c3.inc
new file mode 100644
index 000..3f5ac26
--- /dev/null
+++ b/meta/conf/machine/include/tune-ppce300c3.inc
@@ -0,0 +1,11 @@
+DEFAULTTUNE ?= ppce300c3
+
+require conf/machine/include/powerpc/arch-powerpc.inc
+
+TUNEVALID[ppce300c3] = Enable ppce300c3 specific processor
optimizations
+TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, ppce300c3,
-mcpu=e300c3, , d)}
+
+AVAILTUNES += ppce300c3
+TUNE_FEATURES_tune-ppce300c3 = m32 fpu-soft ppce300c3
+TUNE_PKGARCH_tune-ppce300c3 = ppce300c3
+PACKAGE_EXTRA_ARCHS_tune-ppce300c3 =
${PACKAGE_EXTRA_ARCHS_tune-powerpc-nf} ppce300c3
diff --git a/meta/recipes-multimedia/flac/flac_1.2.1.bb
b/meta/recipes-multimedia/flac/flac_1.2.1.bb
index 3c5b73c..25db1c4 100644
--- a/meta/recipes-multimedia/flac/flac_1.2.1.bb
+++ b/meta/recipes-multimedia/flac/flac_1.2.1.bb
@@ -36,9 +36,14 @@ EXTRA_OECONF = --disable-oggtest
--disable-id3libtest \
--without-xmms-exec-prefix \
--without-libiconv-prefix \
--without-id3lib
+
+FLACOVERRIDE = :${DEFAULTTUNE}
+OVERRIDES .= ${FLACOVERRIDE}
+
EXTRA_OECONF_prepend_e500mc = --disable-altivec
EXTRA_OECONF_prepend_e5500 = --disable-altivec
EXTRA_OECONF_prepend_e5500-64b = --disable-altivec
+EXTRA_OECONF_prepend_ppce300c3 = --disable-altivec
This is getting ugly and is kind of unsafe. Perhaps the architecture
should be doing something like:
MACHINEOVERRIDES .= ${@bb.utils.contains(TUNE_FEATURES, ppce300c3,
:noaltivec, ,d)}
or even in this recipe just do:
EXTRA_OECONF += ${@bb.utils.contains(TUNE_FEATURES, ppce300c3,
--disable-altivec, ,d)}
These don't work because you still have the other 3 lines that look
just like this. Or am I missing something?
I definitely considered this route. I can do that for the new arch, and
the
old ones, but can't test the old ones at the moment.
The problem is actually in the flac. This recipe sees powerpc as the
machine
type, and immediately enabled altivec. By default altivec support is
disabled
in OE-Core.
Perhaps one way we could address this is add a tune flag that says if the
tune
has altivec support or not.. then in the flac binary, disable it unless
it's
enabled?
I think having altivec in the tune_features would be ideal. I'd love to
get this cleaned up too but I lack much knowledge about powerpc...
My proposal then would be to accept Bruce's patch, with the understanding
that we need to add a tune flag of 'altivec' to the PowerPC tunings (where
appropriate) and then make the flac recipe respect that flag.
This sounds good to me. If a bug is filed against me I can take a look
at it since I did the initial damage.
-M
Unfortunately I don't have the time to do that right now or I would. Would
an enhancement bug in the Yocto Project bugzilla be enough to be sure the
work is done?
--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] [for-denzil][meta-oe][PATCH 09/11] kernel: Add kernel headers to kernel-dev package
On Tue, Aug 28, 2012 at 1:41 AM, Koen Kooi k...@dominion.thruhere.net wrote:
From: Darren Hart dvh...@linux.intel.com
[YOCTO #1614]
Add the kernel headers to the kernel-dev package. This packages what was
already built and kept in sysroots for building modules with bitbake.
Making this available on the target requires removing some additional
host binaries.
Move the location to /usr/src/kernel
Before use on the target, the user will need to:
# cd /usr/src/kernel
# make scripts
This renders the kernel-misc recipe empty, so remove it.
As we use /usr/src/kernel in several places (and I missed one in the
previous version), add a KERNEL_SRC_DIR variable and use that throughout
the class to avoid update errors in the future.
Now that we package the kernel headers, drop the
kernel_package_preprocess function which removed them from PKGD.
All *-sdk image recipes include dev-pkgs, so the kernel-dev package will
be installed by default on all such images.
Signed-off-by: Darren Hart dvh...@linux.intel.com
CC: Bruce Ashfield bruce.ashfi...@windriver.com
CC: Tom Zanussi tom.zanu...@intel.com
CC: Khem Raj raj.k...@gmail.com
---
meta/classes/kernel.bbclass | 25 +++--
meta/conf/bitbake.conf |2 +-
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 3ccd753..d79ba9f 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -77,6 +77,10 @@ EXTRA_OEMAKE =
KERNEL_ALT_IMAGETYPE ??=
+# Define where the kernel headers are installed on the target as well as
where
+# they are staged.
+KERNEL_SRC_PATH = /usr/src/kernel
+
KERNEL_IMAGETYPE_FOR_MAKE = ${@(lambda s: s[:-3] if s[-3:] == .gz else
s)(d.getVar('KERNEL_IMAGETYPE', True))}
kernel_do_compile() {
@@ -130,7 +134,7 @@ kernel_do_install() {
# Support for external module building - create a minimal copy of the
# kernel source tree.
#
- kerneldir=${D}/kernel
+ kerneldir=${D}${KERNEL_SRC_PATH}
install -d $kerneldir
#
@@ -191,20 +195,15 @@ kernel_do_install() {
# Remove the following binaries which cause strip errors
# during do_package for cross-compiled platforms
bin_files=arch/powerpc/boot/addnote arch/powerpc/boot/hack-coff \
- arch/powerpc/boot/mktree
+ arch/powerpc/boot/mktree scripts/kconfig/zconf.tab.o \
+ scripts/kconfig/conf.o
for entry in $bin_files; do
rm -f $kerneldir/$entry
done
}
-PACKAGE_PREPROCESS_FUNCS += kernel_package_preprocess
-
-kernel_package_preprocess () {
- rm -rf ${PKGD}/kernel
-}
-
sysroot_stage_all_append() {
- sysroot_stage_dir ${D}/kernel ${SYSROOT_DESTDIR}/kernel
+ sysroot_stage_dir ${D}${KERNEL_SRC_PATH}
${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
}
kernel_do_configure() {
@@ -252,13 +251,11 @@ EXPORT_FUNCTIONS do_compile do_install do_configure
# kernel-base becomes kernel-${KERNEL_VERSION}
# kernel-image becomes kernel-image-${KERNEL_VERISON}
-PACKAGES = kernel kernel-base kernel-image kernel-dev kernel-vmlinux
kernel-misc
+PACKAGES = kernel kernel-base kernel-vmlinux kernel-image kernel-dev
FILES =
FILES_kernel-image = /boot/${KERNEL_IMAGETYPE}*
-FILES_kernel-dev = /boot/System.map* /boot/Module.symvers* /boot/config*
+FILES_kernel-dev = /boot/System.map* /boot/Module.symvers* /boot/config*
${KERNEL_SRC_PATH}
This patch is causing the following on denzil (which Scott applied to
his denzil-next branch)
ERROR: QA Issue: non debug package contains .debug directory:
kernel-dev path
/work/p5020ds_64b-poky-linux/linux-qoriq-sdk-3.0.34-r4/packages-split/kernel-dev/usr/src/kernel/tools/perf/.debug/perf
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa
ERROR: Logfile of failure stored in:
/local/home/mattsm/git/poky/build-denzil/tmp/work/p5020ds_64b-poky-linux/linux-qoriq-sdk-3.0.34-r4/temp/log.do_package.26851
NOTE: package linux-qoriq-sdk-3.0.34-r4: task do_package: Failed
ERROR: Task 13
(/local/home/mattsm/git/poky/build-denzil/../meta-fsl-ppc/recipes-kernel/linux/linux-qoriq-sdk.bb,
do_package) failed with exit code '1'
At first glance, it looks like we should:
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 7ae2a53..511b22b 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -546,4 +546,5 @@ EXPORT_FUNCTIONS do_deploy
PACKAGES =+ perf-dbg perf
FILES_perf = ${bindir}/* \
${libexecdir}
-FILES_perf-dbg = ${FILES_${PN}-dbg}
+FILES_perf-dbg = ${FILES_${PN}-dbg} \
+ ${KERNEL_SRC_PATH}/tools/perf/.debug
Thoughts?
-M
FILES_kernel-vmlinux = /boot/vmlinux*
-# misc is a package to contain files we need in staging
-FILES_kernel-misc = /kernel/include/config /kernel/scripts
Re: [OE-core] [for-denzil][meta-oe][PATCH 09/11] kernel: Add kernel headers to kernel-dev package
On Wed, Sep 5, 2012 at 7:49 PM, Darren Hart dvh...@linux.intel.com wrote:
On 09/05/2012 02:42 PM, McClintock Matthew-B29882 wrote:
On Tue, Aug 28, 2012 at 1:41 AM, Koen Kooi k...@dominion.thruhere.net
wrote:
From: Darren Hart dvh...@linux.intel.com
[YOCTO #1614]
Add the kernel headers to the kernel-dev package. This packages what was
already built and kept in sysroots for building modules with bitbake.
Making this available on the target requires removing some additional
host binaries.
Move the location to /usr/src/kernel
Before use on the target, the user will need to:
# cd /usr/src/kernel
# make scripts
This renders the kernel-misc recipe empty, so remove it.
As we use /usr/src/kernel in several places (and I missed one in the
previous version), add a KERNEL_SRC_DIR variable and use that throughout
the class to avoid update errors in the future.
Now that we package the kernel headers, drop the
kernel_package_preprocess function which removed them from PKGD.
All *-sdk image recipes include dev-pkgs, so the kernel-dev package will
be installed by default on all such images.
Signed-off-by: Darren Hart dvh...@linux.intel.com
CC: Bruce Ashfield bruce.ashfi...@windriver.com
CC: Tom Zanussi tom.zanu...@intel.com
CC: Khem Raj raj.k...@gmail.com
---
meta/classes/kernel.bbclass | 25 +++--
meta/conf/bitbake.conf |2 +-
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 3ccd753..d79ba9f 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -77,6 +77,10 @@ EXTRA_OEMAKE =
KERNEL_ALT_IMAGETYPE ??=
+# Define where the kernel headers are installed on the target as well as
where
+# they are staged.
+KERNEL_SRC_PATH = /usr/src/kernel
+
KERNEL_IMAGETYPE_FOR_MAKE = ${@(lambda s: s[:-3] if s[-3:] == .gz else
s)(d.getVar('KERNEL_IMAGETYPE', True))}
kernel_do_compile() {
@@ -130,7 +134,7 @@ kernel_do_install() {
# Support for external module building - create a minimal copy of
the
# kernel source tree.
#
- kerneldir=${D}/kernel
+ kerneldir=${D}${KERNEL_SRC_PATH}
install -d $kerneldir
#
@@ -191,20 +195,15 @@ kernel_do_install() {
# Remove the following binaries which cause strip errors
# during do_package for cross-compiled platforms
bin_files=arch/powerpc/boot/addnote arch/powerpc/boot/hack-coff \
- arch/powerpc/boot/mktree
+ arch/powerpc/boot/mktree scripts/kconfig/zconf.tab.o \
+ scripts/kconfig/conf.o
for entry in $bin_files; do
rm -f $kerneldir/$entry
done
}
-PACKAGE_PREPROCESS_FUNCS += kernel_package_preprocess
-
-kernel_package_preprocess () {
- rm -rf ${PKGD}/kernel
-}
-
sysroot_stage_all_append() {
- sysroot_stage_dir ${D}/kernel ${SYSROOT_DESTDIR}/kernel
+ sysroot_stage_dir ${D}${KERNEL_SRC_PATH}
${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
}
kernel_do_configure() {
@@ -252,13 +251,11 @@ EXPORT_FUNCTIONS do_compile do_install do_configure
# kernel-base becomes kernel-${KERNEL_VERSION}
# kernel-image becomes kernel-image-${KERNEL_VERISON}
-PACKAGES = kernel kernel-base kernel-image kernel-dev kernel-vmlinux
kernel-misc
+PACKAGES = kernel kernel-base kernel-vmlinux kernel-image kernel-dev
FILES =
FILES_kernel-image = /boot/${KERNEL_IMAGETYPE}*
-FILES_kernel-dev = /boot/System.map* /boot/Module.symvers* /boot/config*
+FILES_kernel-dev = /boot/System.map* /boot/Module.symvers* /boot/config*
${KERNEL_SRC_PATH}
This patch is causing the following on denzil (which Scott applied to
his denzil-next branch)
ERROR: QA Issue: non debug package contains .debug directory:
kernel-dev path
/work/p5020ds_64b-poky-linux/linux-qoriq-sdk-3.0.34-r4/packages-split/kernel-dev/usr/src/kernel/tools/perf/.debug/perf
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa
ERROR: Logfile of failure stored in:
/local/home/mattsm/git/poky/build-denzil/tmp/work/p5020ds_64b-poky-linux/linux-qoriq-sdk-3.0.34-r4/temp/log.do_package.26851
NOTE: package linux-qoriq-sdk-3.0.34-r4: task do_package: Failed
ERROR: Task 13
(/local/home/mattsm/git/poky/build-denzil/../meta-fsl-ppc/recipes-kernel/linux/linux-qoriq-sdk.bb,
do_package) failed with exit code '1'
At first glance, it looks like we should:
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 7ae2a53..511b22b 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -546,4 +546,5 @@ EXPORT_FUNCTIONS do_deploy
PACKAGES =+ perf-dbg perf
FILES_perf = ${bindir}/* \
${libexecdir}
-FILES_perf-dbg = ${FILES_${PN}-dbg}
+FILES_perf-dbg = ${FILES_${PN}-dbg} \
+ ${KERNEL_SRC_PATH}/tools/perf/.debug
Thoughts?
I suppose
Re: [OE-core] [PATCH 0/8] Patches for LSB perl test
On Wed, Sep 5, 2012 at 10:01 PM, Kang Kai kai.k...@windriver.com wrote: On 2012年09月06日 10:47, McClintock Matthew-B29882 wrote: On Tue, Sep 4, 2012 at 10:01 AM, Saul Wolds...@linux.intel.com wrote: On 08/31/2012 03:00 AM, Kang Kai wrote: The following changes since commit b4c5725af4cd85d5644f0373e2674e903c4eab2b: yocto-bsp: add missing xserver-xf86-config .bbappend for qemu (2012-08-25 14:47:07 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib kangkai/lsb http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/lsb Kang Kai (8): libclass-isa-perl: add it perl: package modules Pod-Html and Tie-Hash-NamedCapture libpod-plainer-perl: add it libdumpvalue-perl: add it libenv-perl: add it libfile-checktree-perl: add it libi18n-collate-perl: add it task-core-lsb: add packages meta/recipes-devtools/perl/perl-5.14.2/config.sh |2 +- .../perl/libclass-isa-perl_0.36.bb | 32 +++ .../perl/libdumpvalue-perl_1.16.bb | 20 meta/recipes-extended/perl/libenv-perl_1.03.bb | 22 + .../perl/libfile-checktree-perl_4.41.bb| 33 .../perl/libi18n-collate-perl_1.02.bb | 22 + .../perl/libpod-plainer-perl_1.03.bb | 24 ++ meta/recipes-extended/tasks/task-core-lsb.bb |9 +- 8 files changed, 162 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-extended/perl/libclass-isa-perl_0.36.bb create mode 100644 meta/recipes-extended/perl/libdumpvalue-perl_1.16.bb create mode 100644 meta/recipes-extended/perl/libenv-perl_1.03.bb create mode 100644 meta/recipes-extended/perl/libfile-checktree-perl_4.41.bb create mode 100644 meta/recipes-extended/perl/libi18n-collate-perl_1.02.bb create mode 100644 meta/recipes-extended/perl/libpod-plainer-perl_1.03.bb Kang, Given that LSB 5.0 is coming out that removes many of these requirements, does it really make sense to add these and then remove them again in a future release. I understand we are trying to be as compliant as possible to LSB, but this may best be in a meta-lsb layer. Is a meta-lsb layer coming? Will it be apart of poky? I send a patch to create meta-lsb layer in poky, and I think that is what Saul wants. That's fine it just was not clear to me if that was going to live on as a separate layer or be in poky by default. It would be nice if this followed the same route as meta-yocto has. -M Regards, Kai -M 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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] distutils/steuptools: Fix files layout and unbreak builds
On Fri, Aug 24, 2012 at 5:01 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Fri, 2012-08-24 at 20:48 +, McClintock Matthew-B29882 wrote:
On Fri, Aug 24, 2012 at 11:15 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
The last two distutils changes progressively broke the builds. Firstly they
moved things from the site_packages directory to being higher up the tree
which introduced package QA warnings as a side effect. Secondly, it
interacts
badly with setuptools which passes in --root=${D} itself.
This patch restores the original directory layout, hence fixing the QA
warnings and also passes extra options to setuptools to deal with the
--root option it passes.
Hmm, I think you don't need certain bits anymore
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/distutils.bbclass
b/meta/classes/distutils.bbclass
index 52a1aa8..c73b24f 100644
--- a/meta/classes/distutils.bbclass
+++ b/meta/classes/distutils.bbclass
@@ -38,7 +38,7 @@ distutils_do_install() {
STAGING_LIBDIR=${STAGING_LIBDIR} \
PYTHONPATH=${D}/${PYTHON_SITEPACKAGES_DIR} \
BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} \
-${STAGING_BINDIR_NATIVE}/python-native/python setup.py install
--install-lib=${D}${libdir}/${PYTHON_DIR} ${DISTUTILS_INSTALL_ARGS} || \
+${STAGING_BINDIR_NATIVE}/python-native/python setup.py install
--install-lib=${D}/${PYTHON_SITEPACKAGES_DIR} ${DISTUTILS_INSTALL_ARGS} ||
\
This change should be handled by the bit below? So you could
s/--install-lib=${D}/${PYTHON_SITEPACKAGES_DIR}//
?
Not everything uses setuptools, there are things using just disutils.
I'm open to further cleanup of this but we need to consider both
cases...
Ah right, I incorrectly assumed both of these always applied.
Thanks for looking at this.
-M
Cheers,
Richard
bbfatal python setup.py install execution failed.
for i in `find ${D} -name *.py` ; do \
diff --git a/meta/classes/setuptools.bbclass
b/meta/classes/setuptools.bbclass
index ced9509..ba9cf13 100644
--- a/meta/classes/setuptools.bbclass
+++ b/meta/classes/setuptools.bbclass
@@ -5,4 +5,5 @@ DEPENDS += python-setuptools-native
DISTUTILS_INSTALL_ARGS = --root=${D} \
--single-version-externally-managed \
--prefix=${prefix} \
+--install-lib=${PYTHON_SITEPACKAGES_DIR} \
--install-data=${datadir}
___
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] distutils-common-base.bbclass: Pick up additional .debug folders:
On Fri, Aug 24, 2012 at 1:25 AM, Martin Jansa martin.ja...@gmail.com wrote:
On Thu, Aug 23, 2012 at 11:13:08PM +0100, Burton, Ross wrote:
On 23 August 2012 19:46, Matthew McClintock m...@freescale.com wrote:
${PYTHON_SITEPACKAGES_DIR}/.debug \
${PYTHON_SITEPACKAGES_DIR}/*/.debug \
${PYTHON_SITEPACKAGES_DIR}/*/*/.debug \
+ ${libdir}/${PYTHON_DIR}/.debug \
+ ${libdir}/${PYTHON_DIR}/*/.debug \
+ ${libdir}/${PYTHON_DIR}/*/*/.debug \
I thought packages that used distutils generally put their files under
sitepackages, and not the python base directory... Are some packages
doing it wrong?
Yes, almost all python-* recipes after this patch
http://git.openembedded.org/openembedded-core/commit/?id=3b23feca31480cc56f55301fd0274e622c40b522
I have 9 such recipes in my dep tree.
Martin,
Can you look at:
http://patches.openembedded.org/patch/35245/
-M
Cheers,
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
___
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] distutils/steuptools: Fix files layout and unbreak builds
On Fri, Aug 24, 2012 at 11:15 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
The last two distutils changes progressively broke the builds. Firstly they
moved things from the site_packages directory to being higher up the tree
which introduced package QA warnings as a side effect. Secondly, it interacts
badly with setuptools which passes in --root=${D} itself.
This patch restores the original directory layout, hence fixing the QA
warnings and also passes extra options to setuptools to deal with the
--root option it passes.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass
index 52a1aa8..c73b24f 100644
--- a/meta/classes/distutils.bbclass
+++ b/meta/classes/distutils.bbclass
@@ -38,7 +38,7 @@ distutils_do_install() {
STAGING_LIBDIR=${STAGING_LIBDIR} \
PYTHONPATH=${D}/${PYTHON_SITEPACKAGES_DIR} \
BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} \
-${STAGING_BINDIR_NATIVE}/python-native/python setup.py install
--install-lib=${D}${libdir}/${PYTHON_DIR} ${DISTUTILS_INSTALL_ARGS} || \
+${STAGING_BINDIR_NATIVE}/python-native/python setup.py install
--install-lib=${D}/${PYTHON_SITEPACKAGES_DIR} ${DISTUTILS_INSTALL_ARGS} || \
bbfatal python setup.py install execution failed.
for i in `find ${D} -name *.py` ; do \
diff --git a/meta/classes/setuptools.bbclass b/meta/classes/setuptools.bbclass
index ced9509..ba9cf13 100644
--- a/meta/classes/setuptools.bbclass
+++ b/meta/classes/setuptools.bbclass
@@ -5,4 +5,5 @@ DEPENDS += python-setuptools-native
DISTUTILS_INSTALL_ARGS = --root=${D} \
--single-version-externally-managed \
--prefix=${prefix} \
+--install-lib=${PYTHON_SITEPACKAGES_DIR} \
--install-data=${datadir}
Looks good... stuff is packaged properly for the libdir = /usr/lib64
Thanks,
M
___
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] distutils/steuptools: Fix files layout and unbreak builds
On Fri, Aug 24, 2012 at 11:15 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
The last two distutils changes progressively broke the builds. Firstly they
moved things from the site_packages directory to being higher up the tree
which introduced package QA warnings as a side effect. Secondly, it interacts
badly with setuptools which passes in --root=${D} itself.
This patch restores the original directory layout, hence fixing the QA
warnings and also passes extra options to setuptools to deal with the
--root option it passes.
Hmm, I think you don't need certain bits anymore
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass
index 52a1aa8..c73b24f 100644
--- a/meta/classes/distutils.bbclass
+++ b/meta/classes/distutils.bbclass
@@ -38,7 +38,7 @@ distutils_do_install() {
STAGING_LIBDIR=${STAGING_LIBDIR} \
PYTHONPATH=${D}/${PYTHON_SITEPACKAGES_DIR} \
BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} \
-${STAGING_BINDIR_NATIVE}/python-native/python setup.py install
--install-lib=${D}${libdir}/${PYTHON_DIR} ${DISTUTILS_INSTALL_ARGS} || \
+${STAGING_BINDIR_NATIVE}/python-native/python setup.py install
--install-lib=${D}/${PYTHON_SITEPACKAGES_DIR} ${DISTUTILS_INSTALL_ARGS} || \
This change should be handled by the bit below? So you could
s/--install-lib=${D}/${PYTHON_SITEPACKAGES_DIR}//
?
bbfatal python setup.py install execution failed.
for i in `find ${D} -name *.py` ; do \
diff --git a/meta/classes/setuptools.bbclass b/meta/classes/setuptools.bbclass
index ced9509..ba9cf13 100644
--- a/meta/classes/setuptools.bbclass
+++ b/meta/classes/setuptools.bbclass
@@ -5,4 +5,5 @@ DEPENDS += python-setuptools-native
DISTUTILS_INSTALL_ARGS = --root=${D} \
--single-version-externally-managed \
--prefix=${prefix} \
+--install-lib=${PYTHON_SITEPACKAGES_DIR} \
--install-data=${datadir}
___
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] distutils/steuptools: Fix files layout and unbreak builds
On Fri, Aug 24, 2012 at 3:51 PM, Andrei Gherzan and...@gherzan.ro wrote: Exactly my fix. Please merge. It's already been merged. -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] distutils-common-base.bbclass: Pick up additional .debug folders:
On Thu, Aug 23, 2012 at 5:13 PM, Burton, Ross ross.bur...@intel.com wrote:
On 23 August 2012 19:46, Matthew McClintock m...@freescale.com wrote:
${PYTHON_SITEPACKAGES_DIR}/.debug \
${PYTHON_SITEPACKAGES_DIR}/*/.debug \
${PYTHON_SITEPACKAGES_DIR}/*/*/.debug \
+ ${libdir}/${PYTHON_DIR}/.debug \
+ ${libdir}/${PYTHON_DIR}/*/.debug \
+ ${libdir}/${PYTHON_DIR}/*/*/.debug \
I thought packages that used distutils generally put their files under
sitepackages, and not the python base directory... Are some packages
doing it wrong?
pexpect was installing /usr/lib/python2.7 and that was my basis for
the correct location so I changed it to ${libdir} to fix that... I
just sent another patch that might address this issue..
-M
Ross
___
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] why does using a revision prevent downloading during a parse?
On Wed, Aug 22, 2012 at 8:11 PM, Robert P. J. Day rpj...@crashcourse.ca wrote:
certainly about to embarrass myself again, but from
u-boot_2011.06.bb:
...
# This revision corresponds to the tag v2011.06
# We use the revision in order to avoid having to fetch it from the repo
during parse
SRCREV = b1af6f532e0d348b153d5c148369229d24af361a
PV = v2011.06+git${SRCPV}
...
i don't know what that means -- how does using that revision
prevent fetching? i would simply have defined the SRC_URI using the
tag value, so i'm not sure what benefit i'm getting out of the above.
You should look for the patch that made that change and read the commit message.
-M
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
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] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 5:49 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Mon, 2012-08-20 at 13:49 -0500, Matthew McClintock wrote:
kmod will fail to build with the following error because O_CLOEXEC is
not defined:
| libkmod/libkmod-module.c: In function 'kmod_module_get_initstate':
| libkmod/libkmod-module.c:1640: error: 'O_CLOEXEC' undeclared (first use in
this function)
| libkmod/libkmod-module.c:1640: error: (Each undeclared identifier is
reported only once
| libkmod/libkmod-module.c:1640: error: for each function it appears in.)
| libkmod/libkmod-module.c: In function 'kmod_module_get_refcnt':
| libkmod/libkmod-module.c:1754: error: 'O_CLOEXEC' undeclared (first use in
this function)
| libkmod/libkmod-module.c: In function 'kmod_module_get_sections':
| libkmod/libkmod-module.c:1913: error: 'O_CLOEXEC' undeclared (first use in
this function)
| libkmod/libkmod-file.c: In function 'kmod_file_open':
| libkmod/libkmod-file.c:282: error: 'O_CLOEXEC' undeclared (first use in
this function)
| libkmod/libkmod-file.c:282: error: (Each undeclared identifier is reported
only once
| libkmod/libkmod-file.c:282: error: for each function it appears in.)
Since we are only using kmod-native for depmod, and it's a non-threaded
user of this libary being built this should be safe to override O_CLOEXEC.
Keep in mind this is ONLY effecting the native builds and not what is
being shipped in the root file system.
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/recipes-kernel/kmod/kmod-native_git.bb |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/kmod/kmod-native_git.bb
b/meta/recipes-kernel/kmod/kmod-native_git.bb
index 96de8b8..3c5e3c3 100644
--- a/meta/recipes-kernel/kmod/kmod-native_git.bb
+++ b/meta/recipes-kernel/kmod/kmod-native_git.bb
@@ -4,7 +4,7 @@
require kmod.inc
inherit native
-PR = ${INC_PR}.0
+PR = ${INC_PR}.1
do_install_append (){
for tool in depmod insmod lsmod modinfo modprobe rmmod
@@ -12,3 +12,9 @@ do_install_append (){
ln -s kmod ${D}${bindir}/$tool
done
}
+
+do_compile_append (){
+ if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then
+ export CFLAGS=$CFLAGS -D O_CLOEXEC=0
+ fi
+}
A compile append would execute after the compile. Isn't this after the
point you need the change?
Yes, and this makes me wonder what I tested...
Anyways, v2 fixed up and sent. I also needed to export the CFLAGS even
earlier so they got picked up correctly.
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj raj.k...@gmail.com wrote:
On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
b29...@freescale.com wrote:
On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj raj.k...@gmail.com wrote:
On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock m...@freescale.com
wrote:
+
+do_configure_prepend (){
+ if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then
+ export CFLAGS=$CFLAGS -D O_CLOEXEC=0
+ fi
+}
IMO It would be safer to create a patch for kmod itself where you
define O_CLOEXEC if it
was not defined before. The above seems a bit risky
Why is it risky? I only wanted to do this for affected systems. There
is not an easy way to do this with a patch, unless of course I apply
the patch manually.
manually gripping at the host installation and then if O_CLOEXEC might
be in comments
How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h
and furthermore it if it comes from fcntl.h which is not where you are
looking for
I am grepping this file though?
there are few variables like that where its impacting more than
affected systems.
I don't follow...
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 1:41 PM, Saul Wold s...@linux.intel.com wrote:
On 08/21/2012 11:30 AM, Khem Raj wrote:
On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882
b29...@freescale.com wrote:
On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj raj.k...@gmail.com wrote:
On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
b29...@freescale.com wrote:
On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj raj.k...@gmail.com wrote:
On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
m...@freescale.com wrote:
+
+do_configure_prepend (){
+ if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h;
then
+ export CFLAGS=$CFLAGS -D O_CLOEXEC=0
+ fi
+}
IMO It would be safer to create a patch for kmod itself where you
define O_CLOEXEC if it
was not defined before. The above seems a bit risky
Why is it risky? I only wanted to do this for affected systems. There
is not an easy way to do this with a patch, unless of course I apply
the patch manually.
manually gripping at the host installation and then if O_CLOEXEC might
be in comments
How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h
and furthermore it if it comes from fcntl.h which is not where you are
looking for
I am grepping this file though?
I would go into the specific file where its asking for O_CLOEXEC
and add
#ifndef O_CLOEXEC
# define O_CLOEXEC 0
#endif
and be done with it
Wasn't this proposed back a month ago:
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026343.html
And there was discussion about that approach then? I think it was rejected
due to lack of testing.
Then we had a bit more analysis and discussion on the issue and others
chimed in they had implemented similar work arounds... it's all in
that thread.
-M
there are few variables like that where its impacting more than
affected systems.
I don't follow...
-M
___
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 v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 1:30 PM, Khem Raj raj.k...@gmail.com wrote:
On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882
b29...@freescale.com wrote:
On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj raj.k...@gmail.com wrote:
On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
b29...@freescale.com wrote:
On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj raj.k...@gmail.com wrote:
On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock m...@freescale.com
wrote:
+
+do_configure_prepend (){
+ if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then
+ export CFLAGS=$CFLAGS -D O_CLOEXEC=0
+ fi
+}
IMO It would be safer to create a patch for kmod itself where you
define O_CLOEXEC if it
was not defined before. The above seems a bit risky
Why is it risky? I only wanted to do this for affected systems. There
is not an easy way to do this with a patch, unless of course I apply
the patch manually.
manually gripping at the host installation and then if O_CLOEXEC might
be in comments
How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h
and furthermore it if it comes from fcntl.h which is not where you are
looking for
I am grepping this file though?
I would go into the specific file where its asking for O_CLOEXEC
and add
#ifndef O_CLOEXEC
# define O_CLOEXEC 0
#endif
and be done with it
Well this is seemingly the same way of doing it, just looks like you
always want it applied? I don't think it should always be applied.
If this was it takes to get the build fix in, then I will do it...
please confirm what will be accepted.
-M
there are few variables like that where its impacting more than
affected systems.
I don't follow...
-M
___
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 v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 2:02 PM, Chris Larson clar...@kergoth.com wrote:
On Tue, Aug 21, 2012 at 11:48 AM, Khem Raj raj.k...@gmail.com wrote:
On Tue, Aug 21, 2012 at 11:41 AM, Saul Wold s...@linux.intel.com wrote:
On 08/21/2012 11:30 AM, Khem Raj wrote:
On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882
b29...@freescale.com wrote:
On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj raj.k...@gmail.com wrote:
On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
b29...@freescale.com wrote:
On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj raj.k...@gmail.com wrote:
On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
m...@freescale.com wrote:
+
+do_configure_prepend (){
+ if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h;
then
+ export CFLAGS=$CFLAGS -D O_CLOEXEC=0
+ fi
+}
IMO It would be safer to create a patch for kmod itself where you
define O_CLOEXEC if it
was not defined before. The above seems a bit risky
Why is it risky? I only wanted to do this for affected systems. There
is not an easy way to do this with a patch, unless of course I apply
the patch manually.
manually gripping at the host installation and then if O_CLOEXEC might
be in comments
How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h
and furthermore it if it comes from fcntl.h which is not where you are
looking for
I am grepping this file though?
I would go into the specific file where its asking for O_CLOEXEC
and add
#ifndef O_CLOEXEC
# define O_CLOEXEC 0
#endif
and be done with it
This does seem like a nicer approach.
OK - 2v1 ;) I'll respin as a patch.
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc
On Tue, Aug 21, 2012 at 2:13 PM, Chris Larson clar...@kergoth.com wrote: On Tue, Aug 21, 2012 at 11:47 AM, McClintock Matthew-B29882 b29...@freescale.com wrote: #ifndef O_CLOEXEC # define O_CLOEXEC 0 #endif and be done with it Well this is seemingly the same way of doing it, just looks like you always want it applied? I don't think it should always be applied. If this was it takes to get the build fix in, then I will do it... please confirm what will be accepted. No, on newer systems O_CLOEXEC will be defined, so that #ifndef block will never be entered, and there'll be no change. Right, I was not thinking... -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libproxy: add dependency on glib-2.0
On Mon, Aug 20, 2012 at 8:50 AM, Paul Gortmaker paul.gortma...@windriver.com wrote: On 12-08-17 05:41 PM, Richard Purdie wrote: On Fri, 2012-08-17 at 14:07 -0400, Paul Gortmaker wrote: On 12-08-17 12:57 PM, Richard Purdie wrote: On Mon, 2012-08-13 at 18:43 -0400, Paul Gortmaker wrote: Without this, you will get occasional build failures if libproxy tries to build before the glib headers are placed in the sysroot. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com diff --git a/meta/recipes-support/libproxy/libproxy_0.4.7.bb b/meta/recipes-support/libproxy/libproxy_0.4.7.bb index 7e3cf27..a39e3a8 100644 --- a/meta/recipes-support/libproxy/libproxy_0.4.7.bb +++ b/meta/recipes-support/libproxy/libproxy_0.4.7.bb @@ -6,7 +6,7 @@ LICENSE = LGPLv2.1+ LIC_FILES_CHKSUM = file://COPYING;md5=7d704a7b1b116e8783edcdb44ff4 \ file://utils/proxy.c;beginline=1;endline=18;md5=55152a1006d7dafbef32baf9c30a99c0 -DEPENDS = gconf +DEPENDS = gconf glib-2.0 We've gone around in circles on this and had issues over circular dependencies. The bottom line is that we don't need glib-2.0 here, we want to disable the glib-2.0 using components of libproxy. I don't know Fair enough. Can we _finally_ fix the mailing lists to not override the To/Cc lines with crap Reply-To: lines? Once again I almost missed seeing this reply, since I was no longer on the To/Cc. AFAICT, all were in agreement that it was broken, but it never got fixed. There were a few things causing problems here such as lost admin access. Those have been resolved and I just changed the setting that I think was causing the problems. Let me know if there are still issues... Looks good now, thanks a lot. Much appreciated by many, I'm sure. Awesome, looks to be working for me too. Did you do oe-devel as well? -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cross-localedef-native_2.16.bb: fix for CentOS 5.X
On Fri, Aug 17, 2012 at 7:10 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Thu, 2012-08-16 at 18:12 -0500, Matthew McClintock wrote:
| gcc
-isystem/home/mattsm/git/poky/build-master/tmp/sysroots/x86_64-linux/usr/include
-isystem/home/mattsm/git/poky/build-master/tmp/sysroots/x86_64-linux/usr/include
-O2 -pipe -DNOT_IN_libc=1 -DNO_SYSCONF -DNO_UNCOMPRESS
-DLOCALE_PATH='/usr/local/lib/locale:/usr/local/share/i18n'
-DLOCALEDIR='/usr/local/lib/locale'
-DLOCALE_ALIAS_PATH='/usr/local/share/locale'
-DCHARMAP_PATH='/usr/local/share/i18n/charmaps'
-DREPERTOIREMAP_PATH='/usr/local/share/i18n/repertoiremaps'
-DLOCSRCDIR='/usr/local/share/i18n/locales' -DNOT_IN_libc
-DIN_GLIBC_LOCALEDEF -Iglibc/locale/programs -I./include -Iglibc/locale -I.
-I. -include ./include/always.h -Wall -Wno-format -c -o ld-address.o
glibc/locale/programs/ld-address.c
| In file included from glibc/locale/programs/localedef.h:24,
| from glibc/locale/programs/ld-address.c:30:
| ./include/locale.h:6: error: conflicting types for 'locale_t'
| glibc/locale/xlocale.h:42: error: previous declaration of 'locale_t' was
here
| make: *** [ld-address.o] Error 1
| ERROR: oe_runmake failed
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/recipes-core/eglibc/cross-localedef-native_2.16.bb | 9 +++--
.../eglibc/eglibc-2.16/fix_for_centos_5.8.patch | 13
+
2 files changed, 20 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-core/eglibc/eglibc-2.16/fix_for_centos_5.8.patch
diff --git a/meta/recipes-core/eglibc/cross-localedef-native_2.16.bb
b/meta/recipes-core/eglibc/cross-localedef-native_2.16.bb
index 47f0834..a79a276 100644
--- a/meta/recipes-core/eglibc/cross-localedef-native_2.16.bb
+++ b/meta/recipes-core/eglibc/cross-localedef-native_2.16.bb
@@ -13,10 +13,15 @@ LIC_FILES_CHKSUM =
file://${LIC_DIR}/LICENSES;md5=98a1128c4b58120182cbea3b1752d
inherit native
inherit autotools
-PR = r0
+# pick up an eglibc-2.16 patch
+FILESPATH = ${FILE_DIRNAME}/eglibc-${PV}
+
+PR = r1
SRCREV=19383
EGLIBC_BRANCH=eglibc-2_16
-SRC_URI =
svn://www.eglibc.org/svn/branches/;module=${EGLIBC_BRANCH};protocol=http
+SRC_URI =
svn://www.eglibc.org/svn/branches/;module=${EGLIBC_BRANCH};protocol=http \
+file://fix_for_centos_5.8.patch;patchdir=.. \
+
S = ${WORKDIR}/${EGLIBC_BRANCH}/localedef
do_unpack_append() {
diff --git a/meta/recipes-core/eglibc/eglibc-2.16/fix_for_centos_5.8.patch
b/meta/recipes-core/eglibc/eglibc-2.16/fix_for_centos_5.8.patch
new file mode 100644
index 000..32ee16d
--- /dev/null
+++ b/meta/recipes-core/eglibc/eglibc-2.16/fix_for_centos_5.8.patch
@@ -0,0 +1,13 @@
+Index: eglibc-2_16/libc/locale/programs/config.h
No patch header here...
Overlooked late last night, v2 sent.
-M
Cheers,
Richard
+===
+--- eglibc-2_16.orig/libc/locale/programs/config.h
eglibc-2_16/libc/locale/programs/config.h
+@@ -19,6 +19,8 @@
+ #ifndef _LD_CONFIG_H
+ #define _LD_CONFIG_H1
+
++#define DUMMY_LOCALE_T
++
+ /* Use the internal textdomain used for libc messages. */
+ #define PACKAGE _libc_intl_domainname
+ #ifndef VERSION
___
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] libproxy: add dependency on glib-2.0
On Fri, Aug 17, 2012 at 1:07 PM, Paul Gortmaker paul.gortma...@windriver.com wrote: On 12-08-17 12:57 PM, Richard Purdie wrote: On Mon, 2012-08-13 at 18:43 -0400, Paul Gortmaker wrote: Without this, you will get occasional build failures if libproxy tries to build before the glib headers are placed in the sysroot. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com diff --git a/meta/recipes-support/libproxy/libproxy_0.4.7.bb b/meta/recipes-support/libproxy/libproxy_0.4.7.bb index 7e3cf27..a39e3a8 100644 --- a/meta/recipes-support/libproxy/libproxy_0.4.7.bb +++ b/meta/recipes-support/libproxy/libproxy_0.4.7.bb @@ -6,7 +6,7 @@ LICENSE = LGPLv2.1+ LIC_FILES_CHKSUM = file://COPYING;md5=7d704a7b1b116e8783edcdb44ff4 \ file://utils/proxy.c;beginline=1;endline=18;md5=55152a1006d7dafbef32baf9c30a99c0 -DEPENDS = gconf +DEPENDS = gconf glib-2.0 We've gone around in circles on this and had issues over circular dependencies. The bottom line is that we don't need glib-2.0 here, we want to disable the glib-2.0 using components of libproxy. I don't know Fair enough. Can we _finally_ fix the mailing lists to not override the To/Cc lines with crap Reply-To: lines? Once again I almost missed seeing this reply, since I was no longer on the To/Cc. PLEASE ;) -M AFAICT, all were in agreement that it was broken, but it never got fixed. Thanks, Paul. -- cmake well enough to know how to configure it to do this though (instead of autodetecting) 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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [discussion] perf: specify SLANG_INC dir for perf
On Thu, Aug 16, 2012 at 10:58 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2012-08-16 at 11:33 -0400, Bruce Ashfield wrote: On 12-08-13 10:17 PM, Liang Li wrote: Hi Richard, Ping ... Hopefully you could recall sufficient context from this thread about the 'include path for slang.h' cause compile error issue that we are trying to fix here. Bump. I'm holding off on merging a kernel patch for this while this is still outstanding. Can I distill this into the following (in the hope of resolving it). - do we want to fix this problem for all kernels, or just the linux-yocto ones ? And by 'fix', I mean without the requirement of porting a kernel patch to older recipes. I propose we add a sed expression to the general kernel do_install which changes the -I/usr/include/slang - -I=/usr/include/slang. That should be generic, acceptable to upstream and fixes all kernel versions. Comments? That would work for me as well ;) -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod: Handle undefined O_CLOEXEC
On Tue, Jul 24, 2012 at 8:40 AM, Burton, Ross ross.bur...@intel.com wrote: On 24 July 2012 14:27, Chris Larson clar...@kergoth.com wrote: On Tue, Jul 24, 2012 at 12:37 AM, Radu Moisan radu.moi...@intel.com wrote: I have not tested on CentOS 5.8 if the applications are not broken in some way, but that's not in the scope of this patch. If something does indeed break, then a totally different patch is required, targeting a backport of kmod for kernel older than 2.6.23. Personally, I'd rather see the build fail than have the tools behave incorrectly in some inexplicable way. If you haven't tested it, the patch shouldn't go in. I was curious... There are two commits in kmod where the cloexec changes were made: http://git.profusion.mobi/cgit.cgi/kmod.git/log/?qt=grepq=cloexec The changes were a simple addition of the O_CLOEXEC flag, so this patch is simply the union of those two commits. A release of kmod that doesn't require O_CLOEXEC has the same behaviour as this patch. The problem O_CLOEXEC is solving isn't possible to solve cleanly without it. Using an older version of kmod instead of patching kmod to work on older systems would result in more bugs and less features for no win. Was there any conclusion on this? I'm seeing the same problems. This would only effect kmod-native (unless the target was using the older stuff as well which is uncommon at this point). Looking the commit that adds this as a dep: commit f22cf1bedf2aa7fb41f98d6165401eb8a8bad17d Author: Khem Raj raj.k...@gmail.com Date: Tue Jan 31 00:35:02 2012 -0800 image.bbclass,kernel.bbclass: Use kmod-native instead of module-init-tools-cross We are just using depmod from this recipe for the kernel build, which is a non-threaded user of this libraries built within kmod - therefore we should not encounter any issues [1](after reading what O_CLOEXEC does) with this patch except that it should only be applied to -native builds. Also, if issues do present themselves they will be during the build and not later at runtime so we can identify any issues that arise. So in summary, the patch should (IMO) be: SRC_URI_append_virtclass-native = file://Handle-unsupported-close-on-exec-flag.patch Thoughts? [1] http://lwn.net/Articles/249006/ -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kmod: Handle undefined O_CLOEXEC
On Wed, Aug 15, 2012 at 2:10 PM, Chris Larson clar...@kergoth.com wrote:
On Wed, Aug 15, 2012 at 11:37 AM, McClintock Matthew-B29882
b29...@freescale.com wrote:
On Tue, Jul 24, 2012 at 8:40 AM, Burton, Ross ross.bur...@intel.com wrote:
On 24 July 2012 14:27, Chris Larson clar...@kergoth.com wrote:
On Tue, Jul 24, 2012 at 12:37 AM, Radu Moisan radu.moi...@intel.com
wrote:
I have not tested on CentOS 5.8 if the applications are not broken in some
way, but that's not in the scope of this patch. If something does indeed
break, then a totally different patch is required, targeting a backport of
kmod for kernel older than 2.6.23.
Personally, I'd rather see the build fail than have the tools behave
incorrectly in some inexplicable way. If you haven't tested it, the
patch shouldn't go in.
I was curious...
There are two commits in kmod where the cloexec changes were made:
http://git.profusion.mobi/cgit.cgi/kmod.git/log/?qt=grepq=cloexec
The changes were a simple addition of the O_CLOEXEC flag, so this
patch is simply the union of those two commits. A release of kmod
that doesn't require O_CLOEXEC has the same behaviour as this patch.
The problem O_CLOEXEC is solving isn't possible to solve cleanly
without it. Using an older version of kmod instead of patching kmod
to work on older systems would result in more bugs and less features
for no win.
Was there any conclusion on this? I'm seeing the same problems. This
would only effect kmod-native (unless the target was using the older
stuff as well which is uncommon at this point).
For what it's worth, we applied this in our layer and things do seem
to work fine with this applied. It was either this or what we did
before (reverted the switch to kmod-native and retained
module-init-tools-cross), as we require CentOS5/RHEL5 support still.
I've been doing something similar and it's been working OK. - I think
we should apply Ross's patch.
-M
diff --git a/meta/recipes-kernel/kmod/kmod-native_git.bb
b/meta/recipes-kernel/kmod/kmod-native_git.bb
index 96de8b8..054a842 100644
--- a/meta/recipes-kernel/kmod/kmod-native_git.bb
+++ b/meta/recipes-kernel/kmod/kmod-native_git.bb
@@ -4,7 +4,9 @@
require kmod.inc
inherit native
-PR = ${INC_PR}.0
+PR = ${INC_PR}.1
+
+CFLAGS += -D O_CLOEXEC=0
do_install_append (){
for tool in depmod insmod lsmod modinfo modprobe rmmod
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED REQUEST 46/64] owl-video_git.bb: fix compilation on Fedora 13 machine
Saul,
I think we decided to wait / ignore this one.
-M
On Tue, Aug 14, 2012 at 7:13 AM, Saul Wold s...@linux.intel.com wrote:
From: Matthew McClintock m...@freescale.com
This adds libXrandr to the link step and fixes this issue:
|
/opt/yocto/upstream/label/master/machine/atom-pc/poky/edison/tmp/sysroots/atom-pc/usr/lib/libgdk-x11-2.0.so:
undefined reference to `XRRGetOutputInfo'
|
/opt/yocto/upstream/label/master/machine/atom-pc/poky/edison/tmp/sysroots/atom-pc/usr/lib/libgdk-x11-2.0.so:
undefined reference to `XRRGetScreenResourcesCurrent'
|
/opt/yocto/upstream/label/master/machine/atom-pc/poky/edison/tmp/sysroots/atom-pc/usr/lib/libgdk-x11-2.0.so:
undefined reference to `XRRFreeOutputInfo'
|
/opt/yocto/upstream/label/master/machine/atom-pc/poky/edison/tmp/sysroots/atom-pc/usr/lib/libgdk-x11-2.0.so:
undefined reference to `XRRFreeScreenResources'
|
/opt/yocto/upstream/label/master/machine/atom-pc/poky/edison/tmp/sysroots/atom-pc/usr/lib/libgdk-x11-2.0.so:
undefined reference to `XRRGetOutputPrimary'
|
/opt/yocto/upstream/label/master/machine/atom-pc/poky/edison/tmp/sysroots/atom-pc/usr/lib/libgdk-x11-2.0.so:
undefined reference to `XRRFreeCrtcInfo'
|
/opt/yocto/upstream/label/master/machine/atom-pc/poky/edison/tmp/sysroots/atom-pc/usr/lib/libgdk-x11-2.0.so:
undefined reference to `XRRGetCrtcInfo'
| collect2: ld returned 1 exit status
Signed-off-by: Matthew McClintock m...@freescale.com
Signed-off-by: Saul Wold s...@linux.intel.com
---
.../owl-video/0001-add-dependency-for-xrandr.patch | 30
.../recipes-sato/owl-video-widget/owl-video_git.bb |5 ++-
2 files changed, 33 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-sato/owl-video-widget/owl-video/0001-add-dependency-for-xrandr.patch
diff --git
a/meta/recipes-sato/owl-video-widget/owl-video/0001-add-dependency-for-xrandr.patch
b/meta/recipes-sato/owl-video-widget/owl-video/0001-add-dependency-for-xrandr.patch
new file mode 100644
index 000..8c14578
--- /dev/null
+++
b/meta/recipes-sato/owl-video-widget/owl-video/0001-add-dependency-for-xrandr.patch
@@ -0,0 +1,30 @@
+Upstream-Status: Pending
+
+This patch should probably go upstream
+
+From 18bdd57b36489439dc5c18b20abd9d59c6778662 Mon Sep 17 00:00:00 2001
+From: Matthew McClintock m...@freescale.com
+Date: Wed, 25 Jul 2012 15:05:40 -0500
+Subject: [PATCH] add dependency for xrandr
+
+Signed-off-by: Matthew McClintock m...@freescale.com
+---
+ src/Makefile.am |2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/src/Makefile.am b/src/Makefile.am
+index 60e845b..00e4b11 100644
+--- a/src/Makefile.am
b/src/Makefile.am
+@@ -12,7 +12,7 @@ video_SOURCES = video.c \
+ owl-overlay-bin.c \
+ owl-overlay-bin.h
+
+-video_LDADD = $(VIDEO_LIBS)
++video_LDADD = $(VIDEO_LIBS) -lXrandr
+
+ dist_pkgdata_DATA = gtk-fullscreen.png
+
+--
+1.7.5.4
+
diff --git a/meta/recipes-sato/owl-video-widget/owl-video_git.bb
b/meta/recipes-sato/owl-video-widget/owl-video_git.bb
index bc63273..321b71b 100644
--- a/meta/recipes-sato/owl-video-widget/owl-video_git.bb
+++ b/meta/recipes-sato/owl-video-widget/owl-video_git.bb
@@ -10,7 +10,7 @@ DEPENDS = libowl-av
SRCREV = f133472318970796fae1ea3e98ac062156768baf
PV = 0.1+git${SRCPV}
-PR = r1
+PR = r2
S = ${WORKDIR}/git
@@ -23,7 +23,8 @@ SRC_URI = git://git.yoctoproject.org/${BPN};protocol=git \
file://stock_volume-med.png \
file://stock_volume-max.png \
file://owl-video-widget.desktop \
- file://make-382.patch
+ file://make-382.patch \
+ file://0001-add-dependency-for-xrandr.patch
inherit autotools pkgconfig
--
1.7.7.6
___
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] perf on older kernels
On Aug 14, 2012 10:11 PM, Bruce Ashfield bruce.ashfi...@gmail.commailto:bruce.ashfi...@gmail.com wrote: On Tue, Aug 14, 2012 at 6:39 PM, McClintock Matthew-B29882 b29...@freescale.commailto:b29...@freescale.com wrote: I've had to fix / hack the perf_3.4.bbhttp://perf_3.4.bb recipe to get it building on my older kernel. Should we add perf_3.0.bbhttp://perf_3.0.bb recipes in oe-core or my own layer? Or try to keep one recipe working for all versions? I have no strong opinions. I'd prefer one recipe. Liang sent another proposal earlier for a fix that should make it work on all kernels. Just waiting to hear on that at the moment. I've actually got other issues... -M Cheers, Bruce -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.orgmailto:Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.orgmailto: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] [oe-core] udev: update rcS to auto-detect hostname
On Tue, Aug 14, 2012 at 10:01 PM, Khem Raj raj.k...@gmail.com wrote: On Tue, Aug 14, 2012 at 8:08 PM, b19...@freescale.com wrote: echo `cat /proc/cpuinfo | grep model | cut -d , -f 2 | tr [A-Z] [a-z]` $ echo `cat /proc/cpuinfo | grep model | cut -d , -f 2 | tr [A-Z] [a-z]` model : 23 model name : intel(r) core(tm)2 quad cpu q9300 @ 2.50ghz model : 23 model name : intel(r) core(tm)2 quad cpu q9300 @ 2.50ghz model : 23 model name : intel(r) core(tm)2 quad cpu q9300 @ 2.50ghz model : 23 model name : intel(r) core(tm)2 quad cpu q9300 @ 2.50ghz is that what we want ? I think we need an option to turn it on or off and or make it configurable from a BSP layer. We are looking for a way to make a rfs for all e500v2 or e500mc, etc and say the right machine type on the prompt. -M ___ 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] [oe-core] udev: update rcS to auto-detect hostname
On Tue, Aug 14, 2012 at 11:12 PM, Chris Larson clar...@kergoth.com wrote: On Tue, Aug 14, 2012 at 9:06 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: On Tue, Aug 14, 2012 at 10:01 PM, Khem Raj raj.k...@gmail.com wrote: On Tue, Aug 14, 2012 at 8:08 PM, b19...@freescale.com wrote: echo `cat /proc/cpuinfo | grep model | cut -d , -f 2 | tr [A-Z] [a-z]` $ echo `cat /proc/cpuinfo | grep model | cut -d , -f 2 | tr [A-Z] [a-z]` model : 23 model name : intel(r) core(tm)2 quad cpu q9300 @ 2.50ghz model : 23 model name : intel(r) core(tm)2 quad cpu q9300 @ 2.50ghz model : 23 model name : intel(r) core(tm)2 quad cpu q9300 @ 2.50ghz model : 23 model name : intel(r) core(tm)2 quad cpu q9300 @ 2.50ghz is that what we want ? I think we need an option to turn it on or off and or make it configurable from a BSP layer. We are looking for a way to make a rfs for all e500v2 or e500mc, etc and say the right machine type on the prompt. This sounds like something that really does belong in your own supplementary layer, rather than oe-core. Seemed like a valuable option for making rfs for multiple machines / targets, but if we don't want it (or some of the bits) in oe-core that's fine by me too. -M -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ 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] owl-video_git.bb: fix compilation on Fedora 13 machine
On Fri, Aug 10, 2012 at 7:54 AM, Burton, Ross ross.bur...@intel.com wrote: On 8 August 2012 17:07, McClintock Matthew-B29882 b29...@freescale.com wrote: Any comments on this? owl-video isn't pulling in Xrandr directly, so something is wrong with the linker flags produced by GTK+. I wonder if -Wl,--as-needed is breaking this... Can you replicate and provide the full build log? Err, I went back and now I can't even reproduce this issue... I guess we can ignore it for the time being. -M Ross ___ 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
