ForkOn 22/07/2020 17:44, Eli Zaretskii wrote:
>> 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.
That's not been my experience. The MSI installer has placed Python-2.7
in $HOME/.wine/drive_c/Python27. If I specify
./configure --with-python=$HOME/.wine/drive_c/Python27 ...
then config.log says "no working Python interpreter in [that path]", and
Python support is disabled, for the entire build. OTOH, if I specify
./configure --with-python=$HOME/.wine/drive_c/Python27/python.exe ...
Python _is_ enabled, but the build fails at "make" time; I see path name
references such as
-IC:/Python27/include\r
-LC:/Python27/libs -lPython27.a\r
which cannot be resolved, due to the trailing '\r'. My wrapper script
takes care of those trailing '\r' characters, but then I fall foul of
generated dependency rules with extraneous colons, due to C:/ prefixes
on header and library path names.
> 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.
So, to make that relocation work, my C:/Python27 build-time prefix needs
to be encoded into the gdb executable, and I'm guessing that this is the
result of running
$python_prog ${srcdir}/python/python-config.py --exec-prefix
at "configure" time, so it seems that, whatever transformations are
needed for the 'C:/' prefixes on header and library path specs, they
should _not_ be applied to the python_prefix result.
--
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/44432443/attachment-0001.sig>