the selected build of GDB does not support Python scripting. it cannot be used in qt creator.

[mumin16]

the selected build of GDB does not support Python scripting. it cannot be used in qt creator.

[mumin16]

in clion:

Error during pretty printers setup: Undefined info command: "pretty-printer". Try "help info".

[brechtsanders]

I see now that GDB was built without python (and also without tcl and tk). I will try to build with them. Right now I'm compiling the new GCC 9.3, so I will see if I can get this sorted for GDB for the next winlibs personal build release.

[brechtsanders]

I just tried with GDB included built with --with-python. It now also contains a file pretty_printers.py, but I'm not sure if the path in the package should be: mingw64/share/gdb/share/gdb/python/gdb/command/pretty_printers.py or: mingw64/share/gdb/python/gdb/command/pretty_printers.py Do you know this?

Also, if I make a release with this gdb will be broken for the users that download it as it will fail to start because the Python DLL file is missing, and I don't intend to distribute an entire Python in the package.

[anb0s]

The second one mingw64/share/gdb/python/gdb/command/pretty_printers.py should be the right path.

[anb0s]

Also, if I make a release with this gdb will be broken for the users that download it as it will fail to start because the Python DLL file is missing, and I don't intend to distribute an entire Python in the package.

You can use the Embedded Python and copy only the python38.dll and python38.zip from the zip file to /bin. This is not that big ~6 MB.

I did it manually for my own GDB build and it worked. I do not know if a patch was needed, as i have no access to my PC...

[brechtsanders]

The concept behind winlibs is that every dependancy is built from source. That way everything is built with the same compiler and linked with the same standard C/C++ libraries. So far I haven't build Python from source yet, but maybe I should give it another try.

[anb0s]

As you mentioned the Python DLL is missing and must be copied by user:

[anb0s]

After adding python.dll etc. GDB starts, but it misses the files, looks like path d:\r\winlibs64-9.3.0-7.0.0\inst_gdb-9.1\share\gdb\share\gdb/python is hardcoded?

d:\git\s7p\work2\s7p.tools\win64_gcc_mingw64_9.3.0\bin>gdb
Python Exception <class 'ModuleNotFoundError'> No module named 'gdb':
d:\git\s7p\work2\s7p.tools\win64_gcc_mingw64_9.3.0\bin\gdb.exe: warning:
Could not load the Python gdb module from `d:\r\winlibs64-9.3.0-7.0.0\inst_gdb-9.1\share\gdb\share\gdb/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.
GNU gdb (GDB for MinGW-W64 x86_64, built by Brecht Sanders) 9.1
Copyright (C) 2020 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.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb)

[anb0s]

It also be good if it can be compiled with Python 3.7 (python3.7.dll) or 3.8 (python3.8.dll)...

[brechtsanders]

I haven't tested this at all. It is very well possible that compiling this in uses absolute paths. For now I will not put any more effort in this as Python or CPython won't build yet in my environment, and the main focus of winlibs is compiled languages like C and C++ and the goal is to build every component in the same environment.

Once I get CPython to compile I may reavaluate. Currently I got 3.8.2 to compile, but linking fails with some undefined references.

[anb0s]

Thank You for the effort! If you have a new version i would be happy to test it :)

[nenin-sc]

Any news about python support?

[Trass3r]

I wonder why they require python support in QtCreator in the first place.

[krsch]

Is it possible to help with this issue? I can find no build or packaging scripts so I don't know how to experiment with solving this issue.

[guyutongxue]

Is it possible to help with this issue? I can find no build or packaging scripts so I don't know how to experiment with solving this issue.

https://github.com/niXman/mingw-builds This repo provides build scripts with Python support. I've tried these scripts, and built MinGW with GCC 10.2.0 successfully.

[longnguyen2004]

@brechtsanders I'm currently in the process of adding Python support to the llvm-mingw toolchain. If you wanna add support for Python in your toolchain, check out the MSYS2 patchset for python3. It should allow you to build Python from source. Just apply all the patches, run autoreconf -fi and configure like usual. Have a look at the PKGBUILD file in the patchset for the configure options.

[emiro85]

Any update on this issue? I would love to move from MinGW builds to your package, but missing Python support is a blocker.

[brechtsanders]

Still unable to build python/cpython in my environment :-(

I need to find time to go through the patches in the links you sent...

[longnguyen2004]

You can have a look at our Python build script here In short, we basically build a native cpython, then we build libffi and cpython for mingw-w64, using the patchset from MSYS2. After that, we removed a few stuff to reduce the size of the package (namely the test module and the bytecode cache). As we don't build gdb, I don't know what flags are required for Python support in gdb, but I think you can figure it out.

[hamidb80]

try to use this version of minGW https://nim-lang.org/install_windows.html

[brechtsanders]

@hamidb80 What do you mean exactly? https://winlibs.com/ provides a standalone build of the latest MinGW-w64 version (currently 9.0.0). The download on the link you mention seems to be an older winlibs release (MinGW-w64 8.0.2).

[hamidb80]

@hamidb80 What do you mean exactly? https://winlibs.com/ provides a standalone build of the latest MinGW-w64 version (currently 9.0.0). The download on the link you mention seems to be an older winlibs release (MinGW-w64 8.0.2).

it supports GDB scripting [I think that's what you wanted, right? ]

it has pretty printing, ... - it meets my needs, maybe it fit for you also

[brechtsanders]

@hamidb80 No, this question is specifically about Python support in GDB. Since the https://nim-lang.org/install_windows.html is an earlier download from https://winlibs.com/ that was renamed, it doesn't have this either.

[hamidb80]

@hamidb80 No, this question is specifically about Python support in GDB. Since the https://nim-lang.org/install_windows.html is an earlier download from https://winlibs.com/ that was renamed, it doesn't have this either.

They have a debugger that is based on gdb scripting with python

[xtemp09]

Guyutongxue made a perfect bundle with a complete mingw-w64 toolchain. It works perfectly with Qt Creator.

[xtemp09]

Any news on python support? LLVM 12.0.1 has been released.

Using your toolchain, I compiled clang with default targetting libc++ instead of libstdc++, using Win32 threads instead of pthreads and libc++abi instead of libgcc_s (the compilation process contains a flaw, libc++abi prefers pthreads, it needs to be set off explicitly).

With Guyutongxue's bundle I made clangless gcc and gccless clang (clang defaults to compiler-rt).

[xtemp09]

Any news on python support?

[brechtsanders]

I have been trying to build the latest Python earlier this week, and while compiling works there are still some missing symbols when linking. I will only include Python support if I get Python to build with the same build tools.

[xtemp09]

Will python scripting in gdb & lldb be implemented before New Year's day?

[brechtsanders]

No. Python still won't build due the winlibs way. But from time to time I try to get it to build (last time was last week when Python 3.11.0a1 came out).

[longnguyen2004]

Don't use 3.10.0 or above, the MSYS2 team only supports up to 3.9.7 (3.10.0 is ongoing). Use the pre-patched Python from https://github.com/msys2-contrib/cpython-mingw to build for mingw. Also, you can publish the build script and other people may try to add Python support in.

[brechtsanders]

@longnguyen2004 Thanks for the tip. Unfortunately the cpython-mingw sources won't build out of the box either and there is no documentation about how to build it :-(

[longnguyen2004]

Here's what I do for building Python: Assuming $PREFIX is the build prefix, $PREFIX_NATIVE is the prefix for native tools (if cross-compiling), $HOST is the host for the build

1. Cloning libffi and python:

   
   git clone https://github.com/libffi/libffi -b v3.4.2
   git clone https://github.com/python/cpython -b v3.9.7 # If cross-compiling
   git clone https://github.com/msys2-contrib/cpython-mingw -b mingw-v3.9.7
   # This is a branch, not a tag. For reproducibility, use a commit hash here

cd libffi && autoreconf -vfi && cd .. cd cpython-mingw && autoreconf -vfi && cd ..

2. (if cross-compiling) Build native libffi and cpython
```sh
cd libffi
mkdir build-native && cd build-native
../configure --prefix="$PREFIX_NATIVE" --disable-symvers --disable-docs
make install -j8

cd ../../cpython
mkdir build-native && cd build-native
../configure --prefix="$PREFIX_NATIVE" --without-ensurepip --with-system-ffi \
    CFLAGS="-I$PREFIX_NATIVE/include"   \
    CXXFLAGS="-I$PREFIX_NATIVE/include" \
    LDFLAGS="-L$PREFIX_NATIVE/lib"
make install -j8

cd ../..
# You can reuse this native build as long as the native version matches the cross version

3. Build mingw libffi and cpython

   
   export PATH="$PREFIX_NATIVE/bin:$PATH" # If cross-compiling

cd libffi mkdir build-$HOST && cd build-$HOST ../configure --prefix="$PREFIX" --host=$HOST --disable-symvers --disable-docs make install -j8

cd ../../cpython-mingw mkdir build-$HOST && cd build-$HOST BUILD=$(../config.guess) export CC=$HOST-gcc # $HOST-clang export CXX=$HOST-g++ # $HOST-clang++ ../configure --prefix="$PREFIX" --build=$BUILD --host=$HOST \ CFLAGS="-I$PREFIX/include" CXXFLAGS="-I$PREFIX/include" LDFLAGS="-L$PREFIX/lib" \ --enable-shared \ --with-system-ffi \ --without-ensurepip \ --without-c-locale-coercion make install -j8

Then build gdb with `--with-python="$PREFIX"`

[brechtsanders]

Doesn't work out of the box. First error I get is:

Python/dynload_shlib.c:87:34: error: implicit declaration of function 'dlsym' [-Werror=implicit-function-declaration]

This can be fixed by doing:

cp -f Python/dynload_win.c Python/dynload_shlib.c

But then the next error is:

Python/initconfig.c:1517:28: error: implicit declaration of function 'nl_langinfo'

which is another typical portability issue. All this gives me doubts on how this was modified to work for MinGW...

[longnguyen2004]

Are you cross-compiling or not? Also, please give me the command invocation and the stdout.

[brechtsanders]

Native build on Windows in MSYS2 shell but using winlibs compiler and all prerequisites already compiled from source in the same environment.

I just noticed I was building 3.9.5 as that was the last tag visible in https://github.com/msys2-contrib/cpython-mingw/tags and since my build scripts use tarballs instead of git clones.

When trying 3.9.7 with:

autoreconf -vfi &&
mkdir -p build_win &&
cd build_win &&
../configure --prefix=$INSTALLPREFIX --build=$BUILDPLATFORM --host=$RUNPLATFORM --enable-shared --enable-optimizations --enable-loadable-sqlite-extensions --disable-ipv6 --with-system-expat --with-system-ffi --with-system-libmpdec --without-ensurepip --without-c-locale-coercion --enable-loadable-sqlite-extensions --with-ssl-default-suites=openssl &&
make

it works. But make install still has issues.

[brechtsanders]

I figured stuff out now.

It's till a mystery to me why the tarballs on https://github.com/msys2-contrib/cpython-mingw/tags don't work and why 3.9.7 isn't even listed in there.

Anyway, it looks like you will still get gdb and lldb with python before X-mas.

But I'm not sure it's functional though.

And when I just run lldb I get:

PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.      Program arguments: D:\\Prog\\winlibs64-11.2.0ucrt\\custombuilt\\share\\llvm\\bin\\lldb.exe
#0 0x00007ffbee0e0000
#1 0x00007ffc4e7c71e9 LLDBSWIGPython_GetValueObjectSPFromSBValue(void*) (D:\Prog\winlibs64-11.2.0ucrt\custombuilt\share\llvm\bin\liblldb.dll+0x3771e9)
#2 0x00007ffc4e7c3d61 LLDBSWIGPython_GetValueObjectSPFromSBValue(void*) (D:\Prog\winlibs64-11.2.0ucrt\custombuilt\share\llvm\bin\liblldb.dll+0x373d61)
#3 0x00007ffc4e96bb21 lldb::SBDebugger::InitializeWithErrorHandling() (D:\Prog\winlibs64-11.2.0ucrt\custombuilt\share\llvm\bin\liblldb.dll+0x51bb21)
#4 0x00007ff77b19c11f (D:\Prog\winlibs64-11.2.0ucrt\custombuilt\share\llvm\bin\lldb.exe+0xc11f)
#5 0x00007ff77b191445 (D:\Prog\winlibs64-11.2.0ucrt\custombuilt\share\llvm\bin\lldb.exe+0x1445)
#6 0x00007ff77b191146 (D:\Prog\winlibs64-11.2.0ucrt\custombuilt\share\llvm\bin\lldb.exe+0x1146)
#7 0x00007ffc848454e0 (C:\WINDOWS\System32\KERNEL32.DLL+0x154e0)
#8 0x00007ffc85d8485b (C:\WINDOWS\SYSTEM32\ntdll.dll+0x485b)
Segmentation fault

gdb starts when PYTHONHOME is set.

Is there a minimal case for testing (I myself have never debugged Python like that)?

[emiro85]

Thats awesome news. Its not about debugging Python, but using Python scripts to enhance the gdb debugging experience. The Qt project and its IDE QtCreator are using it heavily. Hence, if you want to debug using QtCreator, gdb needs to be built with Python support. A minimal test case would be to install QtCreator, create a simple C++ application, compile and try to debug it through QtCreator.

[longnguyen2004]

It's till a mystery to me why the tarballs on https://github.com/msys2-contrib/cpython-mingw/tags don't work and why 3.9.7 isn't even listed in there.

Because the tags are from the upstream repo. The MSYS2 team doesn't create tags for their fork, it's an ongoing patchset that's based on a specific Python version. My "use a tag" advice is a bit misleading here. I actually mean "use a commit hash". Sorry for that.

Is there a minimal case for testing

The bare minimum is being able to launch Python in GDB (by running python from the gdb prompt) and import the gdb module. If that succeeds, then the basic functionality is there, and we can solve other problems later.

[xtemp09]

Perhaps, a minimal test case is the possibility to be used in Qt Creator as the debugger.

Arcane has been released, my birthday is coming, now Python support is finally being added to the toolchain. The end is nigh.

[longnguyen2004]

Arcane has been released, my birthday is coming, now Python support is finally being added to the toolchain. The end is nigh.

Only after a year :) (which is kinda funny, since llvm-mingw also took a year to add Python support, and I basically wrote the build script for them)

[brechtsanders]

[longnguyen2004]

Can you import gdb?

[brechtsanders]

What do you mean exactly?

I have started building GCC 11.2.1-snapshot20211211 and will try include gdb in this package.

Do you know if it only requires the Python DLL, or should other files also be copied (e.g. lib/python*/*)?

[longnguyen2004]

What do you mean exactly?

After entering Python, run import gdb to import the gdb module. If it succeed, then the basic functionality is working.

Do you know if it only requires the Python DLL, or should other files also be copied (e.g. lib/python*/*)?

I just do make install and leave it as is, since the user might want to do custom data processing that relies on the standard modules. To lower the build size, you can delete the various test modules and the __pycache__ folder, to save a couple hundred MB.

[brechtsanders]

I'm trying to make the distribution package.

Currently when I run gdb --version the result is:

Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Python path configuration:
  PYTHONHOME = (not set)
  PYTHONPATH = (not set)
  program name = 'r:\d\prog\winlibs64ucrt_stage\custombuilt\share\python/bin/python'
  isolated = 0
  environment = 1
  user site = 1
  import site = 1
  sys._base_executable = 'r:\\d\\prog\\winlibs64ucrt_stage\\custombuilt\\share\\python/bin/python'
  sys.base_prefix = 'R:/winlibs64ucrt_stage/33664.cpython-mingw/inst_cpython-mingw-3.9.7/share/python'
  sys.base_exec_prefix = 'R:/winlibs64ucrt_stage/33664.cpython-mingw/inst_cpython-mingw-3.9.7/share/python'
  sys.platlibdir = 'lib'
  sys.executable = 'r:\\d\\prog\\winlibs64ucrt_stage\\custombuilt\\share\\python/bin/python'
  sys.prefix = 'R:/winlibs64ucrt_stage/33664.cpython-mingw/inst_cpython-mingw-3.9.7/share/python'
  sys.exec_prefix = 'R:/winlibs64ucrt_stage/33664.cpython-mingw/inst_cpython-mingw-3.9.7/share/python'
  sys.path = [
    'R:/winlibs64ucrt_stage/33664.cpython-mingw/inst_cpython-mingw-3.9.7/share/python/lib/python39.zip',
    'R:/winlibs64ucrt_stage/33664.cpython-mingw/inst_cpython-mingw-3.9.7/share/python/lib/python3.9',
    'R:/winlibs64ucrt_stage/33664.cpython-mingw/inst_cpython-mingw-3.9.7/share/python/lib/lib-dynload',
    '',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x000033e4 (most recent call first):
<no Python frame>

Looks like the executable path isn't properly detected and there are some dive letter issues (e.g. r:\\d\\).

[brechtsanders]

This fixed the issue. Apparently the detected path got overruled by the compile-time value...

patch -ulbf Python/pathconfig.c << EOF
@@ -421,7 +421,7 @@
             } \
         }

-#ifdef MS_WINDOWS
+#if defined(MS_WINDOWS) && !defined(__MINGW32__)
     if (config->executable != NULL && config->base_executable == NULL) {
         /* If executable is set explicitly in the configuration,
            ignore calculated base_executable: _PyConfig_InitPathConfig()
EOF

Now the next step is to run: python -c "import gdb" but unfortunately this returns:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "R:/winlibs64ucrt_stage/inst_winlibs-x86_64-posix-seh-gcc-11.2.1-snapshot20211211-mingw-w64ucrt-9.0.0-r1/mingw64/lib/python3.9/gdb/__init__.py", line 19, in <module>
    import _gdb
ModuleNotFoundError: No module named '_gdb'

What needs to be copied for the module with underscore (_gdb) to be able to load?

[longnguyen2004]

You need to run it from inside gdb, not from bare Python. Basically, run gdb, then enter Python mode, then import gdb

[brechtsanders]

Like this?

GNU gdb (GDB for MinGW-W64 x86_64, built by Brecht Sanders) 11.1
Copyright (C) 2021 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.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) python-interactive
>>> import gdb
>>> quit()

Looks good right?

[Whotakesmyname]

Looks beautiful.