Hi,
i've installed the current version of the arm-none-eabi toolchain (11.2 2022.02) for Windows and i'm wondering why is there a mandatory dependency to the "Python DLL dependencies" for GDB usage which indeed uses Python 2.7.4?
As far as i know Python2 is deprecated and it is recommended to switch to Python3 for current releases since April 2020. On the other hand for Linux hosts there is at least a dependency against Python3.6.
With the previous arm-none-eabi toolchain version 2021.10 there is no such dependency.
Kind regards,
Christian
Hi Christian,we face the same issue within our project, do you have a workaround in place for the issue?Best regards,Jochen
Hi Jochen,
currently we're using the 2021.10 GDB instead of the 2022.02 GDB which is quite uncomfortable due to the fact having 2 toolchains mixed up. But we do not want to install Python2 just for GDB. In addition to this we tried to use the toolchain via WSL & Ubuntu which uses then Python3 but this adds additional configuration overhead.
Best regards,
Same issue here. Even after installing Python 2.7 and adding it to the path, it still can run GBD.
Hello,
Arm GNU Toolchain version 10.3-2021.10 provided arm-none-eabi-gdb with python support and arm-none-eabi-gdb without python support.
Arm GNU Toolchain version 11.2-2022.02 only provides arm-none-eabi-gdb with python support. However, the python packages are not provided (similar to previous releases). Therefore, using GDB requires a working installation of Python. For the Windows based toolchains, this requires installing Python 2.7 (for 32-bit).
The Python2 EOL is a known limitation and this is being considered as part of future releases.
Hi Christian,
When you say that you do not want to install Python2 just for GDB, could you please clarify whether you mean you don't want to install any version of Python, or do you mean you that don't want to install Python2 specifically?
Kind regards
Considering all the above and the fact that there is already a version that does not require Python I would suggest going forward, release only the version that doesn't depend on Python at all. Seems the most logical choice...
since we're using Python also for other parts of our daily work, Python installs in general are absolutely okay.
But we're avoiding Python2 due to its EOL and related security issues.