[OE-core] question about FILE_DIRNAME versus THISDIR when setting FILESPATH
probably a simple answer to this, but in examining the way FILESPATH
is created, i notice that, in .bb recipe files, the general form of
setting FILESPATH always seems to involve the use of the FILE_DIRNAME
variable, such as in the default value from base.bbclass:
FILESPATH = ${@base_set_filespath([${FILE_DIRNAME}/${BP},
${FILE_DIRNAME}/${BPN}, ${FILE_DIRNAME}/files], d)}
however, when one is extending FILESPATH in .bbappend files, the
variable used to refer to the current directory is always THISDIR. but
it's not clear what the distinction is.
i'm using bb show and, when i'm referring to the value of
FILESPATH for an overlayed recipe, both FILE_DIRNAME and THISDIR seem
to properly refer to the directory for the bbappend file.
can someone clarify the proper usage of these variables? in
particular, why it's important for .bb files to use FILE_DIRNAME but
.bbappend files to use THISDIR? thanks.
rday
p.s. i'll have a more involved FILESPATH question shortly.
--
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.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/8] udev: fix dependency and location of udevadm
On 11/10/2013 06:54 AM, Phil Blundell wrote:
On Sat, 2013-11-09 at 13:28 +0800, qi.c...@windriver.com wrote:
+ install -d ${D}${base_bindir}
+ mv ${D}${bindir}/udevadm ${D}${base_bindir}/udevadm
+ rmdir ${D}${bindir}
This will fail if ${bindir} and ${base_bindir} are the same.
p.
In udev recipe, they are not defined as the same one.
And moving something from bindir to base_bindir doesn't seem uncommon in
OE, you can grep the project using the following command.
grep -Ri 'mv.*bindir.*base_bindir' meta/*
Best Regards,
Chen Qi
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/8] initscripts: add setup-commands.sh
On 11/10/2013 07:00 AM, Phil Blundell wrote:
On Sat, 2013-11-09 at 13:28 +0800, qi.c...@windriver.com wrote:
+for dir in /usr/bin /usr/sbin; do
+if [ ! -e $dir ]; then
+ if [ $VERBOSE != no ]; then
+ echo WARN: $dir missing, setting up links to busybox
+ fi
+ mkdir -p $dir
+ for suffix in .nosuid .suid ; do
+ if [ ! -e /etc/busybox.links${suffix} ]; then
+ continue
+ fi
+ usr_commands=`grep $dir /etc/busybox.links${suffix}`
+ for command in $usr_commands; do
+ ln -sf /bin/busybox${suffix} $command
+ done
Hi Phil,
This script is an effort to try to make system boot up even if /usr is
not there.
It relies on busybox because in most cases, busybox is there in an OE
based system.
And please see comments below.
This seems slightly bogus for a number of reasons:
1. initscript doesn't obviously rdepend on busybox so it's not obvious
that the latter will always be available;
Yes. Initscript doesn't rdepend on busybox. But note it also doesn't
rdepend on sed or awk or grep.
So I think it's reasonable to assume the presence of busybox.
2. it should probably be using ${base_bindir} and ${bindir} rather than
hardcoding absolute paths.
In init scripts, we usually hardcode things, because these scripts are
destined to run on target.
In recipes we try not to hardcode things because the recipe may need to
extend to native or nativesdk.
3. the whole idea of creating a shadow /usr/bin underneath what's
meant to be a mountpoint seems rather dubious to me.
Agree.
The problem here is that the init scripts under /etc/rcS.d/ need to
execute commands like awk, dirname, and readlink which are from /usr.
As it's not appropriate to move these commands into /bin, basically
there are only two options I can see here. One is to modify these
scripts to use only commands from /bin or /sbin; the other is to make
use of busybox, as busybox is located under /bin as it provides these
commands.
I chose to the latter one because I thought that solution would have the
less impact.
What do you think? Do we need to modify the init scripts? Or any other
solution?
4. this seems like distro policy and not something that really belongs
in oe-core at all. For systems where ${bindir} and ${base_bindir} are
on the same filesystem (or even are the same directory) this script will
just make bootup slower without achieving anything useful.
p.
If /usr and / are on the same file system, this script has no real
effect because /usr will always be there. So I think it will not take
much time at boot.
If ${base_bindir} and ${bindir} are the same, that means that there's no
/usr. In this case, there should no /usr/xxx entries in
/etc/busybox.links, so this script should also function correctly and it
will not take much time at boot.
(I just configured ${bindir} and ${base_bindir} to be the same and
performed a build, it failed. I'm not sure whether it's valid to make
such configurations in OE.)
Best Regards,
Chen Qi
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Disable building libgcc with -O0
Link error happens for valgrind when linking unoptimized libgcc.
Libgcc requires symbol _Unwind_Resume defined in libgcc_eh which
in turn requires pulling in entire glibc. We can't make valgrind
link with glibc due to its design. So don't build libgcc without
optimizations, so that calls to _Unwind_Resume get eliminated.
Signed-off-by: Lei Liu lei.l...@windriver.com
---
meta/recipes-devtools/gcc/gcc-cross.inc | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc
b/meta/recipes-devtools/gcc/gcc-cross.inc
index 25a3142..cf03c08 100644
--- a/meta/recipes-devtools/gcc/gcc-cross.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross.inc
@@ -25,6 +25,15 @@ EXTRA_OECONF_PATHS = \
ARCH_FLAGS_FOR_TARGET += -isystem${STAGING_DIR_TARGET}${target_includedir}
+def get_optimization(d):
+selected_optimization = d.getVar(SELECTED_OPTIMIZATION, True)
+if base_contains(SELECTED_OPTIMIZATION, -O0, x, , d) == x:
+bb.note(libgcc can't be built with -O0, -O2 will be used instead.)
+return selected_optimization.replace(-O0, -O2)
+return selected_optimization
+
+SELECTED_OPTIMIZATION := ${@get_optimization(d)}
+
do_configure_prepend () {
sed -i 's/BUILD_INFO=info/BUILD_INFO=/' ${S}/gcc/configure
}
--
1.8.2.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Enable building multiarch mips gcc
MIPS gcc is not configured with multiarch enabled. This causes
compiler generates local label with $ prefix, which is specified
in default o32 abi. It is not recognized as local symbol by n64
assembler, so we get a lot of unexpected external symbols. We
should configure MIPS gcc with --enable-targets=all, as for other
archs.
Signed-off-by: Lei Liu lei.l...@windriver.com
---
meta/recipes-devtools/gcc/gcc-common.inc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-common.inc
b/meta/recipes-devtools/gcc/gcc-common.inc
index adaef03..6f3bd24 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -28,6 +28,7 @@ def get_gcc_multiarch_setting(bb, d):
multiarch_options = {
i586:--enable-targets=all,
powerpc: --enable-targets=powerpc64,
+mips:--enable-targets=all,
sparc: --enable-targets=all,
}
--
1.7.0.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2] systemd: Upgrade 206 - 208
Remove patches accepted upstream
Forward-port uclibc patches
Create additional packages to bundle zsh support files
Signed-off-by: Khem Raj raj.k...@gmail.com
---
.../0001-use-CAP_MKNOD-ConditionCapability.patch | 32 -
.../systemd/systemd/systemd-pam-fix-msformat.patch | 137 ++---
.../systemd/{systemd_206.bb = systemd_208.bb} | 12 +-
3 files changed, 76 insertions(+), 105 deletions(-)
delete mode 100644
meta/recipes-core/systemd/systemd/0001-use-CAP_MKNOD-ConditionCapability.patch
rename meta/recipes-core/systemd/{systemd_206.bb = systemd_208.bb} (97%)
diff --git
a/meta/recipes-core/systemd/systemd/0001-use-CAP_MKNOD-ConditionCapability.patch
b/meta/recipes-core/systemd/systemd/0001-use-CAP_MKNOD-ConditionCapability.patch
deleted file mode 100644
index 4a35c23..000
---
a/meta/recipes-core/systemd/systemd/0001-use-CAP_MKNOD-ConditionCapability.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-Upstream-Status: Submitted
-
-From cfdd1eb76dced87c73bac8ec22d3a10244c9bbf6 Mon Sep 17 00:00:00 2001
-From: Khem Raj raj.k...@gmail.com
-Date: Wed, 21 Aug 2013 20:25:19 -0700
-Subject: [PATCH] use CAP_MKNOD ConditionCapability
-
-Fixes errors seen when booting VMs on QEMU like
-
-systemd[1]: kmod-static-nodes.service: main process exited, code=exited,
status=203/EXEC
-systemd[1]: Failed to start Create list of required static device nodes for
the current kernel.
-systemd[1]: Unit kmod-static-nodes.service entered failed state.
-
-Make sure that mknod capability is available
-
-Signed-off-by: Khem Raj raj.k...@gmail.com
- units/kmod-static-nodes.service.in | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-Index: systemd-206/units/kmod-static-nodes.service.in
-===
systemd-206.orig/units/kmod-static-nodes.service.in2013-08-21
19:13:02.0 -0700
-+++ systemd-206/units/kmod-static-nodes.service.in 2013-08-21
20:39:13.310689871 -0700
-@@ -9,6 +9,7 @@
- Description=Create list of required static device nodes for the current kernel
- DefaultDependencies=no
- Before=sysinit.target systemd-tmpfiles-setup-dev.service
-+ConditionCapability=CAP_MKNOD
-
- [Service]
- Type=oneshot
diff --git a/meta/recipes-core/systemd/systemd/systemd-pam-fix-msformat.patch
b/meta/recipes-core/systemd/systemd/systemd-pam-fix-msformat.patch
index 77bb305..e8a9144 100644
--- a/meta/recipes-core/systemd/systemd/systemd-pam-fix-msformat.patch
+++ b/meta/recipes-core/systemd/systemd/systemd-pam-fix-msformat.patch
@@ -1,10 +1,10 @@
Upstream-Status: Denied [no desire for uclibc support]
Signed-off-by: Khem Raj raj.k...@gmail.com
-Index: systemd-204/src/fsck/fsck.c
+Index: systemd-208/src/fsck/fsck.c
===
systemd-204.orig/src/fsck/fsck.c 2013-04-02 05:48:49.0 -0700
-+++ systemd-204/src/fsck/fsck.c2013-05-23 11:26:51.776345015 -0700
+--- systemd-208.orig/src/fsck/fsck.c 2013-08-13 13:02:46.0 -0700
systemd-208/src/fsck/fsck.c2013-11-05 22:01:26.776490078 -0800
@@ -37,6 +37,8 @@
#include virt.h
#include fileio.h
@@ -33,10 +33,10 @@ Index: systemd-204/src/fsck/fsck.c
/* Only show one progress counter at max */
if (!locked) {
-Index: systemd-204/src/core/swap.c
+Index: systemd-208/src/core/swap.c
===
systemd-204.orig/src/core/swap.c 2013-05-06 12:06:04.0 -0700
-+++ systemd-204/src/core/swap.c2013-05-23 11:26:51.780345015 -0700
+--- systemd-208.orig/src/core/swap.c 2013-09-26 11:20:30.0 -0700
systemd-208/src/core/swap.c2013-11-05 22:01:26.776490078 -0800
@@ -41,6 +41,8 @@
#include path-util.h
#include virt.h
@@ -46,15 +46,15 @@ Index: systemd-204/src/core/swap.c
static const UnitActiveState state_translation_table[_SWAP_STATE_MAX] = {
[SWAP_DEAD] = UNIT_INACTIVE,
[SWAP_ACTIVATING] = UNIT_ACTIVATING,
-@@ -1055,6 +1057,7 @@
- char *dev = NULL, *d;
+@@ -1041,6 +1043,7 @@
+ _cleanup_free_ char *dev = NULL, *d = NULL;
int prio = 0, k;
+#ifdef HAVE_MSFORMAT
k = fscanf(m-proc_swaps,
%ms /* device/file */
%*s /* type of swap */
-@@ -1062,6 +1065,16 @@
+@@ -1048,6 +1051,16 @@
%*s /* used */
%i\n, /* priority */
dev, prio);
@@ -71,10 +71,10 @@ Index: systemd-204/src/core/swap.c
if (k != 2) {
if (k == EOF)
break;
-Index: systemd-204/src/core/mount-setup.c
+Index: systemd-208/src/core/mount-setup.c
===
systemd-204.orig/src/core/mount-setup.c2013-04-24 06:34:38.0
-0700
[OE-core] [PATCH] elfutils: remove eu-objdump if it does not work
From: Roy Li rongqing...@windriver.com
[YOCTO #5283]
eu-objdump does not work on mips, arm and ppc, so remove it from these
unsupported architectures
Signed-off-by: Roy Li rongqing...@windriver.com
---
meta/recipes-devtools/elfutils/elfutils_0.155.bb |6 ++
1 file changed, 6 insertions(+)
diff --git a/meta/recipes-devtools/elfutils/elfutils_0.155.bb
b/meta/recipes-devtools/elfutils/elfutils_0.155.bb
index 1a8c3c7..dec3379 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.155.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.155.bb
@@ -47,6 +47,12 @@ do_configure_prepend() {
cp ${WORKDIR}/*dis.h ${S}/libcpu
}
+do_install_append() {
+ if [ ${TARGET_ARCH} != x86_64 ] [ ! `echo ${TARGET_ARCH}|grep
-q 'i.86'` ];then
+ rm ${D}${bindir}/eu-objdump
+ fi
+}
+
# we can not build complete elfutils when using uclibc
# but some recipes e.g. gcc 4.5 depends on libelf so we
# build only libelf for uclibc case
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
