Is Regulatory DB enabled in the kernel?

[lybtongji]

Is Regulatory DB enabled in the kernel? I want the Edison work in 5GHz AP mode. Thanks.

[htot]

I don't know, I haven't tried. But if the original edison kernel supported it, it should be easy enough to add.

[lybtongji]

Thanks for replying.

[htot]

We could try to add this. What do you need?

[lybtongji]

Thanks. I’m happy to hear that. ^_^

I just want to let the Intel Edison as a Wireless Access Point.

I had let the Intel Edison works in 2.4GHz mode with hostapd, but failed in 5Ghz mode.

Then I found a solution for this problem. link: https://communities.intel.com/thread/57515

It said that the Regulatory DB is not enabled in the original edison kernel.

[alext-mkrs]

But as these days we anyway use te upstream kernel, we could enable it right away. Here's the link from that thread highlighting the option that needs to be enabled: http://wireless.kernel.org/en/developers/Regulatory/CRDA%23CONFIG_CFG80211_INTERNAL_REGDB

[htot]

Right, but as I understand the preferred method is to use the crda package. And this will probably just build on rocko: http://layers.openembedded.org/layerindex/recipe/71066/

[alext-mkrs]

Yeah, that or the kernel option - in the thread it was mentioned that crda way didn't work right away while kernel option did.

Either way, @lybtongji, if you need that, it could be done.

[lybtongji]

Yes, I need it. Thanks very much.

Alex T notifications@github.com 于 2018年6月6日周三 00:54写道：

Yeah, that or the kernel option - in the thread it was mentioned that crda way didn't work right away while kernel option did.

Either way, @lybtongji https://github.com/lybtongji, if you need that, it could be done.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/htot/meta-intel-edison/issues/21#issuecomment-394782829, or mute the thread https://github.com/notifications/unsubscribe-auth/AGdvNcfvI852dJgvURXy2FC3UtO0Gj6yks5t5reogaJpZM4UWRg4 .

[alext-mkrs]

Ok, I'll take a look sometime this week. I'll have to refresh my build setup so it'll take some time - I'll post back when I have something tangible.

[htot]

I think in the thread crda didn't build because edison's yocto was too old. But thanks for taking this @alext-mkrs, on first start of a fresh rootfs I always see annoying errors from hostapd passing by. A reminder that that is still on the todo.

[htot]

PS I created a super group on Telegram called Intel Edison, where we can discuss stuff

[alext-mkrs]

All right, so I have checked and looks like at least on the rocko32-produced image everything works in 5GHz mode without any problems, out of the box. You just need to set three main parameters (as also highlighted in the accepted answer in the Intel forums thread): hw_mode, channel and country.

After doing that I can see the test SSID on 5GHz. So give it a try, @lybtongji.

[alext-mkrs]

PS I created a super group on Telegram called Intel Edison, where we can discuss stuff

Too bad they require a phone number. I would suggest something like Matrix - this has gateways to everything, allows to setup "rooms" and doesn't require your phone number to register.

[lybtongji]

OK. Thanks for your work. I will try it. @alext-mkrs

[lybtongji]

Hello, Alex. @alext-mkrs I have tried the rocko32. But there are some problems. My OS is Ubuntu 16.04. I used these commands to build the image.

cd
mkdir os
cd os
git clone -b rocko32 https://github.com/htot/meta-intel-edison.git
cd meta-intel-edison
./setup.sh
cd /home/recover/os/out/linux64
source poky/oe-init-build-env
bitbake -k edison-image

Then I got errors. To fix the first error, I edited the file /home/recover/os/meta-intel-edison/meta-intel-edison-bsp/recipes-kernel/linux/linux-yocto_4.16.0.bb. But how can I deal with the remaining errors?

ERROR: u-boot-1_2018.05-r0 do_patch: Command Error: 'quilt --quiltrc /home/recover/os/out/linux64/build/tmp/work/edison-poky-linux/u-boot/1_2018.05-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output: Applying patch 0006-HACK-mmc-sdhci-SDHCI-controllers-also-need-power.patch patching file arch/x86/dts/edison.dts Hunk #1 succeeded at 66 (offset -1 lines). patching file board/intel/edison/edison.c Hunk #1 FAILED at 14. 1 out of 1 hunk FAILED -- rejects in file board/intel/edison/edison.c patching file drivers/mmc/sdhci.c Hunk #1 succeeded at 478 (offset 1 line). Patch 0006-HACK-mmc-sdhci-SDHCI-controllers-also-need-power.patch does not apply (enforce with -f) ERROR: u-boot-1_2018.05-r0 do_patch: Function failed: patch_do_patch ERROR: Logfile of failure stored in: /home/recover/os/out/linux64/build/tmp/work/edison-poky-linux/u-boot/1_2018.05-r0/temp/log.do_patch.30391 ERROR: Task (/home/recover/os/meta-intel-edison/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot_2018.05.bb:do_patch) failed with exit code '1' ERROR: u-boot-fw-utils-1_2018.05-r0 do_patch: Command Error: 'quilt --quiltrc /home/recover/os/out/linux64/build/tmp/work/edison-poky-linux/u-boot-fw-utils/1_2018.05-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output: Applying patch 0006-HACK-mmc-sdhci-SDHCI-controllers-also-need-power.patch patching file arch/x86/dts/edison.dts Hunk #1 succeeded at 66 (offset -1 lines). patching file board/intel/edison/edison.c Hunk #1 FAILED at 14. 1 out of 1 hunk FAILED -- rejects in file board/intel/edison/edison.c patching file drivers/mmc/sdhci.c Hunk #1 succeeded at 478 (offset 1 line). Patch 0006-HACK-mmc-sdhci-SDHCI-controllers-also-need-power.patch does not apply (enforce with -f) ERROR: u-boot-fw-utils-1_2018.05-r0 do_patch: Function failed: patch_do_patch ERROR: Logfile of failure stored in: /home/recover/os/out/linux64/build/tmp/work/edison-poky-linux/u-boot-fw-utils/1_2018.05-r0/temp/log.do_patch.30396 ERROR: Task (/home/recover/os/meta-intel-edison/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot-fw-utils_2018.05.bb:do_patch) failed with exit code '1' NOTE: Tasks Summary: Attempted 4153 tasks of which 4151 didn't need to be rerun and 2 failed. Summary: 2 tasks failed: /home/recover/os/meta-intel-edison/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot_2018.05.bb:do_patch /home/recover/os/meta-intel-edison/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot-fw-utils_2018.05.bb:do_patch Summary: There were 4 ERROR messages shown, returning a non-zero exit code.

[htot]

Telegram wants your phone number only once. You can install only any device, it does not depend on the number.

[htot]

The 2nd error is caused by a missing space ' '

I think these errors were caused by my typo's in linux-yocto_4.16.0.bb that @alext-mkrs already resolved. I squashed these in rocko32 yesterday evening. You might want to fetch and checkout the latest and make update .

[alext-mkrs]

Telegram wants your phone number only once. You can install only any device, it does not depend on the number.

Yeah, but the point is that I don't want to give up my number at all :) Never mind, so far it generally was okay to use just GH and if not we can always revise.

[lybtongji]

OK, it works fine. @htot

You can use a virtual phone number (like Textnow) to login Telegram. @alext-mkrs

[alext-mkrs]

Closing this one as @lybtongji has confirmed it works now.

[htot]

@lybtongji have you been able build crda now and use that to setup hostapd in 5GHz mode?

[lybtongji]

@htot After built and flashed rocko32, I just set the parameters: hw_mode, channel and country. Then the hostapd had already worked in 5GHz mode. But the command iw reg set [Your COUNTRY] does not work. iw reg get still shows “country 00”. I don't know how crda works. There was also a problem that the wifi could not work in Managed mode. And I try to build the branch master at the moment, then get an error:

[alext-mkrs]

Well, if you already set your country via hostapd.conf, I don't think you need to set it via iw.

EDIT: and what exactly do you mean by "the wifi could not work in Managed mode."? When hostapd is active (i.e. the wireless adapter is in AP mode) I don't think you can use the client mode, if that's what you mean.

The error shown is fixed by the latest commit in master (https://github.com/edison-fw/meta-intel-edison/commit/535f3a33e6c2b2114719315a7e3ca324a33caa7e) - are you sure you have the latest one?

[lybtongji]

@alext-mkrs My git shows "Already up-to-date."

recover@ilab:~/os/meta-intel-edison$  git remote -v
origin  https://github.com/edison-fw/meta-intel-edison/ (fetch)
origin  https://github.com/edison-fw/meta-intel-edison/ (push)
recover@ilab:~/os/meta-intel-edison$  git pull
Already up-to-date.
recover@ilab:~/os/meta-intel-edison$

[lybtongji]

@alext-mkrs OK. When I build again, It works fine. I don't know why.

[lybtongji]

@alext-mkrs Another error appeared:

[alext-mkrs]

@lybtongji, and could you please show what git status returns? That's a bit strange. The second build would pass, that's the nature of the problem - only the first build fails.

As for the second problem - looks like you don't have python 2.7 available on the host and nodejs-native build process needs that. At least that's as much as I can see from the screenshot - and I haven't had such problems in my builds.

[lybtongji]

@alext-mkrs I use pyenv to manage python version

recover@ilab:~/os$  pyenv version
2.7.14 (set by /home/recover/.pyenv/version)
3.6.4 (set by /home/recover/.pyenv/version)
recover@ilab:~/os$  cd meta-intel-edison/
recover@ilab:~/os/meta-intel-edison$  git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

I think the commits maybe not merge into master.

[lybtongji]

@alext-mkrs If I use the default python in system. I will get an error: (My default python in system is Python3, to run Python2 need to type python2)

OpenEmbedded requires 'python' to be python v2 (>= 2.7.3), not python v3.

recover@ilab:~/os$  make clean
rm -rf out
recover@ilab:~/os$  rm -rf bbcache/sstate-cache/
recover@ilab:~/os$  make setup
Setup buildenv for SDK host linux64
./meta-intel-edison/setup.sh  --dl_dir=/home/recover/os/bbcache/downloads --sstate_dir=/home/recover/os/bbcache/sstate-cache --build_dir=/home/recover/os/out/linux64 --build_name=custom_build_recover@20180708203138 --sdk_host=linux64
Fetching origin
Fetching origin
Fetching origin
Fetching origin
Fetching origin
Fetching origin
Fetching origin
Cloning Poky in the /home/recover/os/out/linux64/poky directory
Cloning into 'poky'...
done.
Already on 'rocko'
Your branch is up-to-date with 'origin/rocko'.
Cloning Mingw layer to /home/recover/os/out/linux64/poky/meta-mingw directory from local cache
Cloning into 'meta-mingw'...
done.
Cloning Darwin layer to /home/recover/os/out/linux64/poky/meta-darwin directory from local cache
Cloning into 'meta-darwin'...
done.
Note: checking out '29b5ff31cee24e796f2eb2d2fd1269e3e92c831c'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 29b5ff3... gcc-runtime: Don't pollute global export namespace
Cloning Openembedded layer to /home/recover/os/out/linux64/poky/meta-openembedded directory from local cache
Cloning into 'meta-openembedded'...
done.
Branch rocko set up to track remote branch rocko from origin.
Switched to a new branch 'rocko'
Cloning Nodejs layer to /home/recover/os/out/linux64/poky/meta-nodejs directory from local cache
Cloning into 'meta-nodejs'...
done.
Already on 'master'
Your branch is up-to-date with 'origin/master'.
Cloning meta-intel layer to /home/recover/os/out/linux64/poky/meta-intel directory from local cache
Cloning into 'meta-intel'...
done.
Branch rocko set up to track remote branch rocko from origin.
Switched to a new branch 'rocko'
meta-acpi already exists, rebasing from local cache
From /home/recover/os/bbcache/downloads/meta-acpi-mirror
 * branch            eds        -> FETCH_HEAD
Current branch eds is up to date.
Cloning meta-arduino layer to /home/recover/os directory from GitHub.com/01org/meta-arduino
Cloning into 'meta-arduino'...
remote: Counting objects: 72, done.
remote: Compressing objects: 100% (42/42), done.
remote: Total 72 (delta 22), reused 72 (delta 22), pack-reused 0
Unpacking objects: 100% (72/72), done.
Checking connectivity... done.
Already on '1.6.x'
Your branch is up-to-date with 'origin/1.6.x'.
Applying patch on poky
Initializing yocto build environment
OpenEmbedded requires 'python' to be python v2 (>= 2.7.3), not python v3.
Please set up python v2 as your default 'python' interpreter.
Makefile:25: recipe for target 'setup' failed
make: *** [setup] Error 1
recover@ilab:~/os$

[alext-mkrs]

Thanks. Okay, so what's in git log then? The commit is on master right now and for a while.

As for Python, looking at how pyenv works

At a high level, pyenv intercepts Python commands using shim executables injected into your PATH <...>

I don't think that's going to work reliably with Yocto, as at the recipe build level the PATH set in the shell that executed bitbake does not mean a lot. But ultimately, take a look at the error log file referenced, it should have more details

[lybtongji]

@alext-mkrs The log:

recover@ilab:~/os$  cd meta-intel-edison/
recover@ilab:~/os/meta-intel-edison$  git log
commit 535f3a33e6c2b2114719315a7e3ca324a33caa7e
Author: Alex Tereschenko <alext.mkrs@gmail.com>
Date:   Mon Jun 25 21:19:03 2018 +0200

    linux-yocto: fix failure upon the first kernel build after setup

    After setting up the build env for the first time or a full cleanup,
    the kernel build fails with

    |   CC      scripts/mod/empty.o
    | cc1: error: code model 'kernel' not supported in the 32 bit mode
    | cc1: sorry, unimplemented: 64-bit mode not compiled in

    This is caused by the fact that .config is created completely
    incorrectly and has 64bit enabled, among other things. This, in turn,
    is caused by the fact that "make alldefconfig" called by merge_config.sh
    fails not being able to find bison - kernels from 4.16 onwards require it (+flex).

    The bison-native package is in the DEPENDS, but is not deployed into sysroot
    until right before the do_configure task and merge_config.sh runs
    within do_kernel_configme, earlier than that. All subsequent task runs succeed,
    because bison is already deployed into the recipe's sysroot.

    There's a Yocto commit, which seemingly addresses this problem:

    https://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/kernel.bbclass?id=20e4d309e12bf10e2351e0016b606e85599b80f6

    but doesn't help as it only makes the dependency explicit, but does nothing
    w.r.t. the do_configure vs. do_kernel_configme ordering.

    So, work this around by adding an explicit dependency between do_kernel_configme
    and bison-native's sysroot deployment task. This must be clarified with Yocto folks
    in the long run.

    Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>

commit 8fc9117b643d447ddadf4cf724e8ecef8b3cef5b
Author: Alex Tereschenko <alext.mkrs@gmail.com>
Date:   Sat Jun 23 21:22:12 2018 +0200

    Fix repo references after moving to edison-fw org

    Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>

commit fc6803fcc11a658399a8ec2763aeded79ca57194
Author: Ferry Toth <ftoth@exalondelft.nl>
Date:   Sat May 12 16:00:22 2018 +0200

    image: switch 32 bits

    Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>

commit a4179ac78604de4b8e201fb27fd688d879550741
Author: Ferry Toth <ftoth@exalondelft.nl>
Date:   Sat May 12 15:58:37 2018 +0200

    acpi: disable

    Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>

commit 5572634401d8d716283278197786bd2ab6d4ff8e
Author: Ferry Toth <ftoth@exalondelft.nl>
Date:   Sat Jun 16 20:25:15 2018 +0200

    u-boot: switch to 2018.05

    Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>

    Fix build failures after last changes

    Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
    Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>

commit a060efa3b56e3a7b22bc78adb44fea6b488bc1e0
Author: Ferry Toth <ftoth@exalondelft.nl>
Date:   Sun Jun 10 20:36:16 2018 +0200

    serial_8250: hsu: add patch to transmit message without interchar gap

    tx buffer is circular, so when a message sent is placed near the end of the buffer,
    transmit happens as 2 dma transactions. The 2nd is started on
    interrupt and latency can cause a interchar gap. This copies the buffer to a lineair
    buffer so each message is always sent in a single transaction. This only works for
    message less than a page size.

    while we're at it, hsu and hsu dma interrupts are handled by the hsu handler. However,
    hsu dma also generates it own interrupts. The hsu dma handler does not handle these,
    but since they are level triggered, they reoccur and an interrupts storm happens.
    On edison the hsu dma interrupt line is not shared with other devices, so we can
    just disable the interrupt

    Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>

For the second log, I will build it again, due to cleanup.

[lybtongji]

@alext-mkrs

recover@ilab:~$  cat /home/recover/os/out/linux64/build/tmp/work/x86_64-linux/nodejs-native/6.10.3-r1.8/temp/log.do_configure.3130
DEBUG: Executing shell function do_configure
Please use either Python 2.6 or 2.7:

  /home/recover/os/out/linux64/build/tmp/hosttools/python2 ./configure --prefix=/home/recover/os/out/linux64/build/tmp/work/x86_64-linux/nodejs-native/6.10.3-r1.8/recipe-sysroot-native/usr --dest-cpu=x64 --dest-os=linux --without-snapshot --with-intl=none --shared-openssl --without-inspector --shared-zlib
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_configure (log file is located at /home/recover/os/out/linux64/build/tmp/work/x86_64-linux/nodejs-native/6.10.3-r1.8/temp/log.do_configure.3130)

[lybtongji]

@alext-mkrs I can run the command

/home/recover/os/out/linux64/build/tmp/hosttools/python2 ./configure --prefix=/home/recover/os/out/linux64/build/tmp/work/x86_64-linux/nodejs-native/6.10.3-r1.8/recipe-sysroot-native/usr --dest-cpu=x64 --dest-os=linux --without-snapshot --with-intl=none --shared-openssl --without-inspector --shared-zlib

in /home/recover/os/out/linux64/build/tmp/work/x86_64-linux/nodejs-native/6.10.3-r1.8/node-v6.10.3 without any error. (/home/recover/os/out/linux64/build/tmp/hosttools/python2 -> /home/recover/.pyenv/shims/python2*)

And the command

/usr/bin/python2 ./configure --prefix=/home/recover/os/out/linux64/build/tmp/work/x86_64-linux/nodejs-native/6.10.3-r1.8/recipe-sysroot-native/usr --dest-cpu=x64 --dest-os=linux --without-snapshot --with-intl=none --shared-openssl --without-inspector --shared-zlib

is also success.

[lybtongji]

@alext-mkrs I try to link /home/recover/os/out/linux64/build/tmp/hosttools/python2 to /usr/bin/python2, but still get error when run make edison-image.

ln -sf /usr/bin/python2 /home/recover/os/out/linux64/build/tmp/hosttools/python2

[lybtongji]

I find sys.version_info in node-v6.10.3/configure is Python 3 (pyenv) when make edison-image.

sys.version_info(major=3, minor=6, micro=4, releaselevel='final', serial=0)

[alext-mkrs]

Yes, apparently the buid process picks up your system python despite pyenv shims (and the fact that you can run that tmp/hosttools thing is sort of irrelevant - build when runs has a semi-isolated env variable environment, so it's not representative anyway).

I've never run Yocto builds with things like that, only relied on system python being the right one, so you may need to dig into details of how it works inside if you want to have it running pyenv - this is not meta-intel-edison specific at all. Quick googling haven't showed up anything meaningful, so it would seem like that could be a somewhat exotic combination (or people have no problems with that).

[alext-mkrs]

...just checked - on my Ubuntu 16.04 host, for example, I have both python 2 and 3 installed system-wide and the build is able to pick whatever it needs - so you may want to do something similar as a simple remediation. And for your dev needs you can use pyenv-managed one, separately.

[lybtongji]

@alext-mkrs Thanks. It might be pyenv's bug. But in some Linux distributions, python means python3 not python2 by default. It can be a problem when run make setup (get error in openembedded). I need to set the python to python2.

---

UPDATA: It is really a bug of pyenv. https://github.com/pyenv/pyenv/issues/985

[alext-mkrs]

What's you distro? In general, I think it actually autodetects which versions are available, not relying on strictly the name.

I've found the reason for the kernel compile error BTW - the committed fix needed an addition, there's another piece it needs (flex in addition to bison). I'll submit a PR for that soon.

[lybtongji]

@alext-mkrs I have a laptop (Fedora 28, python -> python3 by default) and a server (Ubuntu 16.04). Last time, I had built rocko32 fine with Ubuntu 16.04 using system Python (python -> python3, python2). But at this time, I got the error (master). I will try to set python to python2 tomorrow.

[alext-mkrs]

If that error you refer to was python-related, then yeah, why not try (even though I believe Yocto sorts this out by itself and your build experience on Ubuntu sort of confirms that), but if that was one of those kernel build related ones you've demonstrated on screenshots earlier, then check out PR #30, it should take care of both of them.

[lybtongji]

@alext-mkrs I link /usr/bin/python to /usr/bin/python2.7 and disable pyenv then make edison-image runs fine.

By the way, if python is set to python3, the command make setup will give an error:

OpenEmbedded requires 'python' to be python v2 (>= 2.7.3), not python v3.
Please set up python v2 as your default 'python' interpreter.

[lybtongji]

@alext-mkrs I have made edison-image successfully using pyenv. I think there is some typos in the layers. The error info is:

| DEBUG: Executing shell function do_configure
| Please use either Python 2.6 or 2.7:
|
|   /home/recover/os/out/linux64/build/tmp/hosttools/python2 ./configure --prefix=/home/recover/os/out/linux64/build/tmp/work/x86_64-linux/nodejs-native/6.10.3-r1.8/recipe-sysroot-native/usr --dest-cpu=x64 --dest-os=linux --without-snapshot --with-intl=none --shared-openssl --without-inspector --shared-zlib
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure (log file is located at /home/recover/os/out/linux64/build/tmp/work/x86_64-linux/nodejs-native/6.10.3-r1.8/temp/log.do_configure.40650)

I had tried to relink /home/recover/os/out/linux64/build/tmp/hosttools/python2, and let it point to /usr/bin/python2. But it did not work. Now I find there are other python links in /home/recover/os/out/linux64/build/tmp/hosttools/ I guess bitbake is use /home/recover/os/out/linux64/build/tmp/hosttools/python (not /home/recover/os/out/linux64/build/tmp/hosttools/python2) to run the command. Then I relink /home/recover/os/out/linux64/build/tmp/hosttools/python to /home/recover/.pyenv/versions/2.7.14/bin/python.

ln -s /home/recover/.pyenv/versions/2.7.14/bin/python /home/recover/os/out/linux64/build/tmp/hosttools/python

Finally, make edison-image gives no errors.

[alext-mkrs]

I think there is some typos in the layers

Nah, that hosttools dir is apparently autogenerated.

...which suggests me something - could you try the following:

1. delete all python-related links from that dir
2. set python 2.x as your default via pyenv
3. run the build
4. do a ls -alF on the hosttools dir and post here

Then repeat the above, but set python 3 as your pyenv default.

My hypothesis is that the dir may have been generated when you had python 3 set as your pyenv default and after that it simply kept the links as is. If that's the case, then the above would show that - as the /home/recover/os/out/linux64/build/tmp/hosttools/python link will be switching along with the pyenv switches. If so then pyenv would actually be easy to use with Yocto - you just need to remove the links after switching the pyenv defaults, so that bitbake regenerates its own links.

I've also finally dug into this and like I said - PATH is sanitized, but I've found some info on this hosttools thing: https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration-2.3-path-variable. So worst case you can just manually set the links there, but try the above and I hope we'll see that it behaves as I described above, so you can do that semiautomatically.

[lybtongji]

@alext-mkrs

hosttools dir

recover@ilab:~$  ls -alF /home/recover/os/out/linux64/build/tmp/hosttools
total 8
drwxrwxr-x  2 recover recover 4096 7月  10 13:46 ./
drwxrwxr-x 12 recover recover 4096 7月  10 13:47 ../
lrwxrwxrwx  1 recover recover   10 7月  10 13:46 [ -> /usr/bin/[*
lrwxrwxrwx  1 recover recover   11 7月  10 13:46 ar -> /usr/bin/ar*
lrwxrwxrwx  1 recover recover   11 7月  10 13:46 as -> /usr/bin/as*
lrwxrwxrwx  1 recover recover   12 7月  10 13:46 awk -> /usr/bin/awk*
lrwxrwxrwx  1 recover recover   17 7月  10 13:46 basename -> /usr/bin/basename*
lrwxrwxrwx  1 recover recover    9 7月  10 13:46 bash -> /bin/bash*
lrwxrwxrwx  1 recover recover   10 7月  10 13:46 bzip2 -> /bin/bzip2*
lrwxrwxrwx  1 recover recover    8 7月  10 13:46 cat -> /bin/cat*
lrwxrwxrwx  1 recover recover   10 7月  10 13:46 chgrp -> /bin/chgrp*
lrwxrwxrwx  1 recover recover   10 7月  10 13:46 chmod -> /bin/chmod*
lrwxrwxrwx  1 recover recover   10 7月  10 13:46 chown -> /bin/chown*
lrwxrwxrwx  1 recover recover   16 7月  10 13:46 chrpath -> /usr/bin/chrpath*
lrwxrwxrwx  1 recover recover   12 7月  10 13:46 cmp -> /usr/bin/cmp*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 comm -> /usr/bin/comm*
lrwxrwxrwx  1 recover recover    7 7月  10 13:46 cp -> /bin/cp*
lrwxrwxrwx  1 recover recover    9 7月  10 13:46 cpio -> /bin/cpio*
lrwxrwxrwx  1 recover recover   12 7月  10 13:46 cpp -> /usr/bin/cpp*
lrwxrwxrwx  1 recover recover   12 7月  10 13:46 cut -> /usr/bin/cut*
lrwxrwxrwx  1 recover recover    9 7月  10 13:46 date -> /bin/date*
lrwxrwxrwx  1 recover recover    7 7月  10 13:46 dd -> /bin/dd*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 diff -> /usr/bin/diff*
lrwxrwxrwx  1 recover recover   17 7月  10 13:46 diffstat -> /usr/bin/diffstat*
lrwxrwxrwx  1 recover recover   16 7月  10 13:46 dirname -> /usr/bin/dirname*
lrwxrwxrwx  1 recover recover   11 7月  10 13:46 du -> /usr/bin/du*
lrwxrwxrwx  1 recover recover    9 7月  10 13:46 echo -> /bin/echo*
lrwxrwxrwx  1 recover recover   10 7月  10 13:46 egrep -> /bin/egrep*
lrwxrwxrwx  1 recover recover   12 7月  10 13:46 env -> /usr/bin/env*
lrwxrwxrwx  1 recover recover   15 7月  10 13:46 expand -> /usr/bin/expand*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 expr -> /usr/bin/expr*
lrwxrwxrwx  1 recover recover   10 7月  10 13:46 false -> /bin/false*
lrwxrwxrwx  1 recover recover   10 7月  10 13:46 fgrep -> /bin/fgrep*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 file -> /usr/bin/file*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 find -> /usr/bin/find*
lrwxrwxrwx  1 recover recover   14 7月  10 13:46 flock -> /usr/bin/flock*
lrwxrwxrwx  1 recover recover   12 7月  10 13:46 g++ -> /usr/bin/g++*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 gawk -> /usr/bin/gawk*
lrwxrwxrwx  1 recover recover   12 7月  10 13:46 gcc -> /usr/bin/gcc*
lrwxrwxrwx  1 recover recover   15 7月  10 13:46 gcc-ar -> /usr/bin/gcc-ar*
lrwxrwxrwx  1 recover recover   16 7月  10 13:46 getconf -> /usr/bin/getconf*
lrwxrwxrwx  1 recover recover   15 7月  10 13:46 getopt -> /usr/bin/getopt*
lrwxrwxrwx  1 recover recover   12 7月  10 13:46 git -> /usr/bin/git*
lrwxrwxrwx  1 recover recover   12 7月  10 13:46 gpg -> /usr/bin/gpg*
lrwxrwxrwx  1 recover recover    9 7月  10 13:46 grep -> /bin/grep*
lrwxrwxrwx  1 recover recover   11 7月  10 13:46 gunzip -> /bin/gunzip*
lrwxrwxrwx  1 recover recover    9 7月  10 13:46 gzip -> /bin/gzip*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 head -> /usr/bin/head*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 hostname -> /bin/hostname*
lrwxrwxrwx  1 recover recover   11 7月  10 13:46 id -> /usr/bin/id*
lrwxrwxrwx  1 recover recover   16 7月  10 13:46 install -> /usr/bin/install*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 join -> /usr/bin/join*
lrwxrwxrwx  1 recover recover   11 7月  10 13:46 ld -> /usr/bin/ld*
lrwxrwxrwx  1 recover recover   15 7月  10 13:46 ld.bfd -> /usr/bin/ld.bfd*
lrwxrwxrwx  1 recover recover   12 7月  10 13:46 ldd -> /usr/bin/ldd*
lrwxrwxrwx  1 recover recover   16 7月  10 13:46 ld.gold -> /usr/bin/ld.gold*
lrwxrwxrwx  1 recover recover    7 7月  10 13:46 ln -> /bin/ln*
lrwxrwxrwx  1 recover recover    7 7月  10 13:46 ls -> /bin/ls*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 make -> /usr/bin/make*
lrwxrwxrwx  1 recover recover   17 7月  10 13:46 makeinfo -> /usr/bin/makeinfo*
lrwxrwxrwx  1 recover recover   15 7月  10 13:46 md5sum -> /usr/bin/md5sum*
lrwxrwxrwx  1 recover recover   10 7月  10 13:46 mkdir -> /bin/mkdir*
lrwxrwxrwx  1 recover recover   10 7月  10 13:46 mknod -> /bin/mknod*
lrwxrwxrwx  1 recover recover   11 7月  10 13:46 mktemp -> /bin/mktemp*
lrwxrwxrwx  1 recover recover    7 7月  10 13:46 mv -> /bin/mv*
lrwxrwxrwx  1 recover recover    7 7月  10 13:46 nc -> /bin/nc*
lrwxrwxrwx  1 recover recover   11 7月  10 13:46 nl -> /usr/bin/nl*
lrwxrwxrwx  1 recover recover   11 7月  10 13:46 nm -> /usr/bin/nm*
lrwxrwxrwx  1 recover recover   16 7月  10 13:46 objcopy -> /usr/bin/objcopy*
lrwxrwxrwx  1 recover recover   16 7月  10 13:46 objdump -> /usr/bin/objdump*
lrwxrwxrwx  1 recover recover   11 7月  10 13:46 od -> /usr/bin/od*
lrwxrwxrwx  1 recover recover   14 7月  10 13:46 patch -> /usr/bin/patch*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 perl -> /usr/bin/perl*
lrwxrwxrwx  1 recover recover   16 7月  10 13:46 pod2man -> /usr/bin/pod2man*
lrwxrwxrwx  1 recover recover   11 7月  10 13:46 pr -> /usr/bin/pr*
lrwxrwxrwx  1 recover recover   15 7月  10 13:46 printf -> /usr/bin/printf*
lrwxrwxrwx  1 recover recover    8 7月  10 13:46 pwd -> /bin/pwd*
lrwxrwxrwx  1 recover recover   46 7月  10 13:46 python -> /home/recover/.pyenv/versions/3.6.4/bin/python*
lrwxrwxrwx  1 recover recover   34 7月  10 13:46 python2 -> /home/recover/.pyenv/shims/python2*
lrwxrwxrwx  1 recover recover   36 7月  10 13:46 python2.7 -> /home/recover/.pyenv/shims/python2.7*
lrwxrwxrwx  1 recover recover   47 7月  10 13:46 python3 -> /home/recover/.pyenv/versions/3.6.4/bin/python3*
lrwxrwxrwx  1 recover recover   15 7月  10 13:46 ranlib -> /usr/bin/ranlib*
lrwxrwxrwx  1 recover recover   16 7月  10 13:46 readelf -> /usr/bin/readelf*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 readlink -> /bin/readlink*
lrwxrwxrwx  1 recover recover    7 7月  10 13:46 rm -> /bin/rm*
lrwxrwxrwx  1 recover recover   10 7月  10 13:46 rmdir -> /bin/rmdir*
lrwxrwxrwx  1 recover recover   15 7月  10 13:46 rpcgen -> /usr/bin/rpcgen*
lrwxrwxrwx  1 recover recover    8 7月  10 13:46 sed -> /bin/sed*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 sftp -> /usr/bin/sftp*
lrwxrwxrwx  1 recover recover    7 7月  10 13:46 sh -> /bin/sh*
lrwxrwxrwx  1 recover recover   18 7月  10 13:46 sha256sum -> /usr/bin/sha256sum*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 size -> /usr/bin/size*
lrwxrwxrwx  1 recover recover   10 7月  10 13:46 sleep -> /bin/sleep*
lrwxrwxrwx  1 recover recover   14 7月  10 13:46 socat -> /usr/bin/socat*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 sort -> /usr/bin/sort*
lrwxrwxrwx  1 recover recover   14 7月  10 13:46 split -> /usr/bin/split*
lrwxrwxrwx  1 recover recover   12 7月  10 13:46 ssh -> /usr/bin/ssh*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 stat -> /usr/bin/stat*
lrwxrwxrwx  1 recover recover   16 7月  10 13:46 strings -> /usr/bin/strings*
lrwxrwxrwx  1 recover recover   14 7月  10 13:46 strip -> /usr/bin/strip*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 sudo -> /usr/bin/sudo*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 tail -> /usr/bin/tail*
lrwxrwxrwx  1 recover recover    8 7月  10 13:46 tar -> /bin/tar*
lrwxrwxrwx  1 recover recover   12 7月  10 13:46 tee -> /usr/bin/tee*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 test -> /usr/bin/test*
lrwxrwxrwx  1 recover recover   14 7月  10 13:46 touch -> /usr/bin/touch*
lrwxrwxrwx  1 recover recover   11 7月  10 13:46 tr -> /usr/bin/tr*
lrwxrwxrwx  1 recover recover    9 7月  10 13:46 true -> /bin/true*
lrwxrwxrwx  1 recover recover   10 7月  10 13:46 uname -> /bin/uname*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 uniq -> /usr/bin/uniq*
lrwxrwxrwx  1 recover recover   11 7月  10 13:46 wc -> /usr/bin/wc*
lrwxrwxrwx  1 recover recover   13 7月  10 13:46 wget -> /usr/bin/wget*
lrwxrwxrwx  1 recover recover   14 7月  10 13:46 which -> /usr/bin/which*
lrwxrwxrwx  1 recover recover   14 7月  10 13:46 xargs -> /usr/bin/xargs*
lrwxrwxrwx  1 recover recover   12 7月  10 13:46 yes -> /usr/bin/yes*
lrwxrwxrwx  1 recover recover    9 7月  10 13:46 zcat -> /bin/zcat*
recover@ilab:~$

hosttools dir

recover@ilab:~$  ls -alF /home/recover/os/out/linux64/build/tmp/hosttools
total 8
drwxrwxr-x  2 recover recover 4096 7月  10 13:56 ./
drwxrwxr-x 12 recover recover 4096 7月  10 13:57 ../
lrwxrwxrwx  1 recover recover   10 7月  10 13:56 [ -> /usr/bin/[*
lrwxrwxrwx  1 recover recover   11 7月  10 13:56 ar -> /usr/bin/ar*
lrwxrwxrwx  1 recover recover   11 7月  10 13:56 as -> /usr/bin/as*
lrwxrwxrwx  1 recover recover   12 7月  10 13:56 awk -> /usr/bin/awk*
lrwxrwxrwx  1 recover recover   17 7月  10 13:56 basename -> /usr/bin/basename*
lrwxrwxrwx  1 recover recover    9 7月  10 13:56 bash -> /bin/bash*
lrwxrwxrwx  1 recover recover   10 7月  10 13:56 bzip2 -> /bin/bzip2*
lrwxrwxrwx  1 recover recover    8 7月  10 13:56 cat -> /bin/cat*
lrwxrwxrwx  1 recover recover   10 7月  10 13:56 chgrp -> /bin/chgrp*
lrwxrwxrwx  1 recover recover   10 7月  10 13:56 chmod -> /bin/chmod*
lrwxrwxrwx  1 recover recover   10 7月  10 13:56 chown -> /bin/chown*
lrwxrwxrwx  1 recover recover   16 7月  10 13:56 chrpath -> /usr/bin/chrpath*
lrwxrwxrwx  1 recover recover   12 7月  10 13:56 cmp -> /usr/bin/cmp*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 comm -> /usr/bin/comm*
lrwxrwxrwx  1 recover recover    7 7月  10 13:56 cp -> /bin/cp*
lrwxrwxrwx  1 recover recover    9 7月  10 13:56 cpio -> /bin/cpio*
lrwxrwxrwx  1 recover recover   12 7月  10 13:56 cpp -> /usr/bin/cpp*
lrwxrwxrwx  1 recover recover   12 7月  10 13:56 cut -> /usr/bin/cut*
lrwxrwxrwx  1 recover recover    9 7月  10 13:56 date -> /bin/date*
lrwxrwxrwx  1 recover recover    7 7月  10 13:56 dd -> /bin/dd*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 diff -> /usr/bin/diff*
lrwxrwxrwx  1 recover recover   17 7月  10 13:56 diffstat -> /usr/bin/diffstat*
lrwxrwxrwx  1 recover recover   16 7月  10 13:56 dirname -> /usr/bin/dirname*
lrwxrwxrwx  1 recover recover   11 7月  10 13:56 du -> /usr/bin/du*
lrwxrwxrwx  1 recover recover    9 7月  10 13:56 echo -> /bin/echo*
lrwxrwxrwx  1 recover recover   10 7月  10 13:56 egrep -> /bin/egrep*
lrwxrwxrwx  1 recover recover   12 7月  10 13:56 env -> /usr/bin/env*
lrwxrwxrwx  1 recover recover   15 7月  10 13:56 expand -> /usr/bin/expand*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 expr -> /usr/bin/expr*
lrwxrwxrwx  1 recover recover   10 7月  10 13:56 false -> /bin/false*
lrwxrwxrwx  1 recover recover   10 7月  10 13:56 fgrep -> /bin/fgrep*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 file -> /usr/bin/file*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 find -> /usr/bin/find*
lrwxrwxrwx  1 recover recover   14 7月  10 13:56 flock -> /usr/bin/flock*
lrwxrwxrwx  1 recover recover   12 7月  10 13:56 g++ -> /usr/bin/g++*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 gawk -> /usr/bin/gawk*
lrwxrwxrwx  1 recover recover   12 7月  10 13:56 gcc -> /usr/bin/gcc*
lrwxrwxrwx  1 recover recover   15 7月  10 13:56 gcc-ar -> /usr/bin/gcc-ar*
lrwxrwxrwx  1 recover recover   16 7月  10 13:56 getconf -> /usr/bin/getconf*
lrwxrwxrwx  1 recover recover   15 7月  10 13:56 getopt -> /usr/bin/getopt*
lrwxrwxrwx  1 recover recover   12 7月  10 13:56 git -> /usr/bin/git*
lrwxrwxrwx  1 recover recover   12 7月  10 13:56 gpg -> /usr/bin/gpg*
lrwxrwxrwx  1 recover recover    9 7月  10 13:56 grep -> /bin/grep*
lrwxrwxrwx  1 recover recover   11 7月  10 13:56 gunzip -> /bin/gunzip*
lrwxrwxrwx  1 recover recover    9 7月  10 13:56 gzip -> /bin/gzip*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 head -> /usr/bin/head*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 hostname -> /bin/hostname*
lrwxrwxrwx  1 recover recover   11 7月  10 13:56 id -> /usr/bin/id*
lrwxrwxrwx  1 recover recover   16 7月  10 13:56 install -> /usr/bin/install*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 join -> /usr/bin/join*
lrwxrwxrwx  1 recover recover   11 7月  10 13:56 ld -> /usr/bin/ld*
lrwxrwxrwx  1 recover recover   15 7月  10 13:56 ld.bfd -> /usr/bin/ld.bfd*
lrwxrwxrwx  1 recover recover   12 7月  10 13:56 ldd -> /usr/bin/ldd*
lrwxrwxrwx  1 recover recover   16 7月  10 13:56 ld.gold -> /usr/bin/ld.gold*
lrwxrwxrwx  1 recover recover    7 7月  10 13:56 ln -> /bin/ln*
lrwxrwxrwx  1 recover recover    7 7月  10 13:56 ls -> /bin/ls*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 make -> /usr/bin/make*
lrwxrwxrwx  1 recover recover   17 7月  10 13:56 makeinfo -> /usr/bin/makeinfo*
lrwxrwxrwx  1 recover recover   15 7月  10 13:56 md5sum -> /usr/bin/md5sum*
lrwxrwxrwx  1 recover recover   10 7月  10 13:56 mkdir -> /bin/mkdir*
lrwxrwxrwx  1 recover recover   10 7月  10 13:56 mknod -> /bin/mknod*
lrwxrwxrwx  1 recover recover   11 7月  10 13:56 mktemp -> /bin/mktemp*
lrwxrwxrwx  1 recover recover    7 7月  10 13:56 mv -> /bin/mv*
lrwxrwxrwx  1 recover recover    7 7月  10 13:56 nc -> /bin/nc*
lrwxrwxrwx  1 recover recover   11 7月  10 13:56 nl -> /usr/bin/nl*
lrwxrwxrwx  1 recover recover   11 7月  10 13:56 nm -> /usr/bin/nm*
lrwxrwxrwx  1 recover recover   16 7月  10 13:56 objcopy -> /usr/bin/objcopy*
lrwxrwxrwx  1 recover recover   16 7月  10 13:56 objdump -> /usr/bin/objdump*
lrwxrwxrwx  1 recover recover   11 7月  10 13:56 od -> /usr/bin/od*
lrwxrwxrwx  1 recover recover   14 7月  10 13:56 patch -> /usr/bin/patch*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 perl -> /usr/bin/perl*
lrwxrwxrwx  1 recover recover   16 7月  10 13:56 pod2man -> /usr/bin/pod2man*
lrwxrwxrwx  1 recover recover   11 7月  10 13:56 pr -> /usr/bin/pr*
lrwxrwxrwx  1 recover recover   15 7月  10 13:56 printf -> /usr/bin/printf*
lrwxrwxrwx  1 recover recover    8 7月  10 13:56 pwd -> /bin/pwd*
lrwxrwxrwx  1 recover recover   46 7月  10 13:56 python -> /home/recover/.pyenv/versions/3.6.4/bin/python*
lrwxrwxrwx  1 recover recover   34 7月  10 13:56 python2 -> /home/recover/.pyenv/shims/python2*
lrwxrwxrwx  1 recover recover   36 7月  10 13:56 python2.7 -> /home/recover/.pyenv/shims/python2.7*
lrwxrwxrwx  1 recover recover   47 7月  10 13:56 python3 -> /home/recover/.pyenv/versions/3.6.4/bin/python3*
lrwxrwxrwx  1 recover recover   15 7月  10 13:56 ranlib -> /usr/bin/ranlib*
lrwxrwxrwx  1 recover recover   16 7月  10 13:56 readelf -> /usr/bin/readelf*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 readlink -> /bin/readlink*
lrwxrwxrwx  1 recover recover    7 7月  10 13:56 rm -> /bin/rm*
lrwxrwxrwx  1 recover recover   10 7月  10 13:56 rmdir -> /bin/rmdir*
lrwxrwxrwx  1 recover recover   15 7月  10 13:56 rpcgen -> /usr/bin/rpcgen*
lrwxrwxrwx  1 recover recover    8 7月  10 13:56 sed -> /bin/sed*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 sftp -> /usr/bin/sftp*
lrwxrwxrwx  1 recover recover    7 7月  10 13:56 sh -> /bin/sh*
lrwxrwxrwx  1 recover recover   18 7月  10 13:56 sha256sum -> /usr/bin/sha256sum*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 size -> /usr/bin/size*
lrwxrwxrwx  1 recover recover   10 7月  10 13:56 sleep -> /bin/sleep*
lrwxrwxrwx  1 recover recover   14 7月  10 13:56 socat -> /usr/bin/socat*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 sort -> /usr/bin/sort*
lrwxrwxrwx  1 recover recover   14 7月  10 13:56 split -> /usr/bin/split*
lrwxrwxrwx  1 recover recover   12 7月  10 13:56 ssh -> /usr/bin/ssh*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 stat -> /usr/bin/stat*
lrwxrwxrwx  1 recover recover   16 7月  10 13:56 strings -> /usr/bin/strings*
lrwxrwxrwx  1 recover recover   14 7月  10 13:56 strip -> /usr/bin/strip*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 sudo -> /usr/bin/sudo*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 tail -> /usr/bin/tail*
lrwxrwxrwx  1 recover recover    8 7月  10 13:56 tar -> /bin/tar*
lrwxrwxrwx  1 recover recover   12 7月  10 13:56 tee -> /usr/bin/tee*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 test -> /usr/bin/test*
lrwxrwxrwx  1 recover recover   14 7月  10 13:56 touch -> /usr/bin/touch*
lrwxrwxrwx  1 recover recover   11 7月  10 13:56 tr -> /usr/bin/tr*
lrwxrwxrwx  1 recover recover    9 7月  10 13:56 true -> /bin/true*
lrwxrwxrwx  1 recover recover   10 7月  10 13:56 uname -> /bin/uname*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 uniq -> /usr/bin/uniq*
lrwxrwxrwx  1 recover recover   11 7月  10 13:56 wc -> /usr/bin/wc*
lrwxrwxrwx  1 recover recover   13 7月  10 13:56 wget -> /usr/bin/wget*
lrwxrwxrwx  1 recover recover   14 7月  10 13:56 which -> /usr/bin/which*
lrwxrwxrwx  1 recover recover   14 7月  10 13:56 xargs -> /usr/bin/xargs*
lrwxrwxrwx  1 recover recover   12 7月  10 13:56 yes -> /usr/bin/yes*
lrwxrwxrwx  1 recover recover    9 7月  10 13:56 zcat -> /bin/zcat*
recover@ilab:~$

[alext-mkrs]

Ok, it sort of confirms my hypothesis but in a very limited way - it only seems to pick one version all the time - but the one from pyenv at least. It starts to look to me like you'd be better off asking on the Yocto mail list as I simply have no that much time to dig into bitbake internals to see why it works like that, in addition to doing things on the Edison images themselves - sorry. I'm pretty sure it's not that complicated and something like grepping for "hosttools" and reverse-engineering the way it constructs that dir could be even fun, but I have to carefully pick things to work on :)

And just to make it clear - it's not the meta-intel-edison or any of our other layers that does that stuff, it just some peculiar interaction between pyenv and bitbake that it as you can see doesn't pick the python version you set as default in pyenv, even though in the shell it works ok and the bitbake itself even reacts when you set 3.x as the default.

[lybtongji]

@alext-mkrs OK. It doesn't matter to me. I could overwrite the hosttools symlink manually. Thanks for your work very much! ^_^

[alext-mkrs]

My pleasure :)