39f559a7ec2fbdc2bf3829a2a067bd41990e2ad2
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.
…
MINGW-packages
Package scripts for MinGW-w64 targets to build under MSYS2.
To build these, run msys2_shell.bat then from the bash prompt.
cd ${package-name}
makepkg-mingw
To install the built package(s).
pacman -U ${package-name}*.pkg.tar.xz
When creating a PKGBUILD use 2 spaces for each tab
expand -t 2 PKGBUILD > PKGBUILD.new; mv PKGBUILD.new PKGBUILD
Description
Releases
1
srcinfo-cache
Latest
Languages
Shell
87.3%
C
5.8%
Fortran
2%
Tcl
1.5%
CMake
1.3%
Other
2%