ForkOn 22/07/2020 17:44, Eli Zaretskii wrote:
> 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.
So, in theory, if I configure with "--prefix=C:/MinGW", (or maybe just
with "--exec-prefix=C:/MinGW"), and I've arranged it such that testing
for Python yields an effective "python_prefix=C:/Python27", (which does
not seem to be achieved with "--with-python=C:/Python27" ... it needs a
program reference, such as "--with-python=mingw32-python-config", which
is assigned to python_prog, and will return the effective prefix when
that program is invoked as
${python_prog} ${srcdir}/python/python-config.py --exec-prefix
with the result assigned to python_prefix), then, at least, if the user
installs GDB to "x:/MinGW", then that installation should expect to find
Python in "x:/Python27"?
That seems reasonable, but wait ... this is truly weird! For reasons I
explained previously, I need to specify "--with-mpfr=/mingw", (and also
"--with-gmp=/mingw", except that's broken anyway), so that the build
process can find MPFR headers and libraries. As long as I configure
with "--prefix=/mingw", (and leave exec-prefix unspecified), and kludge
around the broken handling of "--with-gmp=/mingw", MPFR detection works
correctly, but if I use "--prefix=C:/MinGW", or even if I simply do no
more than add "--exec-prefix=C:/MinGW", then MPFR detection fails!
Likewise for "--with-expat=/mingw": works fine as long as configuration
of "--prefix=/mingw" is consistent, but breaks with "--prefix=C:/MinGW",
or with "--exec-prefix=C:/MinGW".
> 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.
It isn't really that complex, but GDB's (and GCC's) horrendously complex
configuration process just doesn't always play nicely with cross
compilation, especially when we want Windows style paths to be recorded
in the generated executable program files.
--
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/20200723/335fe34c/attachment.sig>