ModuleNotFoundError: No module named 'elftools'

[shehamb]

Hello, I am trying to build sample application on for mimxrt1064_evk on windows 10. I seem to have installed everything, but i still get this error: C:\Users\mbajaj\zephyrproject\zephyr>west build -p auto -b mimxrt1064_evk samples/hello_world [1/130] Generating include/generated/kobj-types-enum.h, include/generated/otype-to-str.h, include/generated/otype-to-size.h FAILED: zephyr/include/generated/kobj-types-enum.h zephyr/include/generated/otype-to-str.h zephyr/include/generated/otype-to-size.h cmd.exe /C "cd /D C:\Users\mbajaj\zephyrproject\zephyr\build\zephyr && C:\Python36\python.exe C:/Users/mbajaj/zephyrproject/zephyr/scripts/gen_kobject_list.py --kobj-types-output C:/Users/mbajaj/zephyrproject/zephyr/build/zephyr/include/generated/kobj-types-enum.h --kobj-otype-output C:/Users/mbajaj/zephyrproject/zephyr/build/zephyr/include/generated/otype-to-str.h --kobj-size-output C:/Users/mbajaj/zephyrproject/zephyr/build/zephyr/include/generated/otype-to-size.h --include C:/Users/mbajaj/zephyrproject/zephyr/build/zephyr/misc/generated/struct_tags.json " Traceback (most recent call last): File "C:/Users/mbajaj/zephyrproject/zephyr/scripts/gen_kobject_list.py", line 62, in import elftools ModuleNotFoundError: No module named 'elftools' [2/130] Generating include/generated/driver-validation.h FAILED: zephyr/include/generated/driver-validation.h cmd.exe /C "cd /D C:\Users\mbajaj\zephyrproject\zephyr\build\zephyr && C:\Python36\python.exe C:/Users/mbajaj/zephyrproject/zephyr/scripts/gen_kobject_list.py --validation-output C:/Users/mbajaj/zephyrproject/zephyr/build/zephyr/include/generated/driver-validation.h --include C:/Users/mbajaj/zephyrproject/zephyr/build/zephyr/misc/generated/struct_tags.json " Traceback (most recent call last): File "C:/Users/mbajaj/zephyrproject/zephyr/scripts/gen_kobject_list.py", line 62, in import elftools ModuleNotFoundError: No module named 'elftools' ninja: build stopped: subcommand failed. FATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' --build 'C:\Users\mbajaj\zephyrproject\zephyr\build'

And elftools is installed as verified by:

pip show pyelftools Name: pyelftools Version: 0.27 Summary: Library for analyzing ELF files and DWARF debugging information Home-page: https://github.com/eliben/pyelftools Author: Eli Bendersky Author-email: eliben@gmail.com License: Public domain Location: c:\python39\lib\site-packages Requires: Required-by: pyocd

[shehamb]

Any inputs on this???

[dcpleung]

It looks like pyelftools is installed under Python 3.9, but your build system is running Python 3.6. Not sure how to force cmake to use Python 3.9, but maybe you can install pyelftools under 3.6 (by invoking pip via 3.6)?

[shehamb]

Hello Daniel,

Thank you for your email. Issue was, west was installed under 3.6, hence it was looking for libraries under 3.6. elftools was first to get searched, hence that error. Uninstalling all different versions of Python and starting from scratch resolved this issue. But i do wonder, why west gets installed in python3.6? Shouldn't it get installed wherever other python is installed through choco?

Regards, Mahesh.

On Thu, May 13, 2021 at 2:29 AM Daniel Leung @.***> wrote:

It looks like pyelftools is installed under Python 3.9, but your build system is running Python 3.6. Not sure how to force cmake to use Python 3.9, but maybe you can install pyelftools under 3.6 (by invoking pip via 3.6)?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zephyrproject-rtos/zephyr/issues/34913#issuecomment-840092536, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOHJYGGJ6EILYT44SKVCKXTTNLT2RANCNFSM44GY3S6A .

[dcpleung]

It's probably because your Python 3.6 installation is earlier in your PATH so it is being used first.

[doctorseus]

Actually the issue here is in cmake/python.cmake. When using a virtualenv/choco the foreach logic introduced with commit 94de3e9f60dca188cae407ab70c5a2a991fa78df tries to be too restrictive and will suggest the system python to PYTHON_EXACT instead of the active python3 on the path.

I think the whole logic should be removed again to not break proper system behavior. The commit says a higher version of python would be a problem? If this is really the case (which I don't think it is) some logic using find_package with EXACT instead should be considered. @tejlmand

[tejlmand]

When using a virtualenv/choco the foreach logic introduced with commit 94de3e9 tries to be too restrictive and will suggest the system python to PYTHON_EXACT instead of the active python3 on the path.

Several people are using venv / pyvenv, and it is suppose to be picking up the python from within there. But be aware that if you are using west build, then the Python used to invoke west will be passed on to CMake.

Could that be the reason for your observation ?

I think the whole logic should be removed again to not break proper system behavior.

If you do that, then you end up with the result that the find_package(Python3 ...) will behave wrongly, just look at: https://github.com/zephyrproject-rtos/zephyr/issues/24340

also take a look here https://github.com/zephyrproject-rtos/zephyr/issues/24692#issue-606566863, especially this explanation:

The FindPythonInterp was deprecated with CMake 3.12, and as there were other issues related to Python location that had to be solved, then it was decided to go for the new FindPython3 CMake module, but as you noticed, it has introduced a new behavior, with some unexpected side-effects.

For a quick test, you can try to set the Windows search Python3_FIND_REGISTRY value to LAST. https://cmake.org/cmake/help/latest/module/FindPython3.html#hints

but you are also welcome to wait till I have investigated on Windows.

On Windows, CMake FindPython3 will default look into Windows registry, so you can take a look to see if all Python versions > > installed are correctly registered: [HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore\ or [HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\

_

The commit says a higher version of python would be a problem?

No, the commit says that not selecting the Python3 in path will be wrong if that Python3 meets the minimal requirement. So if you have:

c:\python36\python
c:\python37\python
c:\python38\python

and first in path is c:\python36\python then the logic you suggest to remove is actually ensuring that Python3.6 is used, and not Python3.8 (if 3.8 was first in path, then that version is of course selected).

Now, in the case reported here:

Issue was, west was installed under 3.6, hence it was looking for libraries under 3.6. elftools was first to get searched, hence that error.

@shehamb is using west for building, and west build will pass on the used Python version, so that the SAME python is used for both west and the build system.

If @shehamb was calling cmake directly, then the Python3 in path would be preferred. If Python3.9 is first in path then that would be used, and based on I It looks like pyelftools is installed under Python 3.9 I assume that @shehamb is actually having Python3.9 first in path, but have installed west under Python3.6.

Now, to request a specific Python version to be used, then it's possible to use PYTHON_PREFER.

west build ..... -- -DPYTHON_PREFER=C:/Python39/python.exe

[github-actions[bot]]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.