Re: Time for a MinGW-GDB Upgrade?

Keith Marshall <[email protected]> Wed, 22 Jul 2020 19:06:29 +0100
Newsgroups	gmane.comp.gnu.mingw.user
Organization	MinGW.org Project
Message-ID	<[email protected]>
On 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

_______________________________________________
MinGW-Users mailing list
[email protected]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.osdn.me/mailman/listinfo/mingw-users
Also: mailto:[email protected]?subject=unsubscribe
signature.asc (application/pgp-signature, 833 B)