This list is closed, nobody may subscribe to it.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(58) |
Oct
(128) |
Nov
(200) |
Dec
(67) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(75) |
Feb
(78) |
Mar
(24) |
Apr
(15) |
May
(31) |
Jun
(118) |
Jul
(34) |
Aug
(74) |
Sep
(52) |
Oct
(27) |
Nov
(33) |
Dec
(27) |
2002 |
Jan
(40) |
Feb
(75) |
Mar
(48) |
Apr
(63) |
May
(123) |
Jun
(140) |
Jul
(39) |
Aug
(89) |
Sep
(90) |
Oct
(98) |
Nov
(132) |
Dec
(98) |
2003 |
Jan
(74) |
Feb
(70) |
Mar
(71) |
Apr
(13) |
May
(47) |
Jun
(25) |
Jul
(74) |
Aug
(29) |
Sep
(46) |
Oct
(25) |
Nov
(36) |
Dec
(17) |
2004 |
Jan
(9) |
Feb
(45) |
Mar
(32) |
Apr
(19) |
May
(56) |
Jun
(20) |
Jul
(27) |
Aug
(3) |
Sep
(28) |
Oct
(5) |
Nov
(60) |
Dec
(22) |
2005 |
Jan
(29) |
Feb
(24) |
Mar
(10) |
Apr
(20) |
May
(14) |
Jun
(112) |
Jul
(22) |
Aug
(30) |
Sep
(16) |
Oct
(16) |
Nov
(14) |
Dec
(21) |
2006 |
Jan
(40) |
Feb
(6) |
Mar
(51) |
Apr
(62) |
May
(131) |
Jun
(39) |
Jul
(8) |
Aug
(30) |
Sep
(62) |
Oct
(31) |
Nov
(55) |
Dec
(21) |
2007 |
Jan
(111) |
Feb
(56) |
Mar
(123) |
Apr
(50) |
May
(111) |
Jun
(6) |
Jul
(35) |
Aug
(53) |
Sep
(20) |
Oct
(6) |
Nov
(68) |
Dec
(13) |
2008 |
Jan
(17) |
Feb
(24) |
Mar
(65) |
Apr
(153) |
May
(20) |
Jun
(58) |
Jul
(8) |
Aug
(3) |
Sep
(99) |
Oct
(32) |
Nov
(5) |
Dec
(20) |
2009 |
Jan
(9) |
Feb
(2) |
Mar
(18) |
Apr
(73) |
May
(10) |
Jun
(32) |
Jul
(108) |
Aug
(14) |
Sep
(23) |
Oct
(50) |
Nov
(33) |
Dec
(4) |
2010 |
Jan
(79) |
Feb
(63) |
Mar
(48) |
Apr
(35) |
May
(72) |
Jun
(132) |
Jul
(77) |
Aug
(58) |
Sep
(27) |
Oct
(18) |
Nov
(3) |
Dec
(5) |
2011 |
Jan
(24) |
Feb
(14) |
Mar
(25) |
Apr
(10) |
May
(75) |
Jun
(19) |
Jul
(9) |
Aug
(29) |
Sep
(2) |
Oct
(76) |
Nov
(104) |
Dec
(43) |
2012 |
Jan
(38) |
Feb
(42) |
Mar
(8) |
Apr
(55) |
May
(14) |
Jun
(33) |
Jul
(47) |
Aug
(58) |
Sep
(66) |
Oct
(33) |
Nov
(1) |
Dec
|
2013 |
Jan
(58) |
Feb
(65) |
Mar
(112) |
Apr
(71) |
May
(6) |
Jun
(3) |
Jul
(12) |
Aug
(14) |
Sep
(11) |
Oct
(14) |
Nov
(1) |
Dec
(7) |
2014 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(3) |
Sep
(2) |
Oct
(5) |
Nov
(11) |
Dec
(2) |
2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
(7) |
2016 |
Jan
(22) |
Feb
|
Mar
(5) |
Apr
|
May
(9) |
Jun
(9) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(10) |
2017 |
Jan
(14) |
Feb
(6) |
Mar
(7) |
Apr
(12) |
May
(16) |
Jun
(7) |
Jul
(5) |
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Keith M. <kei...@us...> - 2017-05-30 19:11:34
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/05/17 18:31, David Gressett wrote: > > > On Sunday, May 28, 2017 10:48 AM Keith Marshall wrote: > >> On 15/03/17 16:04, David Gressett wrote: >>> The bug that is fixed in gcc 6.3.0 is in the GCC Bugzilla as bug >>> report 70684. a patch is in Comment 7: > >> Thanks, David, but I wonder is really worth bothering to back-port to >> GCC-5.3.0? Would it not be better to just release GCC-6.3.0, which we >> have both now built successfully[*]? > > It is better; if you are ready to move forward, I say go for it. You may notice that, earlier today, I uploaded gcc-6.3.0-mingw32 to FRS, along with binutils-2.28-mingw32, gmp-6.1.2-mingw32, mpfr-3.1.5-mingw32, mpc-1.0.3-mingw32, and isl-0.18-mingw32. I may post an interim heads up for interested users, on the MinGW-Users list, but I'll hold off on a formal release notice until I've completed the mingw-get integration, (which I may not get around to until next week). >>> The other patch is the one for the undefined items; >>> diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.am gcc-5.3.0-working-m64/libgfortran/Makefile.am >>> ... >>> diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.in gcc-5.3.0-working-m64/libgfortran/Makefile.in > >> Strictly, you should patch only Makefile.am, then run autoreconf to >> regenerate Makefile.in, (along with the rest of the build system), and >> yes, that's an absolute pain in the proverbial, unless your automake is >> identically the same version as the original maintainer's; just one of >> the reasons why, despite favouring autoconf, I detest automake. > > No disagreement here. I have avoided the autotools, as I have never > needed them for anything that I have produced, and so I know little > about them; I only use them as needed to build open-source software. > For me, they are magic spells, to be avoided when possible. Well, I think I spent about an hour a day, for around a week, to grasp the rudiments of autoconf; I find it so useful that I tend to use it for everything ... even trivial projects. However, when I subsequently looked at automake, I just could never grasp what useful purpose it might serve ... unless you like to have your logical makefile syntax translated into pure gobbledygook. > I have found, however, that I can't avoid automake. My attempt at > rebuilding the various MinGW libraries with my sjlj GCC-7.1.0 > was derailed when my attempt at compiling gettext-0.18.3.2 > dropped dead because it wanted automake 1.14. > > (To be more specific, it wanted aclocal-1.14) Ah, aclocal; logically, that should be an autoconf component, but the autoconf developers declined to provide any such tool, (perhaps because they were unable to come up with a reasonable design); the automake folks took it on themselves to provide the current turd ... it is both conceptually and fundamentally broken by design, and may even destroy a carefully crafted aclocal.m4, if used carelessly. > I am now working on getting the newer automakes to work. > >> For me, that patch does no more than suppress an innocuous, and harmless >> warning about only being able to create a static libcaf_single.a; that's >> all I get anyway, with or without the patch. Does it create a DLL, and >> accompanying libcaf_single.dll.a, for you? > > I searched my builds for 5.3.0, 6.3.0, and 7.1.0 and found no DLL. Right, so that patch isn't strictly necessary ... it does no more than suppress a fundamentally harmless message, which is readily overlooked anyway, amongst the rest of the build system noise. >> [*] I think I've applied all your patches, but I still don't get any >> Ada associated DLLs built. > > My builds do not put them in the usual place. Look in > > /mingw/lib/gcc/mingw32/6.3.0/adalib > > In that directory, I have libgnarl.a, libgnarl-6.dll, libgnarl-6.dll.a, > libgnat.a, libgnat-6.dll, and libgnat-6.dll.a I've already searched my entire build tree, and staged install tree; in the build tree, I see: gcc/ada/rts/libgnarl.a gcc/ada/rts/libgnat.a but no corresponding DLLs or .dll.a import libraries; in the install tree, I see that these have been copied to: $prefix/lib/gcc/mingw32/6.3.0/adalib/libgnarl.a $prefix/lib/gcc/mingw32/6.3.0/adalib/libgnat.a Among the messages from "make install", I see conditional attempts to install the corresponding DLLs, IFF they exist in gcc/ada/rts, which of course they don't. Among those messages, I also see: cp: cannot stat ‘rts/standard.ads.h’: No such file or directory which may be (potentially) more disturbing. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZLcPcAAoJEMCtNsY0flo/WD0QAIsYUOdADSbph+H3zXYcQY2Z 94V7rCRX8vc4/KZ5TaYIPNqXS0ged0bIXGBJa275pHsCrguxjuZVw5edlwqaTO8j p4AVjAKGU8sJDL3DYdU7fDEQvO0r7ojl2fJRfsYKv33TwHrkWTvCeS92fMHQ8ZRD nvWtW8DqHj3HxAbzhtqiWxh+jl2COy/8/lvhLtPfK4iFxMNeAnbBtnGpDPkba9ZE ZEw6Ap87dy18e9jDVrsHoMC5xsOwKWKO9+X9B6pyi+jrNLIIxd6+RP4OC7Rbu7gD XHwSYl3XGwfemiRur8PRbb/F6ISO56Gf87dWf6PNwv5z/821KiuOeQgZ7k1GC75o zT3qvzd6BZO5xnVuTGO4jkgvo+pQr2AH8avR5tKgPBbDlxOHJQEF4DzKPaBD6tia 00HSZ+HuHUPKEJLg//gUM3LoiqGzuwgW+UjqOC4ZPc9w1ZZy27LdFFSaIcYFEMuq weksmU7CcOnL/D0FeIoiGro+tjtxEdWIEwOKkZDHdUh3anhcoS/ymHW/1LCJlRmN mPulAn5ZIaAZ30spfJr+0peYso034Vg/oTIMzr/sjC9Gbd9P/QZaXYCIf1nP8hrw ajAvcUJfMBL+A6lm0yrqPrgtX3jx2IXB0hg7MsF4HWP73wXfau6lNtOuvQUdd3sf yeXYQWMtVKYBpIgq7rVJ =+x31 -----END PGP SIGNATURE----- |
From: David G. <jdg...@ho...> - 2017-05-30 17:31:11
|
On Sunday, May 28, 2017 10:48 AM Keith Marshall wrote: >On 15/03/17 16:04, David Gressett wrote: >> The bug that is fixed in gcc 6.3.0 is in the GCC Bugzilla as bug >> report 70684. a patch is in Comment 7: >Thanks, David, but I wonder is really worth bothering to back-port to >GCC-5.3.0? Would it not be better to just release GCC-6.3.0, which we >have both now built successfully[*]? It is better; if you are ready to move forward, I say go for it. >> The other patch is the one for the undefined items; >> diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.am gcc-5.3.0-working-m64/libgfortran/Makefile.am >> ... >> diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.in gcc-5.3.0-working-m64/libgfortran/Makefile.in >Strictly, you should patch only Makefile.am, then run autoreconf to >regenerate Makefile.in, (along with the rest of the build system), and >yes, that's an absolute pain in the proverbial, unless your automake is >identically the same version as the original maintainer's; just one of >the reasons why, despite favouring autoconf, I detest automake. No disagreement here. I have avoided the autotools, as I have never needed them for anything that I have produced, and so I know little about them; I only use them as needed to build open-source software. For me, they are magic spells, to be avoided when possible. I have found, however, that I can't avoid automake. My attempt at rebuilding the various MinGW libraries with my sjlj GCC-7.1.0 was derailed when my attempt at compiling gettext-0.18.3.2 dropped dead because it wanted automake 1.14. (To be more specific, it wanted aclocal-1.14) I am now working on getting the newer automakes to work. >For me, that patch does no more than suppress an innocuous, and harmless >warning about only being able to create a static libcaf_single.a; that's >all I get anyway, with or without the patch. Does it create a DLL, and >accompanying libcaf_single.dll.a, for you? I searched my builds for 5.3.0, 6.3.0, and 7.1.0 and found no DLL. >[*] I think I've applied all your patches, but I still don't get any >Ada associated DLLs built. My builds do not put them in the usual place. Look in /mingw/lib/gcc/mingw32/6.3.0/adalib In that directory, I have libgnarl.a, libgnarl-6.dll, libgnarl-6.dll.a, libgnat.a, libgnat-6.dll, and libgnat-6.dll.a |
From: Keith M. <kei...@us...> - 2017-05-28 15:48:37
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/03/17 16:04, David Gressett wrote: > The bug that is fixed in gcc 6.3.0 is in the GCC Bugzilla as bug > report 70684. a patch is in Comment 7: Thanks, David, but I wonder is really worth bothering to back-port to GCC-5.3.0? Would it not be better to just release GCC-6.3.0, which we have both now built successfully[*]? > The other patch is the one for the undefined items; > diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.am gcc-5.3.0-working-m64/libgfortran/Makefile.am > ... > diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.in gcc-5.3.0-working-m64/libgfortran/Makefile.in Strictly, you should patch only Makefile.am, then run autoreconf to regenerate Makefile.in, (along with the rest of the build system), and yes, that's an absolute pain in the proverbial, unless your automake is identically the same version as the original maintainer's; just one of the reasons why, despite favouring autoconf, I detest automake. For me, that patch does no more than suppress an innocuous, and harmless warning about only being able to create a static libcaf_single.a; that's all I get anyway, with or without the patch. Does it create a DLL, and accompanying libcaf_single.dll.a, for you? [*] I think I've applied all your patches, but I still don't get any Ada associated DLLs built. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZKvFMAAoJEMCtNsY0flo/3wkP/j62TC8UCvrS2gwNg8fO0AEt /fcCb6OWCpb+9Jkrr1jXykVoDA0liCLK2PpNYpQIPuH1JwRNCMUXL8GDN3lqQpta T3xlG+ydRz2h8yYdVOAZO5RPo8hmWp2rQDbk7XJt4Klh2ltYHkPfaLtUPDl6nTjc cXzBmoSG4wBGzjofYxEPlGzCpUOBrvwL6LJ989zVm4NV0JC87fygrcJI17SPPeam uX2ymKdb06ENPsdNaOQSRbwiCUBvcS8b8Q2ma3bmuzfRAESqzYNTsO5boqD8P4S0 Ps41Y5zkxGoW39dB1o90OPivmFjTBx55mCAEZhWVPdcEA8vGaUeW7Bbo7O1Kf61c Kb06d9FwX+hBqmQaR68AhHTrXAnjBt3T488NgaFATvGZQhdVE5VesY6ADBkKzGn+ B/NjHpWCdS1Gr4a6xCXUrZWVyBFBI6f4m6V4KS8seLySvoN1+rgmdMmRh6s7oXZP VWFlCJngytz7IJwrgeULV3gKlMJJFiBKJG03dUnSkPegds135CumomMSb9F3/wlh Ayo6u0tf9nfcpatfmmeAvDf81EQ9zV0+2S9fPPwuO1YnSR1rN+ZFs6r7x3JVKC6j CUaNcSO0eCJqVWv6Ay25yg64kFof27xYSa8mSEScUTuPjglx9L2bSzwO6LxHA8V4 Ua+y+xIr6bYzU41nfqls =GA0c -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2017-05-21 12:48:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/05/17 13:09, Keith Marshall wrote: > On 20/05/17 22:36, David Gressett wrote: >> I downloaded pthreads-w32-2.10-mingw32-pre-20160821-1-src.tar.xz > >> (I unpacked this with 7-zip, which complained that it was not an >> xz-compressed archive, but was just a tar that had been renamed.) > > ... > > Please read the notes, at the foot of the FRS download page: > https://sourceforge.net/projects/mingw/files/MinGW/Base/pthreads-w32/pthreads-w32-2.10-pre-20160821-1/ > > The README source file for that is also present on the download page; > it should have been included in the source tarball, but it appears to > have been omitted. I'll remedy that, together with the compression > issue, and upload a fresh copy. Done. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZIYyAAAoJEMCtNsY0flo/z3UP/RnkZTurJrGIBQRK0xKzEKzY qVsx8bRLxuzt12R1zEWWr1uEeHPvVeZu3OqeZMcKvvQq1V7wg7TY/FPFI5nM5+ZY PjcA3wzIqbuVzcVoivqXfcFXmMygCyWxjTTdxzRotXCMTCLR2DgpuNKMgGX8YWTR GVjl6wGV/tbS+7jh0+vMbGZ5HGW7ZZWucpbDK/95eW70AjH7DeSMMel4Ug8mN3DN wxabsh+UQ3DVZjCERH8VEiXakVR79uDGpGje9j6gAIKor+9GAak0spPZ8Kt57tb7 yrjuD5X0RruvkB3fS42P1tByF/GSVpZpdMUhriJkXWEySAJTqrnQIGdqvPZcDejm l4BuFBVaAVqEsUU1BGFHCDKv+gjPzWyMs1JQPjPMWZzzyYQW2oj/Zvc6YS9QaPZC TbNGsTRyKVn/Q4aSDuWlcmIiuRUNXnFvJnK/HACW4HiuY7rWM6vVcPrjYgrgtlEz hzCrUqbTCipo2+kEmmvbfDNkfbN/ajHE5U2x5OG+pah3wgnvR2/iggrv3L114QEI Nvv/eTm74U3xqOQiRI26TYoD99rrMKZ3n3nuVd7E66xga6i5KtR7IUcXjn4uVO7R CUtQqR7e+L8oLqGS9tmlBppnXeduc1FwSu0jTbSIb2QVVdvehV4sESKDM7G35H6r r2AnoooFTuRBoOW7F1ru =cGSD -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2017-05-21 12:09:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/05/17 22:36, David Gressett wrote: > wsl-5 now compiles, so I am on to the next target: pthreads > > I downloaded pthreads-w32-2.10-mingw32-pre-20160821-1-src.tar.xz > > (I unpacked this with 7-zip, which complained that it was not an > xz-compressed archive, but was just a tar that had been renamed.) Hmm. Confirmed, thanks. I don't know what went wrong there; all of the binary packages do appear to be appropriately compressed, in the "dist" staging directory whence I uploaded them: $ file dist/*.xz dist/pthreads-GCE-w32-2.10-mingw32-pre-20160821-1-dev.tar.xz: XZ compressed data dist/pthreads-GCE-w32-2.10-mingw32-pre-20160821-1-dll-3.tar.xz: XZ compressed data dist/pthreads-GC-w32-2.10-mingw32-pre-20160821-1-dev.tar.xz: XZ compressed data dist/pthreads-GC-w32-2.10-mingw32-pre-20160821-1-dll-3.tar.xz: XZ compressed data dist/pthreads-w32-2.10-mingw32-pre-20160821-1-doc.tar.xz: XZ compressed data dist/pthreads-w32-2.10-mingw32-pre-20160821-1-lic.tar.xz: XZ compressed data dist/pthreads-w32-2.10-mingw32-pre-20160821-1-src.tar.xz: POSIX tar archive (GNU) > it already had a makefile for gcc named GNUmakefile, ... which comes directly from upstream; it is NOT build ready. > ... so I tried it. It does several different builds which are > defined by command-line arguments. > > All that I tried failed with several undefined type errors. The > offender is int64_t: > > error: unknown type name 'int64_t' > > What should I do to get this to compile correctly? Please read the notes, at the foot of the FRS download page: https://sourceforge.net/projects/mingw/files/MinGW/Base/pthreads-w32/pthreads-w32-2.10-pre-20160821-1/ The README source file for that is also present on the download page; it should have been included in the source tarball, but it appears to have been omitted. I'll remedy that, together with the compression issue, and upload a fresh copy. Additionally, you may note the availability of a pkgspec file, within the source tarball; this supports building with mingw-pkg[1]: $ pwd /home/keith/src/pthreads-win32-2.10 $ mkdir -p build && cd build $ mingw-pkg --srcdir=.. patch configure compile $ make prefix=`pwd`/staged install WJFFM, delivering: $ ls -R staged/ staged/: bin include lib staged/bin: pthreadGC-3.dll pthreadGCE-3.dll staged/include: pthread.h ptw32_errno.h _ptw32.h sched.h semaphore.h staged/lib: libpthread.a libpthreadGC-3.a libpthreadGCE-3.a libpthread.dll.a libpthreadGC-3.dll.a libpthreadGCE-3.dll.a [1]: If you don't have the latest version of mingw-pkg, with support for the --srcdir option, you can substitute SRCDIR=..; (the advantage of the option is that it makes the SRCDIR=.. assignment persistent, so you don't need to specify it every time you run mingw-pkg in a given build directory). - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZIYN6AAoJEMCtNsY0flo/pkIQAJt6MojohVgTN8DoF3oDUsLc SFOF57BFHn7OnHeKbkirdM9bzCg9UNFOzSgfN5z5KNFPzgz6MeVDwpej9gxDhMA7 DIbPgPyCTpsbxn401i/H6VLobZ3TY7Wdja1FiQ73BZtF5EO1M4oi6pnV+OL8Lzu6 lMlpEnDN8cMiLW6v19+h8yMaWL24BapbNoD7UTNJjQr5IFst09I6IyS5cLijdYhw f9l+48luRi52vSZ5ZpkTFufCBmQhDPTtnm6WWf/XZuG1oZTqbN1yxlonyR4fGnCe fQAyJYJYFciiFwCllNQZJXQECHMmxbE17xl/HjqHhE8xj6FEfUWOZ94TylMt2srl BGmUDfl1u9tcIsKjCAbpd8z1opdEx8YC3NIDuVQ3oyljFPeSdb0ijIIGiswDNOw5 pxWXPrKwEo+b1laothGf+2XtX2DE6rZAorR4Va+vQxJiGlB84slQOj/jtX9RJz3N ZaWynHCoDLPSWmOyXy+qTGI4IpG290MCL6IptMZWlAHqeGldMos7MovT5nDvdjZv Di0gNAaxGyaoaHk1+HIn9RjH/85KeqYVQoFgdCSMSfgc3WSF/zWDlYrruy8PyT5c 9uvTqjSOvUELwPiURnTdWZDwd2etCaMLkY1HHHy1mX7OsvcBtdoRUqeJ7GrDB1ju gzltx0/76s/u8OZP9PDZ =lPMp -----END PGP SIGNATURE----- |
From: David G. <jdg...@ho...> - 2017-05-20 21:36:36
|
wsl-5 now compiles, so I am on to the next target: pthreads I downloaded pthreads-w32-2.10-mingw32-pre-20160821-1-src.tar.xz (I unpacked this with 7-zip, which complained that it was not an xz-compressed archive, but was just a tar that had been renamed.) it already had a makefile for gcc named GNUmakefile, so I tried it. It does several different builds which are defined by command-line arguments. All that I tried failed with several undefined type errors. The offender is int64_t: error: unknown type name 'int64_t' What should I do to get this to compile correctly? |
From: Keith M. <kei...@us...> - 2017-05-19 19:07:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/05/17 17:56, David Gressett wrote: > I used the integrated structure from the git repository. > > Configure fails with this message: > > error: cannot find install-sh, install.sh, or shtool in build-aux ".."/build-aux Then you are trying to build on a (defunct) v4.x branch. You need to ensure that you have checked out the 5.0-active development branch: $ git checkout 5.0-active OTOH, if you cloned into a mercurial working repository, you should already be on the correct "branch"; (actually a bookmark in mercurial parlance, this being the equivalent of a a git branch; true mercurial branches are rather more concrete entities). If you are unsure: $ hg co 5.0-active - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZH0J8AAoJEMCtNsY0flo/j5sP/2WLYybhGVJNFJf1DrVlz6XZ 9zSB9YfdpusxmRKql0tixNL7kZG4jOkPoJxngXDCSuMBwjj7nYFc2C8xI3sMP1fB NrLst4W5BIXxv/BJVZCTo2fcBeA4A5/Rk7AEB+Ul234IU3umbjd97Wr69FHyvZ8e SQC04PLptn1Ols5VD2IdGjPf21yLjFL72RZj6+pHJD2avocGxj+3mDUYVjgpkeMh LLGvfpXQernYVbeEdrHjkPc0bfn5rrPjhBP9pbQQJ2X+eRKqtGExIpYSQLDdjxCn hJK+/KLmDls/BbqlRsRiecY9dS67L7iSOr76YnAkVj1KqCHsURJklm6w27XxQS8a QNf2h21osOJymif6D5kPMr4ORxGt+K1ZBWVJmQJw9hTtsSgNJZHpdltCwDb0Js1W /3wtUcY2HMP/LF+elgbfj7oNGSK8EgFQPY3IMc871E8B5FegpwAO6rRhhzK/fEN8 Bs4VVR8W9NnjN1KFYY9/afrxcWVZIuzabfIbE3GPMFNYbIlMmBJO6nsCl/h6hPxU woRTN0GT1yzir2Kd7GTBFvItJY4rS4ovIen9MPFskKJL0kq6oMRBNXr4rwY5nbbd 7fqk4B2q9sxR3GHaagQzQKyZ0A4eU8/RwdDO3JRVpfuN6k5ZjwLd3J8TnUU/sbcz TIQSgsFJkEX/z4EJMSIw =wsz8 -----END PGP SIGNATURE----- |
From: David G. <jdg...@ho...> - 2017-05-19 17:28:01
|
On Thursday, May 18, 2017, Keith Marshall wrote: >On 17/05/17 19:56, David Gressett wrote: >> There are no build instructions for these How can I >> build them from source as a native Windows build? >Both follow the conventional GNU paradigm: > $ configure && make && make install ... snip ... >I'd also recommend building in a separate directory for each distinct >configuration you wish to create, (a subdirectory at the top level of >your source clone is fine), e.g.: > $ mkdir build-sjlj && cd build-sjlj > $ ../configure --prefix=<your-choice> && make && make install >should build and install both packages for you. I used the integrated structure from the git repository. Configure fails with this message: error: cannot find install-sh, install.sh, or shtool in build-aux ".."/build-aux |
From: Keith M. <kei...@us...> - 2017-05-18 19:28:11
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/05/17 19:56, David Gressett wrote: > There are no build instructions for these How can I > build them from source as a native Windows build? Both follow the conventional GNU paradigm: $ configure && make && make install By default, configure should set prefix to /mingw; use the --prefix=... option, if you wish to stage it elsewhere. Besides that, there is one wrinkle you should consider ... both source packages are interdependent, and must both must be available (in unpacked form), in a common parent directory, before either can be built as a separate entity. You may find it more convenient to build from a git, (or hg), clone of the WSL repository: https://sourceforge.net/p/mingw/mingw-org-wsl/ci/5.0-active/tree/ This supports building both packages as an integrated entity, but does require an additional pre-configuration step, (in the top directory of the cloned repository tree): $ autoreconf -I .. I'd also recommend building in a separate directory for each distinct configuration you wish to create, (a subdirectory at the top level of your source clone is fine), e.g.: $ mkdir build-sjlj && cd build-sjlj $ ../configure --prefix=<your-choice> && make && make install should build and install both packages for you. > I'm doing experiments with building a MinGW gcc 7.1 > that uses sjlj exceptions. I know very little about how > exceptions are done by gcc, but I expect that inconsistent > exception handling methods will cause trouble, so I'm > trying to rebuild everything I might possibly use with > my sjlj test version of gcc 7.1 That would likely be a mandatory requirement ... be sure to build it all with that sjlj compiler itself. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZHfXDAAoJEMCtNsY0flo/k7kP/2WoOqaV9UAmRK/6GDy9+Lkd EhTMLd5JZ6N+KnMzaP2ueMXQCSpkh9Q3KKC9sgYdgZ5qBycwwGHyijKPgBCLaZqu Z8EqodMPk4uM7itNcnU/c7B/j0UsZ18joKr6jdVnb3E+JQxTRcsR8iAAPgIEY2Ol DulmTtDrjgeTaW0dCBvRD8KsoDiwMlXvVAxyXoCJHdu9dt6FDEqt9xMx5IzQOJhC qM3t2ibxLIGgzeR0cQ1lTygT2+OYqBDYuCBdHugIPlQZaXPSMZkV46CwlGQ6W8T6 iE12dfJLNg/hM2rkEJ0FTmPBJlaTs5frQtHNPCHsxBcFENUnijBpkGK6wffvWng0 Zfc5jE2cZkP4MrP2sGdCON2qcOQmNNeLqeCPrZSNy2d/C63Mnt7RnOTusLqHQNlr h90oh2OTOBqRql1TIuBDQGmCMLFnBI1+sf9z0WBMqTBamIIsGhi1Opzi9kI9NIWh LTfgmAV4nw4x1lplqgamXCAYwVon3GjokHRdmHSrtrKXoQK9uKo5f4S7N/ID15+/ PcGLWGWiSzv/wO+MAXVMTCxCev2qUSro2XHR5n2RsC1ft6CyhGMtqoF9C4NYCAPF FuqWMNQ1Lc4cdmsInVu8VZNVdWhFe7QrV8H28WyHwFD0Nk/tQgcAgnHqyuK3jBjH Ot+IDBIP/p9hkJfibGs7 =q6/G -----END PGP SIGNATURE----- |
From: David G. <jdg...@ho...> - 2017-05-17 18:56:52
|
There are no build instructions for these How can I build them from source as a native Windows build? I'm doing experiments with building a MinGW gcc 7.1 that uses sjlj exceptions. I know very little about how exceptions are done by gcc, but I expect that inconsistent exception handling methods will cause trouble, so I'm trying to rebuild everything I might possibly use with my sjlj test version of gcc 7.1 |
From: David G. <jdg...@ho...> - 2017-05-04 22:08:33
|
I have successfully built gcc 7.1.0 for MinGW It would not build with the in-tree gmp, so I removed it and the related mpfr and mpc. I kept isl and built using the MinGW-supplied libraries. The gmp problem will become a separate detective work project. The patch situation has changed, as a number of the patches that I needed in my previous 5.3.0 and 6.3.0 builds are no longer needed; they have been applied to the upstream gcc sources. I have added one completely new patch which fixes a build failure in libstdc++. It is the last patch below. It is adequate for building in the MinGW environment, but needs some #ifdef improvements in order to be submitted to the upstream gcc project. The pkgspec file that I used was almost the same as the one I used for mu 6.3.0 build. The configuration options that I used are shown below: # Configuration options for GCC build # option configure --prefix=/mingw option configure --disable-win32-registry option configure --target=$ARCH --with-arch=i586 option configure --enable-languages=c,c++,objc,obj-c++,fortran,ada option configure --enable-static --enable-shared --enable-threads option configure --with-dwarf2 --disable-sjlj-exceptions option configure --enable-version-specific-runtime-libs option configure --with-libiconv-prefix=/mingw option configure --with-libintl-prefix=/mingw option configure --enable-libstdcxx-debug option configure --with-tune=generic option configure --enable-libgomp option configure --disable-libvtv option configure --enable-nls The patches are included below, and are delimited with lines of dashes. Some of them are almost identical to the original patches for the MinGW gcc 5.3 release, and so I have retained the original file names, but all of these patches have been newly generated by using diff to compare original and patched gcc 7.1.0 source code. 01-mingw-w64-brain-damage.patch ----------------------------------------------------------------------- diff -pNar -U 5 gcc-7.1.0-current/gcc/config/i386/mingw32.h gcc-7.1.0-working/gcc/config/i386/mingw32.h --- gcc-7.1.0-current/gcc/config/i386/mingw32.h 2017-01-17 01:23:40 -0600 +++ gcc-7.1.0-working/gcc/config/i386/mingw32.h 2017-05-02 14:49:43 -0500 @@ -159,22 +159,41 @@ along with GCC; see the file COPYING3. %{fvtable-verify=none:%s; \ fvtable-verify=preinit:vtv_end.o%s; \ fvtable-verify=std:vtv_end.o%s} \ crtend.o%s" -/* Override startfile prefix defaults. */ +#if MINGW_W64_BRAIN_DAMAGE +/* FIXME: override startfile prefix defaults; unconditionally disabled. + + This may suit the mingw-w64 developers, but it seems to unnecessarily + restrict installation path choice; besides, the original defaults seem + to work just fine for me (KDM). */ + #ifndef STANDARD_STARTFILE_PREFIX_1 #define STANDARD_STARTFILE_PREFIX_1 "/mingw/lib/" #endif #ifndef STANDARD_STARTFILE_PREFIX_2 #define STANDARD_STARTFILE_PREFIX_2 "" #endif -/* For native mingw-version we need to take care that NATIVE_SYSTEM_HEADER_DIR - macro contains POSIX-style path. See bug 52947. */ +/* FIXME: work around bug 52947; unconditionally disabled, for now. + + This gross hack works around an issue when building under MSYS: + for native mingw-version we need to ensure that NATIVE_SYSTEM_HEADER_DIR + is defined to represent a POSIX-style path. Unfortunately, MSYS passes + the definition from the makefile, after translation to a fully device + qualified native windows absolute path; TARGET_SYSTEM_ROOT is passed + in similarly translated format, and the concatenation of the pair + becomes invalid as a path name. + + The hack may suit mingw-w64 developers, but it's too restrictive for + general use, and may even produce bogus path references, such as + described by bug 56279. */ + #undef NATIVE_SYSTEM_HEADER_DIR #define NATIVE_SYSTEM_HEADER_DIR "/mingw/include" +#endif /* MINGW_W64_BRAIN_DAMAGE */ /* Output STRING, a string representing a filename, to FILE. We canonicalize it to be in Unix format (backslashes are replaced forward slashes. */ #undef OUTPUT_QUOTED_STRING ----------------------------------------------------------------------- 02-mingw32-float.h.patch ----------------------------------------------------------------------- diff -pNar -U 5 gcc-7.1.0-current/gcc/ginclude/float.h gcc-7.1.0-working/gcc/ginclude/float.h --- gcc-7.1.0-current/gcc/ginclude/float.h 2017-01-01 06:07:43 -0600 +++ gcc-7.1.0-working/gcc/ginclude/float.h 2017-05-02 15:17:02 -0500 @@ -501,6 +501,16 @@ see the files COPYING3 and COPYING.RUNTI #undef DEC_EVAL_METHOD #define DEC_EVAL_METHOD __DEC_EVAL_METHOD__ #endif /* __STDC_WANT_DEC_FP__ */ +#if defined (__MINGW32__) && ! defined (_MINGW_FLOAT_H_) +/* MinGW.org's runtime libraries provide a supplementary float.h, which + * must also be included to complement this one. Ideally that MinGW.org + * header should be included first, and it will include this one, but in + * a default configuration it doesn't normally happen this way; when we + * didn't see it first, include the MinGW.org header now! + */ +# include_next <float.h> +#endif + #endif /* _FLOAT_H___ */ ----------------------------------------------------------------------- 03-ada-largefile.patch ----------------------------------------------------------------------- diff -pNar -U 5 gcc-7.1.0-current/gcc/ada/adaint.c gcc-7.1.0-working/gcc/ada/adaint.c --- gcc-7.1.0-current/gcc/ada/adaint.c 2017-02-01 15:36:09 -0600 +++ gcc-7.1.0-working/gcc/ada/adaint.c 2017-05-02 15:40:03 -0500 @@ -1345,20 +1345,20 @@ win32_filetime (HANDLE h) return (time_t) 0; } /* As above but starting from a FILETIME. */ static void -f2t (const FILETIME *ft, __time64_t *t) +f2t (const FILETIME *ft, GNAT_TIME_T *t) { union { FILETIME ft_time; unsigned long long ull_time; } t_write; t_write.ft_time = *ft; - *t = (__time64_t) (t_write.ull_time / 10000000ULL - w32_epoch_offset); + *t = (GNAT_TIME_T) (t_write.ull_time / 10000000ULL - w32_epoch_offset); } #endif /* Return a GNAT time stamp given a file name. */ @@ -1367,11 +1367,11 @@ __gnat_file_time_name_attr (char* name, { if (attr->timestamp == (OS_Time)-2) { #if defined (_WIN32) BOOL res; WIN32_FILE_ATTRIBUTE_DATA fad; - __time64_t ret = -1; + GNAT_TIME_T ret = -1; TCHAR wname[GNAT_MAX_PATH_LEN]; S2WSC (wname, name, GNAT_MAX_PATH_LEN); if ((res = GetFileAttributesEx (wname, GetFileExInfoStandard, &fad))) f2t (&fad.ftLastWriteTime, &ret); diff -pNar -U 5 gcc-7.1.0-current/gcc/ada/adaint.h gcc-7.1.0-working/gcc/ada/adaint.h --- gcc-7.1.0-current/gcc/ada/adaint.h 2017-01-20 08:49:28 -0600 +++ gcc-7.1.0-working/gcc/ada/adaint.h 2017-05-02 15:42:33 -0500 @@ -57,17 +57,27 @@ extern "C" { #define GNAT_STAT stat64 #define GNAT_FSTAT fstat64 #define GNAT_LSTAT lstat64 #define GNAT_STRUCT_STAT struct stat64 -#elif defined(_WIN32) +#elif defined(_WIN64) #define GNAT_FOPEN fopen64 #define GNAT_OPEN open #define GNAT_STAT stat64 #define GNAT_FSTAT fstat64 #define GNAT_LSTAT lstat #define GNAT_STRUCT_STAT struct stat64 +#define GNAT_TIME_T __time64_t + +#elif defined(_WIN32) +#define GNAT_FOPEN fopen64 +#define GNAT_OPEN open +#define GNAT_STAT _stati64 +#define GNAT_FSTAT _fstati64 +#define GNAT_LSTAT _stati64 +#define GNAT_STRUCT_STAT struct _stati64 +#define GNAT_TIME_T time_t #elif defined(__APPLE__) # include <TargetConditionals.h> diff -pNar -U 5 gcc-7.1.0-current/gcc/ada/cstreams.c gcc-7.1.0-working/gcc/ada/cstreams.c --- gcc-7.1.0-current/gcc/ada/cstreams.c 2016-04-18 07:27:10 -0500 +++ gcc-7.1.0-working/gcc/ada/cstreams.c 2017-05-02 15:58:57 -0500 @@ -262,11 +262,11 @@ __gnat_full_name (char *nam, char *buffe #endif return buffer; } -#ifdef _WIN32 +#ifdef _WIN64 /* On Windows we want to use the fseek/fteel supporting large files. This issue is due to the fact that a long on Win64 is still a 32 bits value */ __int64 __gnat_ftell64 (FILE *stream) { ----------------------------------------------------------------------- 04-eh-frame-begin.patch ----------------------------------------------------------------------- diff -pNar -U 5 gcc-7.1.0-current/libgcc/config/i386/cygming-crtbegin.c gcc-7.1.0-working/libgcc/config/i386/cygming-crtbegin.c --- gcc-7.1.0-current/libgcc/config/i386/cygming-crtbegin.c 2017-01-21 02:52:32 -0600 +++ gcc-7.1.0-working/libgcc/config/i386/cygming-crtbegin.c 2017-05-02 16:30:14 -0500 @@ -76,11 +76,11 @@ __deregister_frame_info (__attribute__(( #endif /* Stick a label at the beginning of the frame unwind info so we can register/deregister it with the exception handling library code. */ #if DWARF2_UNWIND_INFO -static EH_FRAME_SECTION_CONST char __EH_FRAME_BEGIN__[] +EH_FRAME_SECTION_CONST char __EH_FRAME_BEGIN__[] __attribute__((used, section(__LIBGCC_EH_FRAME_SECTION_NAME__), aligned(4))) = { }; static struct object obj; ----------------------------------------------------------------------- 05-ssp-wincrypt.patch ----------------------------------------------------------------------- diff -pNar -U 5 gcc-7.1.0-current/libssp/ssp.c gcc-7.1.0-working/libssp/ssp.c --- gcc-7.1.0-current/libssp/ssp.c 2017-04-01 19:35:58 -0500 +++ gcc-7.1.0-working/libssp/ssp.c 2017-05-02 16:49:17 -0500 @@ -64,10 +64,14 @@ see the files COPYING3 and COPYING.RUNTI #endif #ifdef HAVE_SYSLOG_H # include <syslog.h> #endif +#if defined (_WIN32) && !defined (__CYGWIN__) +#include <wincrypt.h> +#endif + void *__stack_chk_guard = 0; static void __attribute__ ((constructor)) __guard_setup (void) { ----------------------------------------------------------------------- 06-fortran-ldflags.patch ----------------------------------------------------------------------- diff -pNar -U 5 gcc-7.1.0-current/libgfortran/Makefile.am gcc-7.1.0-working/libgfortran/Makefile.am --- gcc-7.1.0-current/libgfortran/Makefile.am 2017-01-17 03:38:48 -0600 +++ gcc-7.1.0-working/libgfortran/Makefile.am 2017-05-02 17:01:31 -0500 @@ -44,11 +44,11 @@ libgfortran_la_LDFLAGS = -version-info ` libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec $(LIBQUADLIB_DEP) cafexeclib_LTLIBRARIES = libcaf_single.la cafexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR) libcaf_single_la_SOURCES = caf/single.c -libcaf_single_la_LDFLAGS = -static +libcaf_single_la_LDFLAGS = -static -no-undefined libcaf_single_la_DEPENDENCIES = caf/libcaf.h libcaf_single_la_LINK = $(LINK) $(libcaf_single_la_LDFLAGS) if IEEE_SUPPORT fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude diff -pNar -U 5 gcc-7.1.0-current/libgfortran/Makefile.in gcc-7.1.0-working/libgfortran/Makefile.in --- gcc-7.1.0-current/libgfortran/Makefile.in 2017-05-02 07:43:57 -0500 +++ gcc-7.1.0-working/libgfortran/Makefile.in 2017-05-02 17:03:13 -0500 @@ -588,11 +588,11 @@ libgfortran_la_LDFLAGS = -version-info ` libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec $(LIBQUADLIB_DEP) cafexeclib_LTLIBRARIES = libcaf_single.la cafexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR) libcaf_single_la_SOURCES = caf/single.c -libcaf_single_la_LDFLAGS = -static +libcaf_single_la_LDFLAGS = -static -static -no-undefined libcaf_single_la_DEPENDENCIES = caf/libcaf.h libcaf_single_la_LINK = $(LINK) $(libcaf_single_la_LDFLAGS) @IEEE_SUPPORT_TRUE@fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude @IEEE_SUPPORT_TRUE@nodist_finclude_HEADERS = ieee_arithmetic.mod ieee_exceptions.mod ieee_features.mod AM_CPPFLAGS = -iquote$(srcdir)/io -I$(srcdir)/$(MULTISRCTOP)../gcc \ ----------------------------------------------------------------------- 07-ada-gnattools.patch ----------------------------------------------------------------------- diff -pNar -U 5 gcc-7.1.0-current/gnattools/Makefile.in gcc-7.1.0-working/gnattools/Makefile.in --- gcc-7.1.0-current/gnattools/Makefile.in 2016-05-16 03:55:12 -0500 +++ gcc-7.1.0-working/gnattools/Makefile.in 2017-05-02 18:13:36 -0500 @@ -195,11 +195,11 @@ gnattools-native: $(GCC_DIR)/stamp-tools $(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \ $(TOOLS_FLAGS_TO_PASS_NATIVE) \ ../../gnatmake$(exeext) ../../gnatlink$(exeext) # gnattools2 $(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \ - $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools + $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools $(EXTRA_GNATTOOLS) # gnatmake/link can be built with recent gnatmake/link if they are available. # This is especially convenient for building cross tools or for rebuilding # the tools when the original bootstrap has already be done. regnattools: $(GCC_DIR)/stamp-gnatlib-rts @@ -207,20 +207,20 @@ regnattools: $(GCC_DIR)/stamp-gnatlib-rt $(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \ $(TOOLS_FLAGS_TO_PASS_RE) INCLUDES="" \ gnatmake-re gnatlink-re # gnattools2 $(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \ - $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools + $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools $(EXTRA_GNATTOOLS) gnattools-cross: $(GCC_DIR)/stamp-tools # gnattools1-re $(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \ $(TOOLS_FLAGS_TO_PASS_CROSS) INCLUDES="" \ gnatmake-re gnatlink-re # gnattools2 $(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \ - $(TOOLS_FLAGS_TO_PASS_CROSS) common-tools + $(TOOLS_FLAGS_TO_PASS_CROSS) common-tools $(EXTRA_GNATTOOLS) # Other # ----- # Check uninstalled version. ----------------------------------------------------------------------- 08-libiberty-lrealpath.patch ----------------------------------------------------------------------- diff -pNar -U 5 gcc-7.1.0-current/libiberty/lrealpath.c gcc-7.1.0-working/libiberty/lrealpath.c --- gcc-7.1.0-current/libiberty/lrealpath.c 2017-01-04 05:30:51 -0600 +++ gcc-7.1.0-working/libiberty/lrealpath.c 2017-05-02 18:26:27 -0500 @@ -136,18 +136,30 @@ lrealpath (const char *filename) It also converts all forward slashes to back slashes. */ #if defined (_WIN32) { char buf[MAX_PATH]; char* basename; + char* slash; DWORD len = GetFullPathName (filename, MAX_PATH, buf, &basename); if (len == 0 || len > MAX_PATH - 1) return strdup (filename); else { - /* The file system is case-preserving but case-insensitive, - Canonicalize to lowercase, using the codepage associated - with the process locale. */ + /* Turn all back slashes back back into forward slashes + and don't make it all lowercase. + Rationale: + Windows is as happy with / as it is with \. This will + have been built using Cygwin, MSYS* or cross-compiled + from a system where dirsep is / so it is cleaner just + to keep the dirseps as / (and the case un-modified). + This way, the value will be consistent with the build + system and string operations (be they internal to this + software or external to it, e.g. processing map files + with sed) work as expected. */ + slash = buf; + while ((slash = strchr(slash,'\\')) != NULL) + *slash = '/'; CharLowerBuff (buf, len); return strdup (buf); } } #endif ----------------------------------------------------------------------- 09-ada-implibs.patch ----------------------------------------------------------------------- diff -pNar -U 5 gcc-7.1.0-current/gcc/ada/gcc-interface/Makefile.in gcc-7.1.0-working/gcc/ada/gcc-interface/Makefile.in --- gcc-7.1.0-current/gcc/ada/gcc-interface/Makefile.in 2017-03-28 05:29:34 -0500 +++ gcc-7.1.0-working/gcc/ada/gcc-interface/Makefile.in 2017-05-02 18:39:49 -0500 @@ -2850,17 +2850,19 @@ gnatlib-shared-default: | sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'` -shared $(GNATLIBCFLAGS) \ $(PICFLAG_FOR_TARGET) \ -o libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \ $(GNATRTL_NONTASKING_OBJS) $(LIBGNAT_OBJS) \ $(SO_OPTS)libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \ + -Wl,-out-implib,libgnat$(hyphen)$(LIBRARY_VERSION).dll.a \ $(MISCLIB) -lm cd $(RTSDIR); `echo "$(GCC_FOR_TARGET)" \ | sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'` -shared $(GNATLIBCFLAGS) \ $(PICFLAG_FOR_TARGET) \ -o libgnarl$(hyphen)$(LIBRARY_VERSION)$(soext) \ $(GNATRTL_TASKING_OBJS) \ $(SO_OPTS)libgnarl$(hyphen)$(LIBRARY_VERSION)$(soext) \ + -Wl,-out-implib,libgnarl$(hyphen)$(LIBRARY_VERSION).dll.a \ $(THREADSLIB) cd $(RTSDIR); $(LN_S) libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \ libgnat$(soext) cd $(RTSDIR); $(LN_S) libgnarl$(hyphen)$(LIBRARY_VERSION)$(soext) \ libgnarl$(soext) ----------------------------------------------------------------------- 10-libstdcpp-aligned-alloc.patch ----------------------------------------------------------------------- diff -pNar -U 5 gcc-7.1.0-current/libstdc++-v3/libsupc++/del_opa.cc gcc-7.1.0-working/libstdc++-v3/libsupc++/del_opa.cc --- gcc-7.1.0-current/libstdc++-v3/libsupc++/del_opa.cc 2017-01-26 08:30:45 -0600 +++ gcc-7.1.0-working/libstdc++-v3/libsupc++/del_opa.cc 2017-05-02 18:50:00 -0500 @@ -22,10 +22,11 @@ // a copy of the GCC Runtime Library Exception along with this program; // see the files COPYING3 and COPYING.RUNTIME respectively. If not, see // <http://www.gnu.org/licenses/>. #include <bits/c++config.h> +#include <malloc.h> #if !_GLIBCXX_HOSTED // A freestanding C runtime may not provide "free" -- but there is no // other reasonable way to implement "operator delete". namespace std @@ -48,11 +49,11 @@ operator delete(void* ptr, std::align_va { #if _GLIBCXX_HAVE_ALIGNED_ALLOC || _GLIBCXX_HAVE_POSIX_MEMALIGN \ || _GLIBCXX_HAVE_MEMALIGN std::free (ptr); #elif _GLIBCXX_HAVE__ALIGNED_MALLOC - _aligned_free (ptr); + __mingw_aligned_free (ptr); #else if (ptr) std::free (((void **) ptr)[-1]); // See aligned_alloc in new_opa.cc #endif } diff -pNar -U 5 gcc-7.1.0-current/libstdc++-v3/libsupc++/new_opa.cc gcc-7.1.0-working/libstdc++-v3/libsupc++/new_opa.cc --- gcc-7.1.0-current/libstdc++-v3/libsupc++/new_opa.cc 2017-01-26 08:30:45 -0600 +++ gcc-7.1.0-working/libstdc++-v3/libsupc++/new_opa.cc 2017-05-02 18:52:08 -0500 @@ -24,18 +24,19 @@ // <http://www.gnu.org/licenses/>. #include <bits/c++config.h> #include <stdlib.h> #include <bits/exception_defines.h> +#include <malloc.h> #include "new" using std::new_handler; using std::bad_alloc; #if !_GLIBCXX_HAVE_ALIGNED_ALLOC #if _GLIBCXX_HAVE__ALIGNED_MALLOC -#define aligned_alloc(al,sz) _aligned_malloc(sz,al) +#define aligned_alloc(al,sz) __mingw_aligned_malloc(sz,al) #elif _GLIBCXX_HAVE_POSIX_MEMALIGN static inline void* aligned_alloc (std::size_t al, std::size_t sz) { void *ptr; ----------------------------------------------------------------------- |
From: Keith M. <kei...@us...> - 2017-04-08 16:58:35
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/04/17 17:32, Earnie wrote: >>>> Going forward, we could begin to develop a proper 64-bit port of >>>> our runtime and w32api. The first roadblock, I think, is the >>>> startup code. >> >> Seems like a good place to start; we should conditionalize, to make >> it as multi-arch as possible. > > IIRC _win64 is defined as well as _win32 by the compiler. The absence > of _win64 is what can be used to indicate 32bit versus 64bit. More or less. AFAIK, the two macros are actually _WIN32 and _WIN64, (upper case matters), and *both* are defined by the 64-bit compiler; the 32-bit compiler defines only _WIN32. Thus, the structure for the conditionals becomes: #if defined _WIN64 /* 64-bit specific code here: */ . . #elif defined _WIN32 /* or maybe just #else */ /* 32-bit specific code here: */ . . #endif - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJY6RazAAoJEMCtNsY0flo/umcP/29X4f2R6FP7vm/VL0V6m9pw FiN3CVQ2TGOHJkt2McCW8td/suAsV2vPSFpcynS6xKWjHPB9c3JWcfHYMtk0HXWe hpLA7c1EyhrpdzHfC5+4F392ZRBmalFiYOXTYg3ucUzfOwO7HeDBGgKhw9Y5pq42 AQ4ZQ2VL6W5TUYYkO76lVRvbU7+1dflINEpPDaMWRjy62shMV+3gG1Z8amVt6B4I RI7Up/8VgNrcxzSrfSf5C+ZPlChR1OyeujCgWPPB9yp5KzO0YDdCAP0aH1Cw2wrt Qv6XuqccrRHs5lY5bmd/7QDZ0kGhHXAqnC3aRtH6pXxH7TwZpsDTK+TJBGHU0iF1 kf3J6PzjW+tWauYeQhPSlLoVMtrrOJdy26KxJANO/SaN1b4qkCHhQV4CR9RWvkDm xynB8NcTdK52AW5HpsJIqQfNnSwaYksu/KnpJRF8yoXKmKFtWtYhFVHhOeU1TSNO +LBe7DErPRWHetqAb5UhUe+LYVy4UZINSkBitW0iMeSdMLS8I98QY1pl7K5CZUaH lbyMyWEUFX4Y/pcv5zW7TgyBZDbJh2A5w+JMnIjwBb9TEVaNmvju527SI4DcDdZr ShsO9s5kkSlZvRaKJ0Pf+08miVtUcvp0Ye3S3tvEBCrXKUh323xM9vBEF3ygKgWJ Oi9dGi4I/trwbF/BlwRX =WvnO -----END PGP SIGNATURE----- |
From: Earnie <ea...@us...> - 2017-04-08 16:48:56
|
On 4/7/2017 3:55 PM, David Gressett wrote: > >> From: Keith Marshall <kei...@us...> > > >> On 07/04/17 14:52, Earnie wrote: >>> On 4/2/2017 3:47 PM, Cesar Strauss wrote: >>>> Following a recent thread on building a MinGW.org cross-compiler >>>> from scratch, I became curious about seeing how far I could get by >>>> targeting "x86_64-pc-mingw32" ... > ... snip ... >>>> Otherwise, we can proceed by trial and error. In that case, we can >>>> take the opportunity to properly document the process for which we >>>> arrived at the final result. If this does not work, we can later >>>> reconsider looking at their startup code. >>> >>>> This may be the better choice. > >> I agree; better to avoid the poisoned chalice. > > I am in full agreement with Keith on this. Some years ago, I was > employed as IT support in a law office where I developed software to > automate the creation of the paperwork involved in filing lawsuits, i.e, > I was generating ingredients for poisoned chalices, and I know far > more than most people know about why they should be avoided. > We would use SPI lawyers to defend our position and counter with the fact that the chalice is using our trademarked name. I do not intend to rebut this so please do not flame. I'm only stating fact to an already tender position. > As I have mentioned in previous messages to this list, I think > that the best long-term solution to navigating the Microsoft > legal minefield is to contact Microsoft and get a detailed answer as > what is permissible and what is not. The official Microsoft > philosophy about open-source software has improved > substantially in recent years, and it may even be possible > to get permission to access some license-protected > information that would otherwise be inaccessible. > Especially since they've been openly helping Cygwin including to the point of adding to the API to support them (and themselves) with a POSIX image. There have been several improvements to the API to help support the Cygwin product. -- Earnie |
From: Earnie <ea...@us...> - 2017-04-08 16:36:34
|
On 4/7/2017 5:57 PM, Cesar Strauss wrote: > > It would be nice to be able to use the 64-bit GDB from the mingw-w64 > project to step into code, but I'll try to avoid it for now. > Maybe use the Cygwin64 gdb instead? -- Earnie |
From: Earnie <ea...@us...> - 2017-04-08 16:32:18
|
On 4/7/2017 1:37 PM, Keith Marshall wrote: > On 07/04/17 14:52, Earnie wrote: >> On 4/2/2017 3:47 PM, Cesar Strauss wrote: >>> Following a recent thread on building a MinGW.org cross-compiler >>> from scratch, I became curious about seeing how far I could get by >>> targeting "x86_64-pc-mingw32" ... > > What does this oxymoron mean? 32-bit code, for use on a 64-bit CPU? > Why would I want that? Or is it just an innately stupid choice of > name? If the latter, *we* should avoid it; surely for preference it > should be "x86_64-pc-mingw64", (and "mingw64" should be adequate > shorthand). > -mingw64 already exists as a choice in config.guess and config.sub. >>> ... instead. After severely hacking at the MinGW.org runtime and >>> w32api, I finally got a 64-bit "hello world" executable which runs >>> on Wine and Windows 10. I neither looked [at] nor used any code >>> from the mingw-w64 project. > > Good. Please keep it that way. > >>> I did not try building a 64-bit DLL yet. >>> >>> 64-bit support in binutils and gcc was already there, thanks to >>> Kai's work upstream. For w32api, I used our gendef tool on the >>> Windows 10 kernel32.dll and msvcrt.dll. For the runtime, I removed >>> from the build all files with 32-bit assembly code. > > Ultimately, those will need to be converted, (or better still adapted > for multi-arch use); it may still need some work, but I added _some_ > 64-bit awareness in (e.g.) mingwex/math/log_generic.sx > >>> Also, exported symbols now have a different number of underscores. > > IIRC, the 32-bit compiler prefixes a single underscore to each public > symbol name, in generated assembly code, whereas 64-bit does not. In > hand-crafted assembly code, the additional underscore must be added > by hand. > The 64bit references also do not carry the @# suffix to indicate the argument bytes. >>> A few routines in the startup code had to be removed to avoid >>> crashes at runtime. > > Can you enumerate them, please? > >>> Going forward, we could begin to develop a proper 64-bit port of >>> our runtime and w32api. The first roadblock, I think, is the >>> startup code. > > Seems like a good place to start; we should conditionalize, to make > it as multi-arch as possible. > IIRC _win64 is defined as well as _win32 by the compiler. The absence of _win64 is what can be used to indicate 32bit versus 64bit. >> Please go forward with your work. Put it in the repository >> somewhere. > > Maybe create a "branch" for 64-bit development? > That was my thought. >>> Now, this brings the question: does our reservation against using >>> the w32api of the mingw-w64 project extends to their startup code? >>> If not, it would be much easier to simply merge back their runtime >>> code. > >> I've been waiting on Keith to respond. > > As I fully intended to do; it's just taken me a few days to acquire > a tuit of the appropriate form factor :) > I knew that, just took longer than _I_ wanted. :D >>> Otherwise, we can proceed by trial and error. In that case, we can >>> take the opportunity to properly document the process for which we >>> arrived at the final result. If this does not work, we can later >>> reconsider looking at their startup code. > >> This may be the better choice. > > I agree; better to avoid the poisoned chalice. Yes. -- Earnie |
From: Cesar S. <ces...@gm...> - 2017-04-07 21:58:08
|
On 07-04-2017 14:37, Keith Marshall wrote: > On 07/04/17 14:52, Earnie wrote: >> On 4/2/2017 3:47 PM, Cesar Strauss wrote: >>> Following a recent thread on building a MinGW.org cross-compiler >>> from scratch, I became curious about seeing how far I could get by >>> targeting "x86_64-pc-mingw32" ... > > What does this oxymoron mean? 32-bit code, for use on a 64-bit CPU? > Why would I want that? Or is it just an innately stupid choice of > name? If the latter, *we* should avoid it; surely for preference it > should be "x86_64-pc-mingw64", (and "mingw64" should be adequate > shorthand). > OK. >>> A few routines in the startup code had to be removed to avoid >>> crashes at runtime. > > Can you enumerate them, please? Sure. They are: void _mingw32_init_fmode (void); void _pei386_runtime_relocator (void); void __main(); Also, there is a weird crash when the startup calls "main", which can be avoided by calling "rmain" instead. It would be nice to be able to use the 64-bit GDB from the mingw-w64 project to step into code, but I'll try to avoid it for now. >> Please go forward with your work. Put it in the repository >> somewhere. > > Maybe create a "branch" for 64-bit development? OK. I'll put my experiment code there to gain visibility. We can clean up the patches later in a new branch, suitable for merging, if we decide to do so. >>> Otherwise, we can proceed by trial and error. In that case, we can >>> take the opportunity to properly document the process for which we >>> arrived at the final result. If this does not work, we can later >>> reconsider looking at their startup code. > >> This may be the better choice. > > I agree; better to avoid the poisoned chalice. OK. Regards, Cesar |
From: David G. <jdg...@ho...> - 2017-04-07 19:55:21
|
>From: Keith Marshall <kei...@us...> >On 07/04/17 14:52, Earnie wrote: >> On 4/2/2017 3:47 PM, Cesar Strauss wrote: >>> Following a recent thread on building a MinGW.org cross-compiler >>> from scratch, I became curious about seeing how far I could get by >>> targeting "x86_64-pc-mingw32" ... ... snip ... >>> Otherwise, we can proceed by trial and error. In that case, we can >>> take the opportunity to properly document the process for which we >>> arrived at the final result. If this does not work, we can later >>> reconsider looking at their startup code. >> >>> This may be the better choice. >I agree; better to avoid the poisoned chalice. >- -- >Regards, >Keith. I am in full agreement with Keith on this. Some years ago, I was employed as IT support in a law office where I developed software to automate the creation of the paperwork involved in filing lawsuits, i.e, I was generating ingredients for poisoned chalices, and I know far more than most people know about why they should be avoided. As I have mentioned in previous messages to this list, I think that the best long-term solution to navigating the Microsoft legal minefield is to contact Microsoft and get a detailed answer as what is permissible and what is not. The official Microsoft philosophy about open-source software has improved substantially in recent years, and it may even be possible to get permission to access some license-protected information that would otherwise be inaccessible. |
From: Keith M. <kei...@us...> - 2017-04-07 17:37:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/04/17 14:52, Earnie wrote: > On 4/2/2017 3:47 PM, Cesar Strauss wrote: >> Following a recent thread on building a MinGW.org cross-compiler >> from scratch, I became curious about seeing how far I could get by >> targeting "x86_64-pc-mingw32" ... What does this oxymoron mean? 32-bit code, for use on a 64-bit CPU? Why would I want that? Or is it just an innately stupid choice of name? If the latter, *we* should avoid it; surely for preference it should be "x86_64-pc-mingw64", (and "mingw64" should be adequate shorthand). >> ... instead. After severely hacking at the MinGW.org runtime and >> w32api, I finally got a 64-bit "hello world" executable which runs >> on Wine and Windows 10. I neither looked [at] nor used any code >> from the mingw-w64 project. Good. Please keep it that way. >> I did not try building a 64-bit DLL yet. >> >> 64-bit support in binutils and gcc was already there, thanks to >> Kai's work upstream. For w32api, I used our gendef tool on the >> Windows 10 kernel32.dll and msvcrt.dll. For the runtime, I removed >> from the build all files with 32-bit assembly code. Ultimately, those will need to be converted, (or better still adapted for multi-arch use); it may still need some work, but I added _some_ 64-bit awareness in (e.g.) mingwex/math/log_generic.sx >> Also, exported symbols now have a different number of underscores. IIRC, the 32-bit compiler prefixes a single underscore to each public symbol name, in generated assembly code, whereas 64-bit does not. In hand-crafted assembly code, the additional underscore must be added by hand. >> A few routines in the startup code had to be removed to avoid >> crashes at runtime. Can you enumerate them, please? >> Going forward, we could begin to develop a proper 64-bit port of >> our runtime and w32api. The first roadblock, I think, is the >> startup code. Seems like a good place to start; we should conditionalize, to make it as multi-arch as possible. > Please go forward with your work. Put it in the repository > somewhere. Maybe create a "branch" for 64-bit development? >> Now, this brings the question: does our reservation against using >> the w32api of the mingw-w64 project extends to their startup code? >> If not, it would be much easier to simply merge back their runtime >> code. > > I've been waiting on Keith to respond. As I fully intended to do; it's just taken me a few days to acquire a tuit of the appropriate form factor :) >> Otherwise, we can proceed by trial and error. In that case, we can >> take the opportunity to properly document the process for which we >> arrived at the final result. If this does not work, we can later >> reconsider looking at their startup code. > > This may be the better choice. I agree; better to avoid the poisoned chalice. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJY585BAAoJEMCtNsY0flo/TZcP/2I307Ri46RpLjbw4Nn2kgRb 0Gd+7aKqFgOKcmV54FXy/TX+qnIeGnYlgm6cLzq96B2QBtSgg0xlpoa9NXjflVDT jYj4WP/v2fVVZzwTjukMI9ZjuBWt/eYhKvjvjzXon0ciZ9/VmNt/jd1pr7/oH0wG NLLsOOROZcw4pVy8iMBWjJ8jbpYhgegsYtEqMBY1QOaG9sO2EplwD7j3NExHqHfA G4vNDBIAO+0opv7tJQLC+7ioFd5uPEUMX67VwYOVFeJaRlG6nDpAafF54WYKI0mQ ye9pJUUr+yVGofs0IBN0juYCKJpdtDFBZAwPdXdVdD8UjE6tWwlJ5MzC1e/VbBJz LmQd11RPUFZNia150rjGeGpacxaVYJyZ/ZzUPXhm/UUTjgYwtW+PzMUPDsJbXbTG vJYQisNhmGnp6pWh1brRo+oG7ANR9jOMQdYYDcNO/g2Ka5NwEjFfbAQeEGvm43D7 MzJm1M+pgtsm0Phv+1BXtReTDqAzxsun5WZbAXyBmEPB8HiXTm8tGcUTglofiMbO MrTqSFDFn/2uPGiMOJGcwKQktSg/D9cfEaTxQVnUbxUVUUaP2LqouMo+PjHB1lsd 9RcWhbBDAOl+SguNRtkA1o5gQgeepKHzRd0lhtHVHuaR2w8YkKndCtQdRb1vJ2PP pXGw3WvWNsDL5NqlmNre =Fsfm -----END PGP SIGNATURE----- |
From: Earnie <ea...@us...> - 2017-04-07 13:52:23
|
On 4/2/2017 3:47 PM, Cesar Strauss wrote: > Hello, > > Following a recent thread on building a MinGW.org cross-compiler from > scratch, I became curious about seeing how far I could get by targeting > "x86_64-pc-mingw32" instead. After severely hacking at the MinGW.org > runtime and w32api, I finally got a 64-bit "hello world" executable > which runs on Wine and Windows 10. I neither looked nor used any code > from the mingw-w64 project. I did not try building a 64-bit DLL yet. > > 64-bit support in binutils and gcc was already there, thanks to Kai's > work upstream. For w32api, I used our gendef tool on the Windows 10 > kernel32.dll and msvcrt.dll. For the runtime, I removed from the build > all files with 32-bit assembly code. Also, exported symbols now have a > different number of underscores. A few routines in the startup code had > to be removed to avoid crashes at runtime. > > Going forward, we could begin to develop a proper 64-bit port of our > runtime and w32api. The first roadblock, I think, is the startup code. > Please go forward with your work. Put it in the repository somewhere. > Now, this brings the question: does our reservation against using the > w32api of the mingw-w64 project extends to their startup code? If not, > it would be much easier to simply merge back their runtime code. > I've been waiting on Keith to respond. But > Otherwise, we can proceed by trial and error. In that case, we can take > the opportunity to properly document the process for which we arrived at > the final result. If this does not work, we can later reconsider looking > at their startup code. This may be the better choice. -- Earnie |
From: Earnie <ea...@us...> - 2017-04-03 15:17:04
|
On 4/2/2017 5:28 PM, NightStrike wrote: > On Sun, Apr 2, 2017 at 3:47 PM, Cesar Strauss <ces...@gm...> wrote: >> Hello, > [..] >> I neither looked nor used any code >> from the mingw-w64 project > [..] >> For w32api, I used our gendef tool on the Windows 10 >> kernel32.dll and msvcrt.dll. > > ....*YOUR* gendef tool? Earnie copied all of Kai's code and stuck it > in your repository, then changed all the licenses. It's completely > stolen. > I don't remember changing licenses but the version I copied was a different license than the one today. >> Going forward, we could begin to develop a proper 64-bit port of our >> runtime and w32api. > > ....*PROPER* ? There's nothing wrong with our port. > >> Now, this brings the question: does our reservation against using the >> w32api of the mingw-w64 project extends to their startup code? If not, >> it would be much easier to simply merge back their runtime code. > > Continuing Earnie's trend of stealing without credit? > If there is missing credits that can be resolved. -- Earnie |
From: Cesar S. <ces...@gm...> - 2017-04-02 22:30:55
|
Dear Nighstrike, By your response, I see I have made a poor choice of words in a few instances. I sincerely apologize. It was not truly my intention. Please let me clarify. On 04-02-2017 18:28, NightStrike wrote: > On Sun, Apr 2, 2017 at 3:47 PM, Cesar Strauss <ces...@gm...> wrote: >> For w32api, I used our gendef tool on the Windows 10 >> kernel32.dll and msvcrt.dll. > > ....*YOUR* gendef tool? Sorry, I did not meant to claim authorship of Kai's work. What I meant was: "For w32api, I used Kai's gendef tool, distributed by us (not the mingw-w64 gendef, which is more recent), on the Windows 10 kernel32.dll and msvcrt.dll" >> Going forward, we could begin to develop a proper 64-bit port of our >> runtime and w32api. > > ....*PROPER* ? There's nothing wrong with our port. Sorry, I didn't mean to imply the mingw-w64 port was not proper. Let me rephrase: "Going forward, we could begin to develop a proper 64-bit port of our runtime and w32api, as opposed to my quick hack, which is not a proper port by any means." Sorry again for any confusion on my part. Thank you for calling attention to these issues. Best regards, Cesar |
From: Cesar S. <ces...@gm...> - 2017-04-02 19:47:30
|
Hello, Following a recent thread on building a MinGW.org cross-compiler from scratch, I became curious about seeing how far I could get by targeting "x86_64-pc-mingw32" instead. After severely hacking at the MinGW.org runtime and w32api, I finally got a 64-bit "hello world" executable which runs on Wine and Windows 10. I neither looked nor used any code from the mingw-w64 project. I did not try building a 64-bit DLL yet. 64-bit support in binutils and gcc was already there, thanks to Kai's work upstream. For w32api, I used our gendef tool on the Windows 10 kernel32.dll and msvcrt.dll. For the runtime, I removed from the build all files with 32-bit assembly code. Also, exported symbols now have a different number of underscores. A few routines in the startup code had to be removed to avoid crashes at runtime. Going forward, we could begin to develop a proper 64-bit port of our runtime and w32api. The first roadblock, I think, is the startup code. Now, this brings the question: does our reservation against using the w32api of the mingw-w64 project extends to their startup code? If not, it would be much easier to simply merge back their runtime code. Otherwise, we can proceed by trial and error. In that case, we can take the opportunity to properly document the process for which we arrived at the final result. If this does not work, we can later reconsider looking at their startup code. Regards, Cesar |
From: David G. <jdg...@ho...> - 2017-03-15 16:04:47
|
The bug that is fixed in gcc 6.3.0 is in the GCC Bugzilla as bug report 70684. a patch is in Comment 7: ----------------------- diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c index e24b3922..b8e174c5 100644 --- a/libgfortran/io/list_read.c +++ b/libgfortran/io/list_read.c @@ -197,7 +197,7 @@ check_buffers (st_parameter_dt *dtp) } done: - dtp->u.p.at_eol = (c == '\n' || c == EOF); + dtp->u.p.at_eol = (c == '\n' || c == '\r' || c == EOF); return c; } ------------------------- The other patch is the one for the undefined items; ---------------------------- diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.am gcc-5.3.0-working-m64/libgfortran/Makefile.am --- gcc-5.3.0-current/libgfortran/Makefile.am 2014-11-28 11:39:15 -0600 +++ gcc-5.3.0-working/libgfortran/Makefile.am 2015-12-27 17:21:46 -0600 @@ -44,13 +44,13 @@ libgfortran_la_DEPENDENCIES = $(version_ myexeclib_LTLIBRARIES = libgfortranbegin.la myexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR) libgfortranbegin_la_SOURCES = fmain.c -libgfortranbegin_la_LDFLAGS = -static +libgfortranbegin_la_LDFLAGS = -static -no-undefined libgfortranbegin_la_LINK = $(LINK) $(libgfortranbegin_la_LDFLAGS) cafexeclib_LTLIBRARIES = libcaf_single.la cafexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR) libcaf_single_la_SOURCES = caf/single.c -libcaf_single_la_LDFLAGS = -static +libcaf_single_la_LDFLAGS = -static -no-undefined libcaf_single_la_DEPENDENCIES = caf/libcaf.h libcaf_single_la_LINK = $(LINK) $(libcaf_single_la_LDFLAGS) diff -pNaur gcc-5.3.0-current/libgfortran/Makefile.in gcc-5.3.0-working-m64/libgfortran/Makefile.in --- gcc-5.3.0-current/libgfortran/Makefile.in 2015-12-04 04:47:53 -0600 +++ gcc-5.3.0-working/libgfortran/Makefile.in 2015-12-27 17:21:46 -0600 @@ -610,12 +610,12 @@ libgfortran_la_DEPENDENCIES = $(version_ myexeclib_LTLIBRARIES = libgfortranbegin.la myexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR) libgfortranbegin_la_SOURCES = fmain.c -libgfortranbegin_la_LDFLAGS = -static +libgfortranbegin_la_LDFLAGS = -static -no-undefined libgfortranbegin_la_LINK = $(LINK) $(libgfortranbegin_la_LDFLAGS) cafexeclib_LTLIBRARIES = libcaf_single.la cafexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR) libcaf_single_la_SOURCES = caf/single.c -libcaf_single_la_LDFLAGS = -static +libcaf_single_la_LDFLAGS = -static -no-undefined libcaf_single_la_DEPENDENCIES = caf/libcaf.h libcaf_single_la_LINK = $(LINK) $(libcaf_single_la_LDFLAGS) @IEEE_SUPPORT_TRUE@fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude ------------------------------------ |
From: David G. <jdg...@ho...> - 2017-03-13 03:27:51
|
On March 12, 2017 4:26 PM Earnie wrote: >On 3/12/2017 9:26 AM, Cesar Strauss wrote: >> On 03-12-2017 06:50, Keith Marshall wrote: >>> How should we best deal with reports of probable erroneous MSDN content >>> such as: https://sourceforge.net/p/mingw/bugs/2248/ ? >>> >>> Here, the poster provides an acceptable test case, which demonstrates >>> that the MSDN information is most likely incorrect, but can refer us >>> only to known sources of plagiarised Microsoft header file content, to >>> support his proposed correction. Obviously, we cannot examine those >>> plagiarised sources, but should we just take his word for it, and >>> correct our headers, as he suggests? >>> >>> Opinions? >> >> It would have been best if the reporter had found the correct prototype >> by trial and error. We cannot do that now, since we already know the answer. >> >> You could argue that the correct prototype is now found in "publicly >> available documentation". Which, in this case, is the text of the bug >> report itself. We already consider Internet references like blog posts >> as "publicly available documentation", if I am not mistaken. You could >> add this on top of your patch: >> >> "MSDN is wrong. The correct type for parameter X is Y according to >> https://sf.net/..." >> >> On the other hand, for such a small change, it could also pass as "fair >> use" instance, even if the source itself is copyrighted. >> >> Maybe make the "documentation or references" requirement more explicit >> on the bug reporting page. We do link to >> http://www.mingw.org/reporting_bugs, but it is a bit buried in there. >> Maybe write a dedicated page, like the one on >> https://wiki.winehq.org/Clean_Room_Guidelines >> >I think we just take the issue on its word value and make the change. I >think MS would be fine with it based on their activity in Cygwin. A bug >report should be filed with MSDN for the invalid documentation by the >original poster and the MSDN ticket given in the bug report ticket.. The safest (but not very satisfactory) solution to the problem is to wait for Microsoft's response to a bug report. The official MinGW position on on Microsoft header snooping is well-documented and making the change would seem to me to be a violation of that policy Another solution would be to go directly to Microsoft, show the official policy to Microsoft (and also how it contrasts with the MinGW-64 philosophy) and try to get some cooperation with Microsoft on getting information that would otherwise be locked away from MinGW use by Microsoft licenses. An interesting situation has developed in Windows 10 that might cause Microsoft to look at this: the arrival in Windows 10 of Bash on Ubuntu on Windows. If I start the Ubuntu bash on my Windows 10 computer and do apt-cache search MinGW I get a substantial list of MinGW-64 packages. There are cross compilers in that list which certainly contain headers which have contents which might cause some cognitive dissonance in the Microsoft legal department, especially since the headers can be obtained using the Microsoft-supplied Ubuntu Bash and other Ubuntu tools running on a Microsoft-designed Linux emulation. The existence of Bash on Ubuntu on Windows shows that Microsoft has become much more tolerant of open-source software, and opening a good communication channel with Microsoft that might solve license-related problems seems to me to be the best long-term solution to development problems like this MSDN error. |
From: Earnie <ea...@us...> - 2017-03-12 21:26:51
|
On 3/12/2017 9:26 AM, Cesar Strauss wrote: > On 03-12-2017 06:50, Keith Marshall wrote: >> How should we best deal with reports of probable erroneous MSDN content >> such as: https://sourceforge.net/p/mingw/bugs/2248/ ? >> >> Here, the poster provides an acceptable test case, which demonstrates >> that the MSDN information is most likely incorrect, but can refer us >> only to known sources of plagiarised Microsoft header file content, to >> support his proposed correction. Obviously, we cannot examine those >> plagiarised sources, but should we just take his word for it, and >> correct our headers, as he suggests? >> >> Opinions? > > It would have been best if the reporter had found the correct prototype > by trial and error. We cannot do that now, since we already know the answer. > > You could argue that the correct prototype is now found in "publicly > available documentation". Which, in this case, is the text of the bug > report itself. We already consider Internet references like blog posts > as "publicly available documentation", if I am not mistaken. You could > add this on top of your patch: > > "MSDN is wrong. The correct type for parameter X is Y according to > https://sf.net/..." > > On the other hand, for such a small change, it could also pass as "fair > use" instance, even if the source itself is copyrighted. > > Maybe make the "documentation or references" requirement more explicit > on the bug reporting page. We do link to > http://www.mingw.org/reporting_bugs, but it is a bit buried in there. > Maybe write a dedicated page, like the one on > https://wiki.winehq.org/Clean_Room_Guidelines > I think we just take the issue on its word value and make the change. I think MS would be fine with it based on their activity in Cygwin. A bug report should be filed with MSDN for the invalid documentation by the original poster and the MSDN ticket given in the bug report ticket.. -- Earnie |