Can't launch project because of libncurses dependency

[KelvinNovais]

While trying to launch a project, I get the following error:

'Launching <Project Name>' has encountered a problem.
Could not determine GDB version using command: arm-none-eabi-gdb --version

Could not determine GDB version using command: arm-none-eabi-gdb --version
arm-none-eabi-gdb: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory

OS: Fedora Linux 42

STM32CubeIDE version: 1.19.0

Although libncurses.so.5 is apparently a very old package, I have "ncurses-compat-libs", which should provide compatibility with the required package version. I can find it on /usr/lib/ but not on /usr/lib64/.

[Ghofrane GSOURI]

Hello @KelvinNovais

It seems you are using the generic installer(amd64.sh) which don't install required libraries.

So, let's try to uninstall STM32CubeIDE 1.19.0 and then install it  using deb_bundle installer, it should install automatically all needed libraries including libncurses5.

Please try this solution, and let me know your feedback. I’ll be waiting to hear from you.

THX

Ghofrane

[KelvinNovais]

It seems you are using the generic installer(amd64.sh) which don't install required libraries.

Actually no, I installed it using the rpm_bundle installer

So, let's try to uninstall STM32CubeIDE 1.19.0 and then install it  using deb_bundle installer

The deb installer won't work on Fedora. Even so, I tried; but as expected, it was unsuccessful because it tries to call dpkg instead of rpm.

So I removed all CubeIDE related installations and reinstalled the IDE using the rpm package, but the problem persists.

[Pavel A.]

Someone with knowledge in Linux distros should look at this and decide what to do: rebuild gdb without dependency on libncurses or provide libncurses.so.5 in a robust way that does not fail.

[Pavel A.]

Someone with knowledge in Linux distros should look at this and decide what to do: rebuild gdb without dependency on libncurses, or provide libncurses.so.5 in a robust way that doesn't fail.

[AScha.3]

Problem is not new...search forum , if you like to do.

+

no...its not a problem in Linux, its just still same build system (gdb).

But its known "problem" , will (should) be cleared with next IDE update.

STM32CubeIDE 2.0  , Nov 2025 .

So wait - or install gdb-multiarch:

+

Try install multiarch...see my post:

https://community.st.com/t5/stm32cubeide-mcus/quot-could-not-determine-gdb-version-quot-in-stm32cubeide-on/m-p/761200/highlight/true#M33524

[JohannesK]

---

@KelvinNovais wrote:

[...]

Although libncurses.so.5 is apparently a very old package, I have "ncurses-compat-libs", which should provide compatibility with the required package version. I can find it on /usr/lib/ but not on /usr/lib64/.

---

That's interesting that the ncurses v5 libraries appears in /usr/lib instead of /usr/lib64, because your posted link says they should be installed under /usr/lib64. I don't use Fedora currently but are there two variants form ncurses-compat-libs (32 Bit and 64 Bit)?

The current build from gdb in the STM32CubeIDE v1.19.0 also requires the also old library libtinfo.so.5.

Here the output on a Debian 13 system (with installed old ncurses libraries from Debian 12) which library dependencies are required:

$ cd /opt/st/stm32cubeide_1.19.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-
stm32.13.3.rel1.linux64_1.0.0.202410170706/tools/bin

$ ldd arm-none-eabi-gdb
       linux-vdso.so.1 (0x00007fb612517000)
       libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 (0x00007fb6124bc000)
       libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fb61248b000)
       libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb612486000)
       libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb611400000)
       libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb612394000)
       libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb612367000)
       libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb612362000)
       libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb61120a000)
       /lib64/ld-linux-x86-64.so.2 (0x00007fb612519000)

It's might not a clean solution (it's a quick and dirty workaround), but have you tried to create symbolic links in /usr/lib64 to the libraries libncurses.so.5 and libtinfo.so.5 with the command line utility ln and restart your system or use ldconfig...

$ cd /usr/lib64
$ ln -s /usr/lib/libncurses.so.5 libncurses.so.5
$ ln -s /usr/lib/libtinfo.so.5 libtinfo.so.5
$ ldconfig

...if these are real 64 Bit libraries on your system?

$ cd /usr/lib
$ file libncurses.so.5.9
libncurses.so.5.9: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=18d3c7f46cc7de831ba6ec8b95f755c0aaa75227, stripped

 It's really not a clean solution but it should work meanwhile.

[JohannesK]

---

@Pavel A. wrote:

[...] rebuild gdb without dependency on libncurses, [...]

---

I think this isn't possible without losing the TUI (text user interface) from gdb. The current build configuration files (from the current branch) checks first if there are is the wchar_t version form ncurses installed on the host system, if not it uses the normal version according the configuration files. If both versions are not installed the build from the TUI will be discarded.

Primarily I build the toolchains for my own on my machine. And the good thing, they the don't link against the old version 5 from ncurses. Version 5 is not required for gdb.

$ arm-none-eabi-gdb --version
GNU gdb (GDB) 16.3
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ ldd `which arm-none-eabi-gdb`
        linux-vdso.so.1 (0x00007f649998c000)
        libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x00007f6498f97000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f6498f61000)
        libpython3.13.so.1.0 => /lib/x86_64-linux-gnu/libpython3.13.so.1.0 (0x00007f6498600000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f6498f35000)
        libmpfr.so.6 => /cross/gnu/202508/lib/libmpfr.so.6 (0x00007f6498e7c000)
        libgmp.so.10 => /cross/gnu/202508/lib/libgmp.so.10 (0x00007f6498e00000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6498200000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6498510000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6498dd3000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f649800a000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6499964000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f649998e000)

[ross8888]

Hey Kelvin!
This error usually pops up because Fedora 42 doesn’t include libncurses.so.5 by default anymore. The good news is it’s an easy fix — just install the compatibility package by running sudo dnf install ncurses-compat-libs in your terminal. Once that’s done, restart STM32CubeIDE and your project should launch without the GDB error.

[Pavel A.]

@JohannesK 

> I think this isn't possible without losing the TUI (text user interface) from gdb.

When the gdb runs inside the Eclipse debugger, the TUI isn't useful?  Just basic line input/output in the terminal window?