I have nowhere an issue not using python v2.7 with GDB

Same problem in Ubuntu 24.04.

I would really appreciate if this could be fixed soon. This ancient version of python2 - support for Python 2 ended Jan. 1, 2020 see announcement on python.org - may be a security risk.

What is the exact issue? What command is not working without Python2?

ldd xtensa-esp32-elf-gdb
        linux-vdso.so.1 (0x00007ffc70f64000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f4d1d2f2000)
        **libpython2.7.so.1.0** => /usr/lib64/libpython2.7.so.1.0 (0x00007f4d1d0a7000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4d1d083000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f4d1d07f000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f4d1cf33000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f4d1ccec000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4d1ccc8000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f4d1cad1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4d1d339000)

gdb is linked dynamically against V2 of libpython. Several distros do no longer offer V2 - so you have either to install it manuallly - as I did longer ago (and forgot that fact until today 😉) - or you get an error message due to the missing lib.

I saw in the meantime that @valeros has upgraded the python version in CI to 3.9 - so I am little bit optimistic
that the next release fixes this isuue

Ahh, you are using the old version

Not voluntary 😆

I am using the latest PlatformIO (6.1.15) and have the same issue.

The Python 2 library that is no longer available in Ubuntu 24.04.

It's even worse - xtensa-esp32s3-elf-gdb shows unsurprisingly the same behaviour

ldd ~/.platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-gdb
       linux-vdso.so.1 (0x00007ffefe7e5000)
       libdl.so.2 => /lib64/libdl.so.2 (0x00007fe6980f4000)
       libpython2.7.so.1.0 => not found
       libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe6980f1000)
       libutil.so.1 => /lib64/libutil.so.1 (0x00007fe6980ec000)
       libm.so.6 => /lib64/libm.so.6 (0x00007fe698002000)
       libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fe697c00000)
       libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe697fde000)
       libc.so.6 => /lib64/libc.so.6 (0x00007fe697800000)
       /lib64/ld-linux-x86-64.so.2 (0x00007fe698123000)

But if I install the missed library manually (and nothing else from python2.7) the linkage error disappears but instead a - at a first glance - strange python error occurs

`
piodebuggdb -e esp32S3
Open On-Chip Debugger v0.11.0-esp32-20220706 (2022-07-06-15:48)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
Info : esp_usb_jtag: VID set to 0x303a and PID to 0x1001
Info : esp_usb_jtag: capabilities descriptor set to 0x2000
adapter speed: 40000 kHz

Warn : Transport "jtag" was already selected
adapter speed: 5000 kHz

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : esp_usb_jtag: serial (24:58:7C:CD:A6:48)
Info : esp_usb_jtag: Device found. Base speed 40000KHz, div range 1 to 255
Info : clock speed 5000 kHz
Info : JTAG tap: esp32s3.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32s3.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : starting gdb server for esp32s3.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
Could not find platform independent libraries
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to [:<exec_prefix>]
ImportError: No module named site

`

This is IMHO due to missing support of python2.7 on my system.

I was able to reproduce this behavior under 3 different distributions/installations

• openSUSE Leap 15.6 (using python3.6)
• openSUSE Tumbleweed (using python3.11)
• debian 12 (using python3.11)

For those who are waiting like me for a solution of this issue - in the meantime I've found a workaround described here - nevertheless it would be REALLY fine, if the support for PYTHON3 would be pushed forward ...