> From: Keith Marshall <keith****@users*****> > Date: Wed, 22 Jul 2020 16:48:35 +0100 > > > I actually don't understand why you needed a Windows file name there. > > The --with-python= configure switch just tells the build process where > > to find the header files during compilation and import libraries to > > link against; the actual Python DLLs will be found at run time via the > > standard Windows DLL search. What am I missing? > > The --with-python=... option accepts arguments of "auto", "yes", "no", > or the name (maybe a fully qualified path name) for the interpreter to > be used for python. It does _not_ seem to accept just the path name of > the python installation tree; rather, if given anything other than "no", > "yes", or "auto", it runs the named interpreter on a provided python > script -- gdb/python/python-config.py -- which offers capabilities > similar to pkg-config, to identify include file paths, library refs, and > the exec-prefix for the python interpreter itself; if the given name > doesn't refer to a valid python interpreter, the python identification > fails, and the effect is as if --without-python had been specified. I think it does both: runs Python at build time to serve the configuration step, and point to a Python tree for compilation and linking. If the system where GDB is run has Python in another place, the end user will have to set PYTHONPATH to point to several directories in that place. > Now, the interpreter used here _has_ to be a Windows python interpreter, > because the requisite paths exhibit significantly different forms from > their GNU/Linux equivalents ... and if I just use --with-python, (the > default interpretation is equivalent to --with-python-auto), or if I use > --with-python=yes, I get paths suitable for GNU/Linux Python. Thus, I > _must_ specify the Windows Python interpreter, in my Wine prefix, but if > I just specify that directly, it spits out results which are a) prefixed > by 'C:/', and b) CRLF terminated. The CRLF termination is a problem, > because GNU/Linux expects LF only, and the '\r' is considered to be a > literal part of each result, invalidating the resulting path names. My > win-python wrapper script deals with that, by stripping away any > trailing '\r'; it currently assumes that the 'C:/' prefix can be > accommodated by a symbolic link from C: -> WINE_PREFIX/drive_c, but that > isn't a satisfactory solution, in this case, so I need to devise a > better alternative. I guess cross-compiling GDB with Python (or Guile, for that matter) is not something many people do... > Whatever viable alternative I come up with, it's clear that it needs to > be reflected in the reported include file and library paths, but I don't > know how the exec-prefix is used within gdb, so it isn't clear to me, > whether or not the C:/... syntax needs to be preserved for this. The Python tree is "relocatable", i.e. if GDB discovers at run time that its installation is some place different from the configured exec-prefix, it will "rewrite" the beginning of the root of the Python installation to be in sync with the actual GDB installation directory. So, for example, if GDB was configured for exec-prefix = x:/usr, and you give --with-python=x:/usr/Python27, then GDB invoked from C:/foo/bar/bin will look for Python in C:/foo/bar/Python27. If this won't work because GDB and Python's installations are "out of sync" wrt their top-level installation directory, then the user needs to use PYTHONPATH. In practice, I think any user of MinGW GDB with Python will have to set PYTHONPATH, unless they copycat your particular directory hierarchy, which AFAICT is not a simple one.
Fork