On 19/07/2020 03:30, Eli Zaretskii wrote: >> 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. > > I do the latter in my ports. I think offering 2 builds as you say is > a good solution. After a two week vacation, I've finally posted a GDB-9.2 build to the MinGW.org FRS, at https://osdn.net/projects/mingw/releases/p17061 This release is: a) Python aware, but not python dependent; specifically, if python-2.7 (from Python.org) is installed, such that python27.dll can be found by a LoadLibrary() call [1], this GDB will be able to use it, but if not, GDB will run without python support. b) Dependent on libncursesw6.dll; I don't know how well it may work with builds other than my ncurses-6.2 version, which may be found at https://osdn.net/projects/mingw/storage/, (posted within the mingw32-packages/contributed collection). c) Dependent on libexpat-1.dll; if you need this, you will find a copy of my expat-2.2.9 build at https://osdn.net/projects/mingw/storage/, (within the mingw32-packages/contributed collection). d) Statically linked with libxxhash.a version 0.8.0; I have not posted a build of this, but have posted a mingw-port, within the collection at https://osdn.net/projects/mingw/storage/mingw-ports [1] To achieve this operational duality, I built GDB twice, one build with python, and one without. In each of these builds, I renamed the resultant gdb.exe to gdbmain.exe, and gdbstub.exe respectively. I then compiled a separate loader stub, which I packaged as gdb.exe, (along with the two renamed alternatives). The LoadLibrary() call, referred to in (a), is performed by the loader stub, which then spawns gdbmain.exe, or gdbstub.exe, depending on the outcome of the load attempt. FWIW, when I tested my loader stub (on each of WinXP and Win7 VMs), I discovered a MinGW run-time start-up bug (relating to initialization of MSVCRT.DLL's _pgmptr variable), but that, I think, deserves its own topic thread, or a bug report. -- 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/20200831/a84944e8/attachment.sig>
Fork