Re: Time for a MinGW-GDB Upgrade?

Keith Marshall <[email protected]> Sat, 18 Jul 2020 21:32:02 +0100
Newsgroups	gmane.comp.gnu.mingw.user
Organization	MinGW.org Project
Message-ID	<[email protected]>
On 18/07/2020 20:08, Eli Zaretskii wrote:
> From: Keith Marshall, Sat, 18 Jul 2020 19:20:11 +0100
>> Not necessarily.  The bug is in pkg-config detection: gdb/configure.ac
>> uses the wrong autoconf macro, selecting pkg-config for $build, (i.e.
>> x86_64-pc-linux-gnu, in my case), where it should select pkg-config for
>> $host, (i.e. mingw32, so mingw32-pkg-config).  Since it's using the
>> wrong pkg-config, it gets the wrong answer when it asks
>>
>>    $pkg_config_prog_path --exists source-highlight
>>
>> (which *does* exist, in the GNU/Linux native compiler tree).
> 
> Ah, so the problem only happens in a cross-build.

Yes, I believe so.

> Omitting Python might be a problem, many projects have custom object
> pretty-printers written in Python (even GCC does for libstdc++),
> without which the users will need jump through hoops to see objects in
> human-readable form.  There are also a couple of GDB commands that are
> implemented in Python.

Requiring Python is also a problem, because I cannot redistribute it;
(the upstream build is done with MSVC, so depends on non-free Microsoft
DLLs, which I don't have a licence to redistribute, and I don't have the
energy to embark on, or to maintain, a MinGW build).  If I do produce a
Python dependent build, then the onus would be on users to furnish the
Python installation for themselves, so they would have to jump through
that hoop anyway.  (I do note that your ezwinport imposes this burden).

What I might consider is to provide a python-independent build, for
those who want a free-standing MinGW build, and an additional (optional
alternative) python-dependent build, for those who may prefer it, and
thus accept the onus of installing python for themselves.

> Expat is needed to parse the XML files supplied with GDB.
> 
>   [...snip...]
> 
> So if the MinGW GDB is only used for native debugging, I guess the
> loss due to no-expat will be minimal, but otherwise it's quite
> significant, I think.

To say nothing of the annoying warning, which appears to be displayed on
starting an inferior process, when GDB is built --without-expat.

> The old MinGW site has expat, can't that be used?

I can easily build an up-to-date expat.  However, the latest release
gratuitously requires Microsoft's rand_s() function, which requires
Vista, or later, (or WinXP with non-free MSVCR80.DLL, or later).  I have
a solution for this, (based on CryptGenRandom(), and thus supported all
the way back to Win95-OSR2, or WinNT4), but it will require an update to
mingwrt, and thus would need a WSL-5.4.1 release; (it would be a trivial
change, requiring no more than public exposure of an existing function,
which is currently implemented internally, with static linkage).

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