• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Answers 2 answers
  • Subscribers 27 subscribers
  • Views 16773 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

gcc-arm-11.2-2022.02-x86_64-arm-none-eabi gdb FAILS on ubuntu

Bas Prins

Hi,

I downloaded gcc-arm-11.2-2022.02-x86_64-arm-none-eabi.tar.xz from https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/downloads.

Unpacked the tar into my home folder. When I then run

```

p@bp-legion:~/Downloads/gcc-arm-11.2-2022.02-x86_64-arm-none-eabi/bin$ ./arm-none-eabi-gdb --version
./arm-none-eabi-gdb: error while loading shared libraries: libpython3.6m.so.1.0: cannot open shared object file: No such file or directory

```

I got this AFTER being forced to `ln`

- /usr/lib/x86_64-linux-gnu/libncursesw.so.6

- /usr/lib/x86_64-linux-gnu/libtinfo.so.6

I didn't graduate on linux, did I miss "the easy way" to get the arm toolchain working on my ubuntu installation?

I can't imagine that I am the first to install the arm toolchain on a fresh installed ubuntu 22.04 environment......

Parents
  • 0 in reply to vvinayag

    Remember that every distribution has its policy about what Python version to install as their system-wide default. For example, for Debian 11 (stable), the current version is Python 3.9, not 3.8, as required by arm-toolchain release 11.3 or Python 3.6 of release 11.2. Any Python version you choose to release your executables would be equally arbitrary and conflicting unless you target a particular Linux distribution/version.

    I believe doing another duplicated, complete Python installation to use gdb when someone does not need Python support in gdb makes no sense. Therefore, looking forward, I think the best solution is:

    1) Two executables, arm-none-gdb and arm-none-gdb-py, as in arm-toolchain release 10.
    2) Statically linked Python on gdb-py, whatever version you choose.

    Currently, the only way to use the arm-toolchain without worrying about Python versions and embarking on tedious workarounds is to use arm-none-gdb (without Pyhton support) in arm-toolchain release 10.

    For the typical end user, it may be more convenient to check their Linux distribution for the package "gcc-arm-none-eabi". For example, Debian testing and Ubuntu 22 already have arm-toolchian release 10 in its package managers.

Reply
  • 0 in reply to vvinayag

    Remember that every distribution has its policy about what Python version to install as their system-wide default. For example, for Debian 11 (stable), the current version is Python 3.9, not 3.8, as required by arm-toolchain release 11.3 or Python 3.6 of release 11.2. Any Python version you choose to release your executables would be equally arbitrary and conflicting unless you target a particular Linux distribution/version.

    I believe doing another duplicated, complete Python installation to use gdb when someone does not need Python support in gdb makes no sense. Therefore, looking forward, I think the best solution is:

    1) Two executables, arm-none-gdb and arm-none-gdb-py, as in arm-toolchain release 10.
    2) Statically linked Python on gdb-py, whatever version you choose.

    Currently, the only way to use the arm-toolchain without worrying about Python versions and embarking on tedious workarounds is to use arm-none-gdb (without Pyhton support) in arm-toolchain release 10.

    For the typical end user, it may be more convenient to check their Linux distribution for the package "gcc-arm-none-eabi". For example, Debian testing and Ubuntu 22 already have arm-toolchian release 10 in its package managers.

Children
No data