Re: Time for a MinGW-GDB Upgrade?

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

_______________________________________________
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)