[Openembedded-architecture] Host tools available from PATH

Richard Purdie richard.purdie at linuxfoundation.org
Thu Mar 9 11:39:14 UTC 2017


We have a determinism problem with recipe specific sysroots (RSS)
highlighted in that tools from the host in PATH can mean recipes work
on some systems and not others. The host having pkg-config installed
and the recipe missing an "inherit pkgconfig" is one such example.

There are two basic ways we can improve the situation, one is the
approach Peter sent patches for which is to have "poisoned" tools in
PATH so the host ones don't get used. This does mean adding such a tool
for each one we want to intercept.

The other approach is to create a "known good" list of tools and put
this as a replacement for PATH. I've created such a patch as a proof of
concept to see what challenges such an approach might bring (included
at the end of this mail).

Firstly, why is this important? OE has a reputation for not being 100%
deterministic. RSS goes a long way to address that however this current
issue is probably going to mean we can't shake that reputation unless
we solve it too. I believe if we merge the blacklist approach, whilst
on a technical level there isn't an issue, our reputation will suffer
badly. I'm therefore fast coming to the conclusion that we need to
implement some kind of whitelist ASAP. I believe strongly enough in
this that I may hold 2.3 M3 (and hence the feature freeze) until we
sort this.

My patch is rather creative/evil. By adding it in layer.conf, it works
before any real parsing happens and therefore gets injected very early
into the process. That is good and the issues of the currently bad user
feedback can be fixed. The downside to it is that its not user
extensible. If you have a missing utility that you need for local
changes (e.g. tasksel in my case or Martin's use of icecc), you're out
of luck in being able to add them.

I see a few possible options:

a) My current approach and then later we give users the option of 
   extending the list (and the directory) at ConfigParsed time
b) Parse with the system PATH and switch to a restricted set at   
   ConfigParsed time.
c) Just use the restricted set in bitbake worker (execution time).
d) Some other combination

I think I'm leaning towards a). That would allow the later second stage
processing to handle user or class additions to the toolset. In fact
thinking about this more, I may be able to do better as there are
probably only a limited set of things needed for the ConfigParsed
stage, maybe even just uname.

I'm sending this to ask whether people feel this is worth getting right
for 2.3 and whether we should hold M3 and the feature freeze to get
something implemented? This would assume we then are prepared to take
the pain of actually populating these lists (I've made a start for OE-
Core at least).

Also to be clear, if we do want to get this into 2.3, it is going to
mean moving fairly fast. I think we can get this right quite quickly
based on my experiments so far and I know others are also running them.
That means if anyone objects to this (and moving quickly) I need to
know about it now.

Cheers,

Richard

From: Richard Purdie <richard.purdie at linuxfoundation.org>
Subject: bitbake/oe-core: Filter contents of PATH

Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>

diff --git a/bitbake/lib/bb/utils.py b/bitbake/lib/bb/utils.py
index d6bcfa3..dbb74dd 100644
--- a/bitbake/lib/bb/utils.py
+++ b/bitbake/lib/bb/utils.py
@@ -1526,3 +1526,13 @@ class LogCatcher(logging.Handler):
         self.messages.append(bb.build.logformatter.format(record))
     def contains(self, message):
         return (message in self.messages)
+
+def setup_native_bindir(dest, toolsvar, d):
+    tools = d.getVar(toolsvar).split()
+    path = os.environ.get("PATH")
+    mkdirhier(dest)
+    for tool in tools:
+        desttool = os.path.join(dest, tool)
+        if not os.path.exists(desttool):
+            srctool = which(path, tool)
+            os.symlink(srctool, desttool)
diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index afc3b0e..0c59e7d 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -62,3 +62,24 @@ SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += " \
   oprofile->virtual/kernel \
 "
 
+# Tools needed to run builds with OE-Core
+NATIVETOOLS = " \
+    bash sh cut sed gcc ld git rm install which find xargs cat true
mktemp \
+    grep tar gzip touch cp mv basename dirname tr getopt sort awk head
tail \
+    mkdir patch uniq perl python chmod python3 ar strip expr ls make
as \
+    ranlib egrep echo chown cpio tee wc wget bzip2 stat date rmdir od
diff \
+    md5sum unlzma dd chrpath file pod2man gunzip python2.7 ln g++ [
false true \
+    uname test hostname nm objdump objcopy cmp printf env readlink
flex gawk fgrep \
+    expand pwd sleep diffstat chgrp flock ldd strings rpcgen ld.bfd du
\
+"
+
+# Tools needed to run testimage runtime image testing
+NATIVETOOLS += " \
+    ps stty ip ssh scp ping \
+"
+
+# Tools needed for local RP hacks
+NATIVETOOLS += "taskset"
+
+DUMMY := "${@bb.utils.setup_native_bindir('${TOPDIR}/nativetools',
'NATIVETOOLS', d)}"
+PATH = "${TOPDIR}/nativetools"


More information about the Openembedded-architecture mailing list