.. to ${MINGW_PREFIX}/share/gdb/python{2,3}/python-gdb.py
Usage:
python
sys.path.append('C:/msys64/mingw64/share/gdb/python3')
import python-gdb
reload(python-gdb)
end
There are link failures at present. If anyone
cares to look into this that'd be great but I
am looking into another GCC bug so I need the
build to succeed. Done as a subsequent patch
rather than removing the patch that enabled
libsanitizer, so that it's easier to remove
once someone fixes this.
Current PKGBUILD pulls directly from the master which BASE-VER is 6.0.0. Recommend either making this change to specify the 5.0 branch which has the current BASE-VER of 5.2.1 or changing _realpkgver to reflect 6.0.0.
Converted the old patches that are still applicable to
git-format patches, adding attribution, commentary and
marking with [deprecated] those that most probably are
not needed anymore.
Fixes https://github.com/Alexpux/MINGW-packages/issues/724 kind of
.. issue 724 is down to the fact that GetModuleFileName is used as
a landmark to locate other executables needed by gpgme. However if
the static library is linked to then the executable will often not
be in /mingw64/bin and the landmark location is irrelevant. I need
to come up with something else instead, but the only idea I've got
at present is to use a registry key for where MSYS2 was installed.
.. breaking multiple installations ... and using the registry, two
things that we've worked hard to avoid so far. Perhaps an env. var.
is the best we can do here.
Anyway, the landmark problem can be mitigated by putting the exe in
the /mingw64/bin folder or perhaps moving the gnupg programs to the
same folder as the exe. Both options are horrible.
Whith that issue avoided, the next bug is the temporary files used
by gpgme to communicate with gnupg are opened with _O_TEMPORARY
meaning they get deleted when they're closed before the spawnee has
had a chance to read them. To avoid this the file is reopened with
the _O_TEMPORARY flag removed.
