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 -------------- 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/20200718/1ba26299/attachment.sig>
Fork