arm-none-eabi-gdb and Python 3.8 issue

In this post, I’m going to show, how to fix an issue with arm-none-eabi-gdb from ARM GNU Toolchain, and old Python 3.8 or Python 3.6 dependencies

Not a long time ago, I’ve updated my home computer with fresh Xubintu 24.04 LTS, so I need to reinstall/resetup my develop enviroment for STM32

If you had an experience with installation of ARM GNU Toolchain on Linux, I guess you also had a painfull experience with ancient and non-working installation instruction for Linux provided by ARM. In general, installtion procedure is quite simple: just unpack an archive, than add «bin» directory into PATH variable.

But! The main issue is a GDB binary with python-based TUI (terminal user interface). It is linked with the old Python 3.8 library, and legacy (plus removed in fresh distros) libncurses5 library.

On the previous Xubuntu 22.04, I’ve used a solution with a custom repository, but for the current Xubintu 24.04 Python 3.8 doesn’t exist, and libncurses5 package has been removed from repositories. How can we solve this problem?

After a litte search, I’ve found a suitable solution on StackOverflow. Just build your own GDB with actual Python for you system! It is quite simple!

I’ve checked this instruction, and did a small change in the tutorial: replaced final «make install» command on a deb-file generation, because simple «make install» just copies compiled binary and other files into your system directories without any control. Please, DON’T DO IT on modern repository-based Linux systems! All software MUST BE installed using a system package manger.

OK. Let’s installation begin! I’m going to do all my action in «/storage/Temp» directory.

Part I. GDB compilation

At first, let’s install all required packages for a compilation

Then, fetch fresh sources for GDB

Unpack it

Create a directory for compilation

And the directories for a future package’s tree

Move to the build directory

And run pre-configuration. Please mention «—prefix» option. It points on our «package’s tree» dir

Run compilation process

And finally, make an «installation»

Well, let’s check what we have in our installation dir

Great! We have «arm-none-eabi-gdb» binary. But we have to check, which kind of libraries linked to our binary.

Success! Our custom GDB binary linked with the fresh system Python, and libncurses libraries! Save this command output, it will be usefull for future steps.

Part II. Build custom «deb» package file

Now we can build our custom «deb» package for the installation.

Add follwing text into «control» file

Also, I have to mention, how to collect a list of packages for the «Depends» option. Look at the output of «ldd» command. It contains list of required shared libraries. Just get the library name from the output (for example, I will use «libexpat»), and find similar in the installed packages.

OK, we have «libexpat1» and «libexpat1-dev». The second is just for compilation from sources, and not needed for the our binary package. Re-check our choice, by listing all files, related to the «libexpat1» package. Yes, it includes /usr/lib/x86_64-linux-gnu/libexpat.so.1 file, so we can add «libexpat1» into «Depends» section.

Right now we have a «package installation tree» in «/storage/Temp/arm-none-eabi-gdb» directory. And on this step, better to check, have we intersections with already installed files in our system, or not. Our package tree has «gdb» directory in /storage/Temp/arm-none-eabi-gdb/usr/share/. And it contains something.

But our current system directory also has same directory and files in /usr/share/!

Unfortunallty, I don’t know, how package mainteiner have to resolve similar issues. I’ve removed confilcting directories and files form «package installation tree»

Well, it is time to build the package. Move to the top directory

And build the package

Recheck what the package contains

Now, we can install it using dpkg

Check it