Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
在 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. > 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. `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). -- 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
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.
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
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 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
> >
>
>
>
>
> ___
> 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/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:
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 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
___
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 上午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.
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.
--
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
[Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
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. ___ 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 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. Regards, Mateusz ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
