Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
在 2018/11/24 13:30, Edward Diener 写道: > ==> Starting prepare()... > patch: invalid argument 'E:\\Programming\\VersionControl' for > '$VERSION_CONTROL' > Valid arguments are: > - 'none', 'off' > - 'simple', 'never' > - 'existing', 'nil' > - 'numbered', 't' > ==> ERROR: A failure occurred in prepare(). > Aborting... > > I do not know what I am doing wrong. > Probably you should `unset VERSION_CONTROL` before invoking `makepkg-mingw`. I can build the package in my MSYS2 and here is my log: ``` lh_mouse@lhmouse-pc /e/GitHub/MINGW-packages/mingw-w64-binutils $ makepkg-mingw --skippgpcheck ==> Making package: mingw-w64-binutils 2.30-5 (Sat, Nov 24, 2018 2:17:26 PM) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Downloading binutils-2.30.tar.bz2... % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 28.1M 100 28.1M0 0 355k 0 0:01:21 0:01:21 --:--:-- 572k -> Downloading binutils-2.30.tar.bz2.sig... % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 801 100 8010 0645 0 0:00:01 0:00:01 --:--:-- 645 -> Found 0001-enable-gold-on.mingw32.patch -> Found 0002-check-for-unusual-file-harder.patch -> Found 0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch -> Found 0110-binutils-mingw-gnu-print.patch -> Found 0200-remove-provide-qualifiers.patch ==> WARNING: Skipping verification of source file PGP signatures. ==> Validating source files with sha256sums... binutils-2.30.tar.bz2 ... Passed binutils-2.30.tar.bz2.sig ... Skipped 0001-enable-gold-on.mingw32.patch ... Passed 0002-check-for-unusual-file-harder.patch ... Passed 0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch ... Passed 0110-binutils-mingw-gnu-print.patch ... Passed 0200-remove-provide-qualifiers.patch ... Passed ==> Extracting sources... -> Extracting binutils-2.30.tar.bz2 with bsdtar ==> Starting prepare()... patching file configure Hunk #1 succeeded at 2956 with fuzz 1 (offset 91 lines). Hunk #2 succeeded at 2968 with fuzz 1 (offset 91 lines). patching file binutils/bucomm.c Hunk #1 succeeded at 590 with fuzz 2 (offset 15 lines). patching file binutils/elfedit.c patching file bfd/coff-alpha.c patching file bfd/coff-mips.c patching file bfd/coff-rs6000.c patching file bfd/coff-sh.c patching file bfd/coffcode.h patching file bfd/bfd-in.h Hunk #1 succeeded at 138 (offset 1 line). patching file bfd/bfd-in2.h Hunk #1 succeeded at 145 (offset 1 line). patching file binutils/dwarf.c Hunk #1 succeeded at 183 (offset 19 lines). patching file binutils/nm.c Hunk #1 succeeded at 171 (offset 1 line). Hunk #2 succeeded at 302 (offset 2 lines). patching file binutils/prdbg.c patching file binutils/readelf.c Hunk #1 succeeded at 1214 (offset 60 lines). Hunk #2 succeeded at 13255 (offset 883 lines). patching file binutils/strings.c Hunk #1 succeeded at 557 (offset -38 lines). Hunk #2 succeeded at 576 (offset -38 lines). Hunk #3 succeeded at 595 (offset -38 lines). patching file gas/as.h Hunk #1 succeeded at 437 (offset -1 lines). patching file gas/read.c Hunk #1 succeeded at 4437 (offset 22 lines). patching file gold/configure Hunk #1 succeeded at 7629 (offset 71 lines). patching file gold/configure.ac Hunk #1 succeeded at 655 (offset 20 lines). patching file include/ansidecl.h patching file ld/ChangeLog Hunk #1 succeeded at 1 with fuzz 1. patching file ld/ld.texinfo patching file ld/scripttempl/pe.sc patching file ld/scripttempl/pep.sc ==> Starting build()... configure: loading site script /etc/config.site checking build system type... x86_64-w64-mingw32 checking host system type... x86_64-w64-mingw32 checking target system type... x86_64-w64-mingw32 checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... no, using cp -p checking for a sed that does not truncate output... /usr/bin/sed checking for gawk... gawk checking for x86_64-w64-mingw32-gcc... x86_64-w64-mingw32-gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes ``` -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
sounds like VERSION_CONTROL is interfering to me. Isnt that a subversion
macro ?, might explain why pacman goes nuts.
Den 24-11-2018 kl. 06:30 skrev Edward Diener:
On 11/23/2018 10:04 PM, Liu Hao wrote:
在 2018/11/24 上午9:31, Edward Diener 写道:
On 11/23/2018 5:06 PM, Greg Jung wrote:
You should try "makepkg -g" and paste/copy the results, for the lines
that
are different, into the PKGBUILD.
Then, makepkg --check can be used to test it.
When I run makepkg -g I get:
==> ERROR: pkgname is not allowed to start with a hyphen.
==> ERROR: depends is not allowed to start with a hyphen.
==> ERROR: depends is not allowed to start with a hyphen.
==> ERROR: makedepends is not allowed to start with a hyphen.
==> ERROR: makedepends is not allowed to start with a hyphen.
In the PKGBUILD file I see these lines among others:
pkgname=("${MINGW_PACKAGE_PREFIX}-${_realname}")
depends=("${MINGW_PACKAGE_PREFIX}-libiconv"
"${MINGW_PACKAGE_PREFIX}-zlib")
makedepends=("${MINGW_PACKAGE_PREFIX}-libiconv"
"${MINGW_PACKAGE_PREFIX}-zlib")
Needless to say I did not change any of these lines.
Use `makepkg-mingw` to build MinGW{32,64} packages, rather than
`makepkg`. That is exactly the difference.
First output:
$ makepkg-mingw --skippgpcheck -g
==> Retrieving sources...
-> Found binutils-2.30.tar.bz2
-> Found binutils-2.30.tar.bz2.sig
-> Found 0001-enable-gold-on.mingw32.patch
-> Found 0002-check-for-unusual-file-harder.patch
-> Found 0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch
-> Found 0110-binutils-mingw-gnu-print.patch
-> Found 0200-remove-provide-qualifiers.patch
-> Found
binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch
==> Generating checksums for source files...
sha256sums=('efeade848067e9a03f1918b1da0d37aaffa0b0127a06b5e9236229851d9d0c09'
'SKIP'
'93296b909e1a4f9d8a4bbe2437aafa17ca565ef6642a9812b0360c05be228c9d'
'2c99345fc575c3a060d6677537f636c6c4154fac0fde508070f3b6296c1060d4'
'604e76e0f702ced493ee22aa3c1768b4776b2008a7d70ae0dd35fe5be3522141'
'0f145655d4f2aae3383e0c0269d0c47b8a7176144bf0595425fc38b7ebf53153'
'28b6d20d1f7e1f29b61bdafff452f2421b7f5b084f69c9563ec4630b1f041abd'
'e4508ea8be28da56e0285c054cbb03636b95fcbb871ba10aa181fa7788f8c8d1')
==> Retrieving sources...
-> Found binutils-2.30.tar.bz2
-> Found binutils-2.30.tar.bz2.sig
-> Found 0001-enable-gold-on.mingw32.patch
-> Found 0002-check-for-unusual-file-harder.patch
-> Found 0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch
-> Found 0110-binutils-mingw-gnu-print.patch
-> Found 0200-remove-provide-qualifiers.patch
-> Found
binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch
==> Generating checksums for source files...
sha256sums=('efeade848067e9a03f1918b1da0d37aaffa0b0127a06b5e9236229851d9d0c09'
'SKIP'
'93296b909e1a4f9d8a4bbe2437aafa17ca565ef6642a9812b0360c05be228c9d'
'2c99345fc575c3a060d6677537f636c6c4154fac0fde508070f3b6296c1060d4'
'604e76e0f702ced493ee22aa3c1768b4776b2008a7d70ae0dd35fe5be3522141'
'0f145655d4f2aae3383e0c0269d0c47b8a7176144bf0595425fc38b7ebf53153'
'28b6d20d1f7e1f29b61bdafff452f2421b7f5b084f69c9563ec4630b1f041abd'
'e4508ea8be28da56e0285c054cbb03636b95fcbb871ba10aa181fa7788f8c8d1')
Second output:
$ makepkg-mingw --skippgpcheck
==> Making package: mingw-w64-binutils 2.30-5 (Sat, Nov 24, 2018
12:21:41 AM)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found binutils-2.30.tar.bz2
-> Found binutils-2.30.tar.bz2.sig
-> Found 0001-enable-gold-on.mingw32.patch
-> Found 0002-check-for-unusual-file-harder.patch
-> Found 0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch
-> Found 0110-binutils-mingw-gnu-print.patch
-> Found 0200-remove-provide-qualifiers.patch
-> Found
binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch
==> WARNING: Skipping verification of source file PGP signatures.
==> Validating source files with sha256sums...
binutils-2.30.tar.bz2 ... Passed
binutils-2.30.tar.bz2.sig ... Skipped
0001-enable-gold-on.mingw32.patch ... Passed
0002-check-for-unusual-file-harder.patch ... Passed
0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch ... Passed
0110-binutils-mingw-gnu-print.patch ... Passed
0200-remove-provide-qualifiers.patch ... Passed
binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch ...
Passed
==> Extracting sources...
-> Extracting binutils-2.30.tar.bz2 with bsdtar
==> Starting prepare()...
patch: invalid argument 'E:\\Programming\\VersionControl' for
'$VERSION_CONTROL'
Valid arguments are:
- 'none', 'off'
- 'simple', 'never'
- 'existing', 'nil'
- 'numbered', 't'
==> ERROR: A failure occurred in prepare().
Aborting...
I do not know what I am doing wrong.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/23/2018 10:04 PM, Liu Hao wrote:
在 2018/11/24 上午9:31, Edward Diener 写道:
On 11/23/2018 5:06 PM, Greg Jung wrote:
You should try "makepkg -g" and paste/copy the results, for the lines
that
are different, into the PKGBUILD.
Then, makepkg --check can be used to test it.
When I run makepkg -g I get:
==> ERROR: pkgname is not allowed to start with a hyphen.
==> ERROR: depends is not allowed to start with a hyphen.
==> ERROR: depends is not allowed to start with a hyphen.
==> ERROR: makedepends is not allowed to start with a hyphen.
==> ERROR: makedepends is not allowed to start with a hyphen.
In the PKGBUILD file I see these lines among others:
pkgname=("${MINGW_PACKAGE_PREFIX}-${_realname}")
depends=("${MINGW_PACKAGE_PREFIX}-libiconv" "${MINGW_PACKAGE_PREFIX}-zlib")
makedepends=("${MINGW_PACKAGE_PREFIX}-libiconv"
"${MINGW_PACKAGE_PREFIX}-zlib")
Needless to say I did not change any of these lines.
Use `makepkg-mingw` to build MinGW{32,64} packages, rather than
`makepkg`. That is exactly the difference.
First output:
$ makepkg-mingw --skippgpcheck -g
==> Retrieving sources...
-> Found binutils-2.30.tar.bz2
-> Found binutils-2.30.tar.bz2.sig
-> Found 0001-enable-gold-on.mingw32.patch
-> Found 0002-check-for-unusual-file-harder.patch
-> Found 0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch
-> Found 0110-binutils-mingw-gnu-print.patch
-> Found 0200-remove-provide-qualifiers.patch
-> Found binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch
==> Generating checksums for source files...
sha256sums=('efeade848067e9a03f1918b1da0d37aaffa0b0127a06b5e9236229851d9d0c09'
'SKIP'
'93296b909e1a4f9d8a4bbe2437aafa17ca565ef6642a9812b0360c05be228c9d'
'2c99345fc575c3a060d6677537f636c6c4154fac0fde508070f3b6296c1060d4'
'604e76e0f702ced493ee22aa3c1768b4776b2008a7d70ae0dd35fe5be3522141'
'0f145655d4f2aae3383e0c0269d0c47b8a7176144bf0595425fc38b7ebf53153'
'28b6d20d1f7e1f29b61bdafff452f2421b7f5b084f69c9563ec4630b1f041abd'
'e4508ea8be28da56e0285c054cbb03636b95fcbb871ba10aa181fa7788f8c8d1')
==> Retrieving sources...
-> Found binutils-2.30.tar.bz2
-> Found binutils-2.30.tar.bz2.sig
-> Found 0001-enable-gold-on.mingw32.patch
-> Found 0002-check-for-unusual-file-harder.patch
-> Found 0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch
-> Found 0110-binutils-mingw-gnu-print.patch
-> Found 0200-remove-provide-qualifiers.patch
-> Found binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch
==> Generating checksums for source files...
sha256sums=('efeade848067e9a03f1918b1da0d37aaffa0b0127a06b5e9236229851d9d0c09'
'SKIP'
'93296b909e1a4f9d8a4bbe2437aafa17ca565ef6642a9812b0360c05be228c9d'
'2c99345fc575c3a060d6677537f636c6c4154fac0fde508070f3b6296c1060d4'
'604e76e0f702ced493ee22aa3c1768b4776b2008a7d70ae0dd35fe5be3522141'
'0f145655d4f2aae3383e0c0269d0c47b8a7176144bf0595425fc38b7ebf53153'
'28b6d20d1f7e1f29b61bdafff452f2421b7f5b084f69c9563ec4630b1f041abd'
'e4508ea8be28da56e0285c054cbb03636b95fcbb871ba10aa181fa7788f8c8d1')
Second output:
$ makepkg-mingw --skippgpcheck
==> Making package: mingw-w64-binutils 2.30-5 (Sat, Nov 24, 2018
12:21:41 AM)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found binutils-2.30.tar.bz2
-> Found binutils-2.30.tar.bz2.sig
-> Found 0001-enable-gold-on.mingw32.patch
-> Found 0002-check-for-unusual-file-harder.patch
-> Found 0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch
-> Found 0110-binutils-mingw-gnu-print.patch
-> Found 0200-remove-provide-qualifiers.patch
-> Found binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch
==> WARNING: Skipping verification of source file PGP signatures.
==> Validating source files with sha256sums...
binutils-2.30.tar.bz2 ... Passed
binutils-2.30.tar.bz2.sig ... Skipped
0001-enable-gold-on.mingw32.patch ... Passed
0002-check-for-unusual-file-harder.patch ... Passed
0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch ... Passed
0110-binutils-mingw-gnu-print.patch ... Passed
0200-remove-provide-qualifiers.patch ... Passed
binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch ...
Passed
==> Extracting sources...
-> Extracting binutils-2.30.tar.bz2 with bsdtar
==> Starting prepare()...
patch: invalid argument 'E:\\Programming\\VersionControl' for
'$VERSION_CONTROL'
Valid arguments are:
- 'none', 'off'
- 'simple', 'never'
- 'existing', 'nil'
- 'numbered', 't'
==> ERROR: A failure occurred in prepare().
Aborting...
I do not know what I am doing wrong.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
在 2018/11/24 上午9:31, Edward Diener 写道:
> On 11/23/2018 5:06 PM, Greg Jung wrote:
>> You should try "makepkg -g" and paste/copy the results, for the lines
>> that
>> are different, into the PKGBUILD.
>> Then, makepkg --check can be used to test it.
>
> When I run makepkg -g I get:
>
> ==> ERROR: pkgname is not allowed to start with a hyphen.
> ==> ERROR: depends is not allowed to start with a hyphen.
> ==> ERROR: depends is not allowed to start with a hyphen.
> ==> ERROR: makedepends is not allowed to start with a hyphen.
> ==> ERROR: makedepends is not allowed to start with a hyphen.
>
> In the PKGBUILD file I see these lines among others:
>
> pkgname=("${MINGW_PACKAGE_PREFIX}-${_realname}")
> depends=("${MINGW_PACKAGE_PREFIX}-libiconv" "${MINGW_PACKAGE_PREFIX}-zlib")
> makedepends=("${MINGW_PACKAGE_PREFIX}-libiconv"
> "${MINGW_PACKAGE_PREFIX}-zlib")
>
> Needless to say I did not change any of these lines.
>
Use `makepkg-mingw` to build MinGW{32,64} packages, rather than
`makepkg`. That is exactly the difference.
--
Best regards,
LH_Mouse
signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/23/2018 5:49 PM, Earnie via Mingw-w64-public wrote: On 11/23/2018 3:12 PM, Edward Diener wrote: On 11/23/2018 9:06 AM, Liu Hao wrote: 在 2018/11/23 21:55, Edward Diener 写道: On 11/22/2018 9:07 PM, Liu Hao wrote: ==> Verifying source file signatures with gpg... binutils-2.30.tar.bz2 ... FAILED (unknown public key 13FCEF89DD9E3C4F) ==> ERROR: One or more PGP signatures could not be verified! Do you have any idea of how I am supposed to fix the ERROR ? Passing `--skippgpcheck` to `makepkg-mingw` would likely overcome this problem. I used --skippgpcheck' but am now getting this really cryptic error of: ==> Starting prepare()... patch: invalid argument 'E:\\Programming\\VersionControl' for '$VERSION_CONTROL' Valid arguments are: - 'none', 'off' - 'simple', 'never' - 'existing', 'nil' - 'numbered', 't' ==> ERROR: A failure occurred in prepare(). Aborting... I have an environment variable under Windows called VERSION_CONTROL but what that has to do with the problem above I do not understand. Does MSYS2 look for an environment variable called VERSION_CONTROL ? It is possible, though I don't know for sure yet, that such a variable could interfere with operation of makepkg. The failure is in applying the first patch file. The patch program isn't liking the Windows style path. Add `--debug` to see the actual command line being executed. When I added --debug, as in 'makepkg-mingw --skippgpcheck --debug', I received: makepkg: invalid option '--debug' ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/23/2018 5:06 PM, Greg Jung wrote:
You should try "makepkg -g" and paste/copy the results, for the lines that
are different, into the PKGBUILD.
Then, makepkg --check can be used to test it.
When I run makepkg -g I get:
==> ERROR: pkgname is not allowed to start with a hyphen.
==> ERROR: depends is not allowed to start with a hyphen.
==> ERROR: depends is not allowed to start with a hyphen.
==> ERROR: makedepends is not allowed to start with a hyphen.
==> ERROR: makedepends is not allowed to start with a hyphen.
In the PKGBUILD file I see these lines among others:
pkgname=("${MINGW_PACKAGE_PREFIX}-${_realname}")
depends=("${MINGW_PACKAGE_PREFIX}-libiconv" "${MINGW_PACKAGE_PREFIX}-zlib")
makedepends=("${MINGW_PACKAGE_PREFIX}-libiconv"
"${MINGW_PACKAGE_PREFIX}-zlib")
Needless to say I did not change any of these lines.
On Fri, Nov 23, 2018 at 10:51 AM Edward Diener <
eldlistmaili...@tropicsoft.com> wrote:
On 11/23/2018 9:06 AM, Liu Hao wrote:
在 2018/11/23 21:55, Edward Diener 写道:
On 11/22/2018 9:07 PM, Liu Hao wrote:
==> Verifying source file signatures with gpg...
binutils-2.30.tar.bz2 ... FAILED (unknown public key
13FCEF89DD9E3C4F)
==> ERROR: One or more PGP signatures could not be verified!
Do you have any idea of how I am supposed to fix the ERROR ?
Passing `--skippgpcheck` to `makepkg-mingw` would likely overcome this
problem.
I used --skippgpcheck' but am now getting this really cryptic error of:
==> Starting prepare()...
patch: invalid argument 'E:\\Programming\\VersionControl' for
'$VERSION_CONTROL'
Valid arguments are:
- 'none', 'off'
- 'simple', 'never'
- 'existing', 'nil'
- 'numbered', 't'
==> ERROR: A failure occurred in prepare().
Aborting...
I have an environment variable under Windows called VERSION_CONTROL but
what that has to do with the problem above I do not understand. Does
MSYS2 look for an environment variable called VERSION_CONTROL ?
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/23/2018 3:12 PM, Edward Diener wrote: On 11/23/2018 9:06 AM, Liu Hao wrote: 在 2018/11/23 21:55, Edward Diener 写道: On 11/22/2018 9:07 PM, Liu Hao wrote: ==> Verifying source file signatures with gpg... binutils-2.30.tar.bz2 ... FAILED (unknown public key 13FCEF89DD9E3C4F) ==> ERROR: One or more PGP signatures could not be verified! Do you have any idea of how I am supposed to fix the ERROR ? Passing `--skippgpcheck` to `makepkg-mingw` would likely overcome this problem. I used --skippgpcheck' but am now getting this really cryptic error of: ==> Starting prepare()... patch: invalid argument 'E:\\Programming\\VersionControl' for '$VERSION_CONTROL' Valid arguments are: - 'none', 'off' - 'simple', 'never' - 'existing', 'nil' - 'numbered', 't' ==> ERROR: A failure occurred in prepare(). Aborting... I have an environment variable under Windows called VERSION_CONTROL but what that has to do with the problem above I do not understand. Does MSYS2 look for an environment variable called VERSION_CONTROL ? It is possible, though I don't know for sure yet, that such a variable could interfere with operation of makepkg. The failure is in applying the first patch file. The patch program isn't liking the Windows style path. Add `--debug` to see the actual command line being executed. -- Earnie ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
You should try "makepkg -g" and paste/copy the results, for the lines that are different, into the PKGBUILD. Then, makepkg --check can be used to test it. On Fri, Nov 23, 2018 at 10:51 AM Edward Diener < eldlistmaili...@tropicsoft.com> wrote: > On 11/23/2018 9:06 AM, Liu Hao wrote: > > 在 2018/11/23 21:55, Edward Diener 写道: > >> On 11/22/2018 9:07 PM, Liu Hao wrote: > >> ==> Verifying source file signatures with gpg... > >> binutils-2.30.tar.bz2 ... FAILED (unknown public key > 13FCEF89DD9E3C4F) > >> ==> ERROR: One or more PGP signatures could not be verified! > >> > >> Do you have any idea of how I am supposed to fix the ERROR ? > >> > > > > Passing `--skippgpcheck` to `makepkg-mingw` would likely overcome this > > problem. > > I used --skippgpcheck' but am now getting this really cryptic error of: > > ==> Starting prepare()... > patch: invalid argument 'E:\\Programming\\VersionControl' for > '$VERSION_CONTROL' > Valid arguments are: >- 'none', 'off' >- 'simple', 'never' >- 'existing', 'nil' >- 'numbered', 't' > ==> ERROR: A failure occurred in prepare(). > Aborting... > > I have an environment variable under Windows called VERSION_CONTROL but > what that has to do with the problem above I do not understand. Does > MSYS2 look for an environment variable called VERSION_CONTROL ? > > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds
W dniu 22.11.2018 o 09:51, Mateusz pisze: > W dniu 21.11.2018 o 23:39, Martin Storsjö pisze: >> On Wed, 21 Nov 2018, Mateusz wrote: >> >>> Problem is in libstdc++.a which uses fseeko64 from libmingwex. >>> >>> My proposition is: >>> we could build two libmingwex -- libmingwex for msvcrt and libmingwex10 for >>> msvcr100 and above, leave fseeko64 in libmingwex* and remove _fseeki64 and >>> _ftelli64 from libmingwex10. >>> For msvcrt spec file should be without changes >>> ... -lmoldname -lmingwex -lmsvcrt >>> for ucrtbase (and similar for msvcr120/110/100) >>> ... -lmoldname -lmingwex10 -lucrtbase >> >> In general, so far, when using ucrt, we rely on a number of redirections in >> headers, so that an object file built for an older crt version won't >> necessarily work with the newer one. The exception to this, so far, has been >> the main CRT startup files and libmingw32/libmingwex. (We haven't checked >> all of libmingwex exhaustively, but only the parts that have been pulled in >> by code built in this setup.) >> >> In your case, the issue is that libstdc++.a contains a whole lot of object >> files built targeting another crt version. >> >> I would very much prefer not to have two separate versions of libmingwex. >> Instead it's often possible to tweak what libmingwex does, and tweak the >> headers and actual functions/stubs exported by libmsvcrt.a and libucrtbase.a >> so that the same single build of libmingwex.a works with both. >> >> If the __pioinfo function is the only issue with a libstdc++.a built against >> libmsvcrt.a but linked against libucrtbase.a, it might be worthwhile to try >> to work around it. To do that, the first step would be to look up what it is >> used for and what the replacing functionality is in ucrtbase. After that, >> one can e.g. change the headers to redirect the __piofunction to use the new >> ucrtbase mechansim in general, and add a wrapper in libmsvcr*.a that >> provides this interface. See e.g. src_msvcrt_common in >> mingw-w64-crt/Makefile.am for a few cases of doing this so far. >> >> A different strategy would be to move the helpers that differ depending on >> crt version from libmingwex.a into libmsvcr*.a and libucrtbase.a instead, to >> allow different versions/sets of them that actually match the CRT they are >> to be used with. In this case, move the parts that you wanted to >> differentiate in libmingwex into libmsvcr*.a and libucrtbase.a. > > Thanks! I like the last approach -- we could remove _fseeki64 and _ftelli64 > from libmingwex.a and move these functions to libmsvcrt.a and libmsvcr80.a > (there are already in libmsvcr90.a and newer). > > I will make some tests and prepare new patch. I've attached new patch -- mingw-w64-crt/Makefile.am is changed so you should use automake before testing. Now libmingwex.a is smaller (without _fseeki64 and _ftelli64 functions which are moved to libmsvcrt.a). I can build and execute x265 linked to msvcrt.dll, msvcr120.dll and ucrtbase.dll. In old file mingw-w64-crt/stdio/fseeko64.c was function mingw_dosmaperr that I don't know for what reason it was so I removed this function (there was only one string 'mingw_dosmaperr' in whole mingw-w64 folder). Regards, Mateusz From 2c3234b7f75efce0c6fb0c872ebd79534948fbce Mon Sep 17 00:00:00 2001 From: Mateusz Brzostek Date: Fri, 23 Nov 2018 19:16:43 +0100 Subject: [PATCH] move _fseeki64 and _ftelli64 functions from libmingwex to libmsvcrt Signed-off-by: Mateusz Brzostek --- mingw-w64-crt/Makefile.am | 1 + mingw-w64-crt/stdio/fseeki64.c | 171 +++ mingw-w64-crt/stdio/fseeko64.c | 222 - mingw-w64-headers/crt/stdio.h | 17 +--- 4 files changed, 175 insertions(+), 236 deletions(-) create mode 100644 mingw-w64-crt/stdio/fseeki64.c diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index 079dc5a..f8b0623 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -210,6 +210,7 @@ src_msvcrt=\ secapi/vsprintf_s.c \ secapi/wmemcpy_s.c \ secapi/wmemmove_s.c \ + stdio/fseeki64.c \ stdio/mingw_lock.c src_ucrtbase=\ diff --git a/mingw-w64-crt/stdio/fseeki64.c b/mingw-w64-crt/stdio/fseeki64.c new file mode 100644 index 000..36d3274 --- /dev/null +++ b/mingw-w64-crt/stdio/fseeki64.c @@ -0,0 +1,171 @@ +/** + * This file has no copyright assigned and is placed in the Public Domain. + * This file is part of the mingw-w64 runtime package. + * No warranty is given; refer to the file DISCLAIMER.PD within this package. + */ +#include +#include +#include +#include +#include + +#define _IOYOURBUF 0x0100 +#define _IOSETVBUF 0x0400 +#define _IOFEOF 0x0800 +#define _IOFLRTN0x1000 +#define _IOCTRLZ0x2000 +#define _IOCOMMIT 0x4000 + +/* General use macros */ + +#define inuse(s)((s)->_flag & (_IOREAD|_IOWRT|_IORW)) +#define mbuf(s) ((s)->_flag & _IOMYBUF) +#define nbuf(s)
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
W dniu 23.11.2018 o 00:50, Edward Diener pisze: > There is a bug which in binutils which causes clang targeting mingw-64/gcc on > Windows to create a bad windows executable. The bug is explained at > https://sourceware.org/bugzilla/show_bug.cgi?id=23872 and is fixed at > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=73af69e74974eaa155eec89867e3ccc77ab39f6d > in the binutils-gdb git repository. I understand that part of the blame for > this problem resides with clang, and I have posted a bug report with clang > that is referencing the problem I found, which may be because of the bug. > > Is it possible for me to replace the binutils executables in the latest > mingw-64 installation I have installed on Windows, which is for gcc-8.1, with > the fixed version ? If so how would I do that working on Windows ? I do have > MSYS2 installed but I do not know how to use it to rebuild the binutils for a > mingw-64 installation, if that is possible, so if anyone can offer me > guidance in doing so it would be appreciated. I am a knowledgeable C++ > programmer so I just need some sort of recipe for doing this, if it is > possible, in order to succeed. Now I'm testing new patch for mingw-w64 so I rebuild GCC 7.3.1 with new patch and binutils from current git -- you can try if ld.exe from this binaries works for you. www.msystem.waw.pl/x265/mingw-gcc731-20181123.7z Regards, Mateusz ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/23/2018 9:06 AM, Liu Hao wrote: 在 2018/11/23 21:55, Edward Diener 写道: On 11/22/2018 9:07 PM, Liu Hao wrote: ==> Verifying source file signatures with gpg... binutils-2.30.tar.bz2 ... FAILED (unknown public key 13FCEF89DD9E3C4F) ==> ERROR: One or more PGP signatures could not be verified! Do you have any idea of how I am supposed to fix the ERROR ? Passing `--skippgpcheck` to `makepkg-mingw` would likely overcome this problem. I used --skippgpcheck' but am now getting this really cryptic error of: ==> Starting prepare()... patch: invalid argument 'E:\\Programming\\VersionControl' for '$VERSION_CONTROL' Valid arguments are: - 'none', 'off' - 'simple', 'never' - 'existing', 'nil' - 'numbered', 't' ==> ERROR: A failure occurred in prepare(). Aborting... I have an environment variable under Windows called VERSION_CONTROL but what that has to do with the problem above I do not understand. Does MSYS2 look for an environment variable called VERSION_CONTROL ? ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
So much confusion for something so simple ...
On 11/22/2018 10:30 PM, Liu Hao wrote:
在 2018/11/23 上午10:37, Edward Diener 写道
I do not believe I am trying to upgrade an MSYS2 package. Rather I am
trying to fix a mingw-64/gcc-8.1 installation in Windows itself so that
the binutils part of the installation can be replaced by the fixed
component(s). In particular I am trying to upgrade the ld.exe in the
installation so that it performs the link correctly even for clang. I
Then you can try extracting LD.EXE from the built package, without
installing it using `pacman -U`.
don't mind creating another completely separate mingw-64/gcc-8.1
installation under MSYS2 which works natively under Windows if
necessary, as long as it contains the fix. Does this make any difference
in your instructions ?
The installation directory seems hard-coded to `/mingw32` or `/mingw64`.
As mentioned above, you can always extract `.tar.xz` packages by hand
and I don't think there is any difference.
Caution --- If you copy a file into a MinGW/MSYS system directory then
you will eventually find trouble updating with pacman unless you give
explicit instruction to `--overwrite' the files.
Also when doing things within MSYS2 am I opening
the MSYS2 MSYS prompt or am I opening the MSYS2 MingW 32-bit or MSYS2
MingW 64-bit prompts ? I am on a 64-bit machine. From what I understand
about MSYS2 the MingW 32-bit and MingW 64-bit prompts allow me to create
native Windows applications, but I do not understand the difference
between using either of the two.
In the MSYS2 shell `gcc` refers to the GCC compiling for MSYS2, in the
MinGW32 shell `gcc` refers to the gcc compiling for i686-w64-mingw32,
and in the MinGW64 shell `gcc` refers to the gcc compiling for
x86_64-w64-mingw32. The system roots for these subsystems are '/usr',
'/mingw32' and '/mingw64' respectively.
To state what Liu said in different words.
If I start MSYS with the preferred icon and choose `Mingw-w64 64bit`
button then PATH has /mingw64/bin as its first member so that `which
gcc` finds /mingw64/bin/gcc. If I choose `Mingw-w64 32bit` then `which
gcc` finds /mingw32/bin/gcc. If I choose MSYS2 then `which gcc` finds
/usr/bin/gcc. In all cases the PATH is adjusted but in the Mingw-w64
{32,64}bit cases the /mingw{32,64}/bin directory is prepended.
Also the MSYSTEM environment variable is adjusted so that the effect of
`uname -s` changes. The values of MSYSTEM are one of MINGW64, MINGW32
or MSYS. It is this that will cause config.guess to determine the
native build system to be one or the other because of the result of
`uname -s`.
`makepkg-mingw` should be run in a MSYS2 shell to prevent unexpected
interference of 32 and 64 bit programs, but I haven't tried running it
in a MinGW32 or MinGW64 shell. Honestly I build packages mostly in CMD
(I only ever tried building something in the MSYS2 shell a couple of times).
You need MSYS to use makepkg, it is a shell script dependent on bash.
The makepkg-mingw script eventually passes the process to makepkg with
an option to use the /etc/makepkg-mingw{32,64}.conf file.
--
Earnie
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
在 2018/11/23 21:55, Edward Diener 写道: > On 11/22/2018 9:07 PM, Liu Hao wrote: > ==> Verifying source file signatures with gpg... > binutils-2.30.tar.bz2 ... FAILED (unknown public key 13FCEF89DD9E3C4F) > ==> ERROR: One or more PGP signatures could not be verified! > > Do you have any idea of how I am supposed to fix the ERROR ? > Passing `--skippgpcheck` to `makepkg-mingw` would likely overcome this problem. -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/22/2018 9:07 PM, Liu Hao wrote:
在 2018/11/23 上午7:50, Edward Diener 写道:
There is a bug which in binutils which causes clang targeting
mingw-64/gcc on Windows to create a bad windows executable. The bug is
explained at https://sourceware.org/bugzilla/show_bug.cgi?id=23872 and
is fixed at
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=73af69e74974eaa155eec89867e3ccc77ab39f6d
in the binutils-gdb git repository. I understand that part of the blame
for this problem resides with clang, and I have posted a bug report with
clang that is referencing the problem I found, which may be because of
the bug.
Is it possible for me to replace the binutils executables in the latest
mingw-64 installation I have installed on Windows, which is for gcc-8.1,
with the fixed version ? If so how would I do that working on Windows ?
I do have MSYS2 installed but I do not know how to use it to rebuild the
binutils for a mingw-64 installation, if that is possible, so if anyone
can offer me guidance in doing so it would be appreciated. I am a
knowledgeable C++ programmer so I just need some sort of recipe for
doing this, if it is possible, in order to succeed.
If you already have MSYS2 then upgrading its packages is easy:
1. Clone 'https://github.com/Alexpux/MINGW-packages.git'.
2. CD into 'mingw-w64-binutils', where there are a series of patches and
a file named 'PKGBUILD'.
3. Save the commit in question as a patch file.
4. Add that patch into 'PKGBUILD'. Note that there are two places where
it is expected. The checksum need not be updated.
5. Run `updpkgsums` in an MSYS2 shell to update the checksum for the new
patch.
6. Run `makepkg-mingw` in an MSYS2 shell. This builds both mingw32 and
mingw64 packages for you.
The outcome of this was:
==> Making package: mingw-w64-binutils 2.30-5 (Fri, Nov 23, 2018
8:52:01 AM)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found binutils-2.30.tar.bz2
-> Found binutils-2.30.tar.bz2.sig
-> Found 0001-enable-gold-on.mingw32.patch
-> Found 0002-check-for-unusual-file-harder.patch
-> Found 0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch
-> Found 0110-binutils-mingw-gnu-print.patch
-> Found 0200-remove-provide-qualifiers.patch
-> Found binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch
==> Validating source files with sha256sums...
binutils-2.30.tar.bz2 ... Passed
binutils-2.30.tar.bz2.sig ... Skipped
0001-enable-gold-on.mingw32.patch ... Passed
0002-check-for-unusual-file-harder.patch ... Passed
0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch ... Passed
0110-binutils-mingw-gnu-print.patch ... Passed
0200-remove-provide-qualifiers.patch ... Passed
binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch ...
Passed
==> Verifying source file signatures with gpg...
binutils-2.30.tar.bz2 ... FAILED (unknown public key 13FCEF89DD9E3C4F)
==> ERROR: One or more PGP signatures could not be verified!
Do you have any idea of how I am supposed to fix the ERROR ?
7. Wait for the build process to finish. There should be sort of
'mingw-w64-{i686,x86_64}-binutils*.tar.xz' in the current directory
after the packages are built successfully.
8. Run `pacman -U ' to install these packages. Remember to
replace with the real names of your packages. Wildcards
are allowed.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/22/2018 10:25 PM, Greg Jung wrote:
The recipe from Liu Hao is correct for what it describes and now the
nomenclature
needs to be discussed so that you can explain what you need. You have
called something
"mingw-64" which is none of the options.
When I wrote mingw-64 I meant mingw-w64.
The MINGW group that MSYS2 uses employs the preamble, "mingw-w64" for the
native software
(i.e.. gcc.) so the 32-bit versions are called "mingw-w64-i686- and
the 64-bit versions
are called "mingw-w64-x86_64-". MSYS2 is a posix system, a subset of
CYGWIN.
In MSYS2, the directory tree /mingw64 holds native programs produced by/for
mingw-w64-x86_64,
and /mingw32 does the same, for the i686 mode. The name, "mingw32" is also
used as a generic identifier
(as for the make program, "mingw32-make" found in both /mingw64/bin and in
/mingw32/bin)
For binutils, you may have up to three versions of them. I do:
$ pacman -Ss binutils
mingw32/mingw-w64-i686-binutils 2.29.1-1 (mingw-w64-i686-toolchain)
[installed: 2.25.1-1]
A set of programs to assemble and manipulate binary and object files
(mingw-w64)
mingw64/mingw-w64-x86_64-binutils 2.29.1-1 (mingw-w64-x86_64-toolchain)
[installed: 2.25.1-1]
A set of programs to assemble and manipulate binary and object files
(mingw-w64)
msys/binutils 2.28-1 (msys2-devel) [installed: 2.25-2]
A set of programs to assemble and manipulate binary and object files
OK, the pacman -Ss binutils command gives me:
mingw32/mingw-w64-i686-binutils 2.30-5 (mingw-w64-i686-toolchain)
A set of programs to assemble and manipulate binary and object
files (mingw-w64)
mingw64/mingw-w64-x86_64-binutils 2.30-5 (mingw-w64-x86_64-toolchain)
A set of programs to assemble and manipulate binary and object
files (mingw-w64)
msys/binutils 2.30-1 (msys2-devel)
A set of programs to assemble and manipulate binary and object files
msys/mingw-w64-cross-binutils 2.30-1 (mingw-w64-cross-toolchain
mingw-w64-cross)
A set of programs to assemble and manipulate binary and object files
but the paths do not correspond to anything I can see so I assume it is
some package nomenclature.
I have installed mingw-w64 distributions under Windows and need to
update the ld.exe of one of those distributions, for gcc-8.1, so that
clang 7.0 might work. So the original answer, as I gather it, was to
build the latest mingw-w64, with the necessary patch which fixes my
problem, under MSYS2, since it appears I need a posix-like environment
to build a mingw-w64 distribution from source. My initial confusion is
whether I use the MSYS2 MSYS subsystem or one of the MSYS2 MingW
subsystems to do this, or if it even matters, so I will try the MSYS2
MSYS subsystem.
Once I do this I assume that I have produced Windows executables and
libraries and can copy the ld.exe I produce to the mingw-w64
distribution I have previously installed.
On Thu, Nov 22, 2018 at 6:49 PM Edward Diener <
eldlistmaili...@tropicsoft.com> wrote:
On 11/22/2018 9:07 PM, Liu Hao wrote:
在 2018/11/23 上午7:50, Edward Diener 写道:
There is a bug which in binutils which causes clang targeting
mingw-64/gcc on Windows to create a bad windows executable. The bug is
If you already have MSYS2 then upgrading its packages is easy:
I do not believe I am trying to upgrade an MSYS2 package. Rather I am
trying to fix a mingw-64/gcc-8.1 installation in Windows itself so that
the binutils part of the installation can be replaced by the fixed
component(s). In particular I am trying to upgrade the ld.exe in the
installation so that it performs the link correctly even for clang. I
don't mind creating another completely separate mingw-64/gcc-8.1
installation under MSYS2 which works natively under Windows if
necessary, as long as it contains the fix. Does this make any difference
in your instructions ? Also when doing things within MSYS2 am I opening
the MSYS2 MSYS prompt or am I opening the MSYS2 MingW 32-bit or MSYS2
MingW 64-bit prompts ? I am on a 64-bit machine. From what I understand
about MSYS2 the MingW 32-bit and MingW 64-bit prompts allow me to create
native Windows applications, but I do not understand the difference
between using either of the two.
1. Clone 'https://github.com/Alexpux/MINGW-packages.git'.
2. CD into 'mingw-w64-binutils', where there are a series of patches and
a file named 'PKGBUILD'.
3. Save the commit in question as a patch file.
4. Add that patch into 'PKGBUILD'. Note that there are two places where
it is expected. The checksum need not be updated.
5. Run `updpkgsums` in an MSYS2 shell to update the checksum for the new
patch.
6. Run `makepkg-mingw` in an MSYS2 shell. This builds both mingw32 and
mingw64 packages for you.
7. Wait for the build process to finish. There should be sort of
'mingw-w64-{i686,x86_64}-binutils*.tar.xz' in the current directory
after the packages are built successfully.
8. Run `pacman -U ' to install these packages. Remember to
replace with
