On 22/07/2020 15:13, Eli Zaretskii wrote: > 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. 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. 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. -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20200722/b1d9b27f/attachment.sig>
Fork