Menu
▾
▴
mingw-dvlpr
|
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: 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: 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-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: Keith M. <kei...@us...> - 2017-05-30 20:06:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/05/17 20:11, Keith Marshall wrote: > I see: > > gcc/ada/rts/libgnarl.a > gcc/ada/rts/libgnat.a > > but no corresponding DLLs or .dll.a import libraries I submitted: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921 - -- 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) iQIcBAEBAgAGBQJZLdDAAAoJEMCtNsY0flo/8j8QAIYSzBvtJLKItPUrxzCKgj66 JKiqCsQZJKBLRp3mmnzAbmBZjXsXJc40SUMuj6rT/a2evbAbI4KXnzE7Hsr9G1Ho TMc+qswkMPQdLhg2RHFOe3GbeYcAsVoRwMdDw1+BXQUxoYEYsakfQCGcJEIkdCwQ rKuFk7g7B6wY8TMuvhpr/HebOLtB/uI16hMmaxea2jm849rIcddOLJ/X+Cyiw6lV E4oSxNiKpkZ17aIR559cSyls/z6YPQuQMKrAKZbHighTtpmPzbdFSvDsRJMjAm3s QThZ8sdl+0M8zMZCATPonq4uLXR/xFD4QEbayar6VvYQSlh/W6+Z97i+ZbBjBzF7 0HtLN9A6fL3PDfAKU2XPo8myo1ukK+Zq9Z1fGZrFZ4e6ddDmDbU5ZE/h1Dj2cO+0 ea8yPYekjJKEIduGge35SguK7Y3jwKVRmGSdRcoMwbXhDOSUJxHZd7QJxpAiWAcZ YBzmpqIO2/zYSln2COX5imnahyEZBWkQiun9i/HCUCAJjj9newO/qUHHJjBeOd8e tYHXQVwPcQGrDQhyupE/lKbpt/9H/Dq5k9q2tjk/rX46Elf3peiTFN5Hdiz5R+Cf l51TRK66AChRIUUNEa05XljjMLpMOJdDZq922iV0xnQa6r5XuEOlvtlHHN0neru/ bf+Rqxw6IGXwWqQ2wT1O =cIrV -----END PGP SIGNATURE----- |
|
From: David G. <jdg...@ho...> - 2017-05-30 20:06:11
|
OnTuesday, May 30, 2017 2:11 PM Keith Marshall wrote >On 30/05/17 18:31, David Gressett wrote: > > > On Sunday, May 28, 2017 10:48 AM Keith Marshall wrote: > ... snip ... >>> [*] 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 my build tree, i do have the corresponding DLLs and import libraries in gcc/ada/rts. >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: I see the same conditional attempts. ( I am looking at the results of "make install-strip", so some parts are different) In my case they succeed, since I do have the pieces that your build tree does not have. > cp: cannot stat ‘rts/standard.ads.h’: No such file or directory >which may be (potentially) more disturbing. I do not have that. Does your build tree contain gnatdll.exe? if not, the patch that enables its construction may not have happened. If it does exist, does your install log show an attempt to install it? In my install-strip log, a set of twelve gnat tools (gnatbind, gnatchop, gnat, etc are installed in a loop; a few lines down, I see gnatdll.exe installed separately. |
|
From: Keith M. <kei...@us...> - 2017-05-30 20:41:28
Attachments:
11-libobjc-install-strip.patch
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/05/17 21:06, David Gressett wrote: >> cp: cannot stat ‘rts/standard.ads.h’: No such file or directory >> >> which may be (potentially) more disturbing. > > I do not have that. > > Does your build tree contain gnatdll.exe? Yes, as gcc/gnatdll.exe > If it does exist, does your install log show an attempt to install > it? A successful attempt; it appears at $prefix/bin/gnatdll.exe. It is also installed (incorrectly) into my cross-compiler tree, as gnatdll, whereas it should be installed as mingw32-gnatdll. > In my install-strip log, a set of twelve gnat tools (gnatbind, gnatchop, > gnat, etc are installed in a loop; These are also installed, for me, and (correctly) named with the host prefix, in the cross-compiler tree ... > a few lines down, I see gnatdll.exe installed separately. ... and it is presumably in that separate installation, that the host prefix is omitted, in the cross-compiler installation. FWIW, I used "install-strip" too, when staging the distribution, but, cognizant of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720, I also checked the effect of "install", in case there was a similar omission for the Ada DLLs. I also included the attached patch, to correct the (long-time ignored) PR-54720 bug, in *our* distribution. The "cannot stat rts/standard.ads.h" issue is evident in both my install and install-strip logs. - -- 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) iQIcBAEBAgAGBQJZLdjvAAoJEMCtNsY0flo/No8P/RLz+93l9EEEQIopuaNXh47h bcOuIfIiFODr4r6ilMAlNUgGCLm6EtXUpvZAv/yVCbRvjxGVby8P+Fca1zZ3ufI5 ovfkg7LJ/HlFOuLoZFQ5BvgJrDj66WBIkaxfG3O+04uxZgwu+1jiwedy0GdCUKSa soe63Gdx5yKTgHEGR+dyLgTbC+fy3mv5ysPngbv5ZJuoaZa4Q17tMrgC7JSMDWr+ vC9/KxntJE1JXji9NbFjpqGSMy3zAoo0yKn5OliLHmwqdUpREtS63beaqtU4oGrj yc/wnFH6O8/yyxFUWYreiLlIwkLM4ZGrybY5qnQ1HxRd6qUJM1LKkpVJLmc2ZskS 1IJ3vRpXgB2Y1gTMQH15ixWIDLMoVrCxO8qBlzbIBNRxMEPokXRA49u0Bdfx7HCI 9W8Hiki2zgvZUDujI6ZXzRDfrzr3j7pFZgyvLFN31VU1H7ofy7zjIxSVafWE+Odx gznzvJQr7ECFZ+pAnC1/o9g6NES4eACtSaX76nlh+6vRtjIa2PnAldWAClViWw+U o/QwquE3M+3RIOaaOUrb8rbIMHENx26g6zUoht57OI0zVHC4Qf4HtjdT1HdJxp0z qtfVSbebj2G/d4YxzNcgV0ehc6fbzI5kRGltjmPB2c0cw5EDHJCkKWaJm4TFXW5o lJJHzR2uIuz7dpLNc/kS =pkoq -----END PGP SIGNATURE----- |
|
From: Keith M. <kei...@us...> - 2017-05-30 21:27:45
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/05/17 21:41, Keith Marshall wrote: > The "cannot stat rts/standard.ads.h" issue is evident in both my install > and install-strip logs. Further investigation reveals that, at some point in the build phase, a symbolic link has been created at $top_builddir/gcc/ada/standard.ads.h; it refers to non-existent $top_srcdir/gcc/ada/standard.ads.h, and the "cannot stat" issue arises when attempting to resolve that symbolic link during the install (or install-strip) phase. - -- 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) iQIcBAEBAgAGBQJZLePJAAoJEMCtNsY0flo/1IgQAKDxHRJSr/CRYnrziIHfLtFF /4ouuyIk84Sneq9IjJrGZVR5RTxsnIm3e7c/hNh3KTuJxiqpqi6od4TjMs4zeXCd rAD7q1NqyWI0rzOxzdyhdf68HNg55k2S8SXK+R3Hsvy81vGN5Ac5t9ZvjV/w8VUk jmjeB41jvZB2j0NPLfsVD0ySl3e7GfvzwSEyRn9LC0B7ijN5lpd/X3CXQxtMPH/R 706KJuDylajkLGjmGdI9WY388ZPYv9LjIyt2M01f+9sKoYKsI133OHc3klePcyjM kpV42R3c+f002iAoxuJ/DG6Gd+gso3Gm/OwPAq8TBWsc3yfwTaSTFdaddDXWRKUu GSRcCH1yiSubU8c63AmDaaC+x4WDBrEMB4L3vVqlqyCOdWNuNiSu983XKeVDe2Uh /r+H2TAhwI5fZrpcc5geJO2sFH5DECb2PahuUPSyNnGT7zORjSYRC+RmAF0MQGiu Igr3SJ4D+5+VQHu985hVOwCeD22LUX8fKPkm2iFuHzDMbp3KIkaghnb9+6ABCSPE j2ilysKSNmmS/ogOrAhAtxXSAh/R6Xk+yCOD7uOxunKiT2C979DfHVEz9mT8SnnX ekAPFfSTW2Gvwui/nX8lohe91CpCFOQQPmknCo9o4ILcMUgBnxGRIovmo3sKpRJD f0cR/JHCm7+SgwXyyzem =H3uI -----END PGP SIGNATURE----- |
|
From: David G. <jdg...@ho...> - 2017-05-30 23:58:51
|
On Tuesday, May 30, 2017 3:41 PM, Keith Marshall wrote >On 30/05/17 21:06, David Gressett wrote: >>> cp: cannot stat ‘rts/standard.ads.h’: No such file or directory >>> >>> which may be (potentially) more disturbing. >> >> I do not have that. >> >> Does your build tree contain gnatdll.exe? >Yes, as gcc/gnatdll.exe >> If it does exist, does your install log show an attempt to install >> it? >A successful attempt; it appears at $prefix/bin/gnatdll.exe. It is also >installed (incorrectly) into my cross-compiler tree, as gnatdll, whereas >it should be installed as mingw32-gnatdll. It installs for me as gnatdll.exe >> In my install-strip log, a set of twelve gnat tools (gnatbind, gnatchop, >> gnat, etc are installed in a loop; >These are also installed, for me, and (correctly) named with the host >prefix, in the cross-compiler tree ... I get the same thing , with the host prefixes, which are incorrect for a native build; I fix them manually after the build completes. There are several executables that get a host prefix from another source, and so get a double dose; for example, i get mingw32-mingw32-gcc.exe, which I rename to mingw32-gcc.exe. The configure system seems to have a problem getting the differences between a native and cross build exactly right. I see other signs of this when I build gcc with gmp, mpfr, and mpc in-tree; I get warnings in my compile log that I am using cross tools not prefixed with the host triplet and that the none host is obsolete. This does not happen when I build the gmp, mpfr, and mpc DLLs as standalone builds. I get compilers that work, however, even with the GCC-7.1.0 builds. >> a few lines down, I see gnatdll.exe installed separately. >... and it is presumably in that separate installation, that the host >prefix is omitted, in the cross-compiler installation. ... and is also omitted for me in my native installation. It looks as if in both cross and native builds, the set of twelve get the prefix and the single gnatdll does not, with different consequences for the Ada DLLs. This leads me to believe that your failure to get the Ada DLLs is the result of the cross build system looking for mingw32-gnatdll and not finding it in the compile part of the build, but my native build looks for gnatdll and finds it. My guess: Those parts of the GCC compiler collection that are used in the middle of the compile process are built early on with the prefix because the cross build needs to use them. gnatdll is handled separately, and incorrectly at one crucial point. The same screwup happens in the native build and accidentally works. ... snip ... |
|
From: Keith M. <kei...@us...> - 2017-06-01 18:03:47
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/05/17 00:58, David Gressett wrote: > This leads me to believe that your failure to get the Ada DLLs > is the result of the cross build system looking for mingw32-gnatdll > and not finding it in the compile part of the build, ... No; although incorrectly installed as gnatdll, I linked that (by file system hard link) to the correctly named mingw32-gnatdll, so it should be found. In any case, there's no evidence in any config.log, nor in my build.log, that there was any attempt to find it. The real cause of the problem is a bogus (utterly nonsensical) test in libada/configure, (requiring $build == $target), which effectively disables building of shared Ada libraries[1]; once I remove that test, I do get libgnat-6.dll and libgnarl-6.dll, (but corresponding import libraries are not built, because there is nothing in the corresponding Makefile to build them). [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921 - -- 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) iQIcBAEBAgAGBQJZMFb+AAoJEMCtNsY0flo/IjsQALFQfcPIiVGPcWySnhCRZFdk KxWiKblq+phJJ5s5dWqDSiiMqYgxLJvPsEHDh8Kw2bYqv9ANIuPSOXmPuZYzAL/I gVFjZR0ulH8GIM3DJKfo/mGFDC860O0eFK20uF4475OJ33wWmMA3CeojVrjs86nd NOsmSy6GQgjFN6AXZRoZZ5gMhqIQEpe7Kzl2PcR4Wd1s1Q/3BBI5cAKv0xM33kb5 tBgzP5/h9UfIVuX3vZAMMg9v+lRTX0wSs3OtRr2qxrBjOSsX2dlGWOAJOKdg5LyH dNfAqI7wiL0r7gEhobEut8/qbqzpZuekpsRloqTrMBOSBKkO7Jm0k68IMXcdM18U niSh4tqfVJB0Hlc0UpnPeIeRyggp1y59CizzRjgobLskl1CvmamonrggI9OziWMw 3sbWIuWAJFqDAxs33yoOFa18zaO+L5IptjzN36G+hZFsvxGzf/YupTy7Y+dWuCDh 27YuYTGcA2ME/piyI5J9xx8YiqbzUgyAuTfzVMvf6QiWUO1LKPsBYqPLOhwyQWSb 4ErqrzK0aoc3gZ9QanyjHyFCLqf/t7qmHI6w+1AXLwbg8zqbn3Vhz33Hr4GXCt5y HVM81HtZaT7svG8FTisfAuufCdCULuoEQiwI7kGoBR6MmA6zrnkjd3ndFbXvJKgv PxWvbPFC9LDdRmN8mngo =zNv9 -----END PGP SIGNATURE----- |
|
From: Keith M. <kei...@us...> - 2017-06-02 20:58:51
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David, On 01/06/17 19:03, Keith Marshall wrote: > I do get libgnat-6.dll and libgnarl-6.dll, (but corresponding > import libraries are not built, because there is nothing in the > corresponding Makefile to build them). I note that "make install-strip" does not strip these DLLs; should it? (Ditto, for libgcc_s_dw2-1.dll). I can hack the Makefile.in to create import libs. Do we need them? (The upstream maintainer says we don't). I also note that "make install", (or "make install-strip"), sequesters all gnat libraries, whether static, import, or DLL, in: $prefix/lib/gcc/mingw32/6.3.0/adalib/ I assume that the gnat tools expect to find them there, but surely any dynamically linked application, built with them, will need the DLLs in a runtime path? Where should mingw-get install them? Come to that, how do the gnat tools select between static and dynamic linking? (The GNU linker will not associate, say, libgnat-6.dll with -lgnat, so if we do not provide libgnat.dll.a, surely it will pick libgnat.a, which is a static library). Does this imply that gnat applications always default to static linking? - -- 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) iQIcBAEBAgAGBQJZMdGBAAoJEMCtNsY0flo/enIQAL3jdoxNpO7t0/6DOaKEij3Z nL35JavMBOcbFeBIz6/sibZCmZPXI/hXXU5dfzAx2TtKjzl/U7+9hfLWYfeaFvgC 9fEPh/TCoyQzQY2mAW6XI++jFbLyQC84K3KTcWPnL2xX130vnpRv69pyqurQvE+M HtvKym3lcvdRJZeBh5Iis8oP2aWMVDM4TaYVOya9TO26ATtpFTsSOAYRaOOVbk/I bBY6mlh5jsAQO+fVnV+ppYLvasADC5oNuGC8xmSH1HobX2n7Iu9d2PbfEjmBXz7M gfrLy2kulBWITBYz5OcHOVaqYZyYF52y+6SQhIyqgTlL0tzQHsEKr2Yu2uWS0SOq 92uEpuqQjfRPVz+ADUI9X4dSzrPD8Sjh3hzVbnvl22EreIJi4fCYJtS8gPzIfU8U gGkmXpGOh3sLOYlsRvV2y5BlhBpH/PGxyTjhLuBSbNE3NUqw8ntm85F6+vFgt9yy qHaEjgjSvmRSdVqNh/agaVRqe7YL5FY7Oee8bD8L3+dUIS26ZvYr9d03oJEaBt1x vLh1p6jGWyh9CxR7I2c0H2YX9tcxdr5tcl+SEwL6zetlBZ07c8SnurjCEPdNeIo6 CbD7tdD9Zr97zSeoGUqLr0ROF242LBmaT4arv/OyR3d59Rt/JJdOwiAkr6CMGGym Inf1qlKi1u3Kc3xmApEM =eGoB -----END PGP SIGNATURE----- |
|
From: David G. <jdg...@ho...> - 2017-06-03 16:14:13
|
On Friday, June 2, 2017 3:58 PM, Keith Marshall wrote: >David, >On 01/06/17 19:03, Keith Marshall wrote: >> I do get libgnat-6.dll and libgnarl-6.dll, (but corresponding >> import libraries are not built, because there is nothing in the >> corresponding Makefile to build them). >I note that "make install-strip" does not strip these DLLs; should it? >(Ditto, for libgcc_s_dw2-1.dll). No, stripping an Ada DLL will cause it to lose its relocatability. >I can hack the Makefile.in to create import libs. Do we need them? >(The upstream maintainer says we don't). It wouldn't hurt to have them, but I expect that any use of them would be very , very infrequent. >I also note that "make install", (or "make install-strip"), sequesters >all gnat libraries, whether static, import, or DLL, in: > $prefix/lib/gcc/mingw32/6.3.0/adalib/ >I assume that the gnat tools expect to find them there, but surely any >dynamically linked application, built with them, will need the DLLs in >a runtime path? Where should mingw-get install them? Come to that, how >do the gnat tools select between static and dynamic linking? (The GNU >linker will not associate, say, libgnat-6.dll with -lgnat, so if we do >not provide libgnat.dll.a, surely it will pick libgnat.a, which is a >static library). Does this imply that gnat applications always default >to static linking? Static linking is the default. I never do dynamic linking, so I don't remember the gnat tool syntax needed; there is a specific command-line option used to dynamically link the runtime, but you would have to find it in the Ada user guide. The libgnat and libgnarl DLL's should be left where "make install" puts them. You could put copies in some place easier to find for people who need to distribute them, but documentation that shows where they are to be found would be adequate. |
|
From: Keith M. <kei...@us...> - 2017-06-04 12:19:49
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/06/17 16:47, David Gressett wrote: > Static linking is the default. I never do dynamic linking, ... I wonder how many MinGW users actually use Ada? Of those who do, I wonder if *any* link the gnat runtime dynamically? > The libgnat and libgnarl DLL's should be left where "make install" > puts them. Looking back to the previous releases, which are still visible on our FRS download pages[1], it was done thus up to v4.3.0, with just one Ada package for each release; thereafter, the DLLs were moved their own separate package, and in the process they were relocated from their default $prefix/lib/gcc/mingw32/[version]/adalib installation path, to $prefix/bin. That relocation would have moved them away from where the gnattools would have expected to link them, making it even less likely that any Ada application would have been linked to depend on them; no existing distribution has provided corresponding import libs, which might have mitigated the effect of relocation. > stripping an Ada DLL will cause it to lose its relocatability. FWIW, I haven't checked them all, but the distributed libgnat-4.7.dll *was* stripped; did that create problems for users of that release? I don't remember any having been reported, but maybe that's simply because no one ever used them. [1]: Those which actually included gnatlib DLLs; GCC-3.x appears not to have done so; neither did any of my cross-compiled releases, from GCC-4.8.2 onwards. Furthermore, while GCC-3.x *did* include the gnatdll.exe tool, that appears to be missing from the GCC-4.x and later releases. - -- 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) iQIcBAEBAgAGBQJZM/rcAAoJEMCtNsY0flo/E4MQALnKFy1yNkzzXEXgfC1Zu+xL xUtjc5E+VF1hWpLzgl7cAhyRFX8N6Wr8jd1HyYMBrSgA4ZJvtJQMKjTpAKULD/Lw 5hQ6B4dd2d+bTmON/DGxpHW5ggluBwzMlZEaVCgHWzObhF2k7hrSxrW8vmO6Q5rE Ob42oY+A+bPyX58HE9p1YD7QVhYPfk7fqosPWIfdrNLmpxZHrhXbQtr2lPFjqW51 qJOsF0dcy+1iM3glnNt5arkCJ/KiRL/NDFf7mJGDPJY2PacboCqSWOo+fndhNW40 8bmZ0P+RJtd/ruu3xjeYMCNguwADPnJRj+Idg8M5ERogdCtZ4iyxveko5udBC1KH rt5dQgEbVwaDL+b3GaQ3e98I7JvS9OupSlq74QebS5jGYby42qmHKoXNaT0b74lG Qf9Kc5O21d6AOzs/Hf+oeN4yrRu6VZKaq4sLHJhIEmNesq5G5Rq08SvxHe0jiKRr zmEv/5zIetTfdNb/KFFZIyo6+4RaluLsQmWK/KLTaAQQDBElaTZDD/B5iqaGvz35 xWWK7UIaVkoWa6srW6HoJp9fmshUrgOYZqgF0jKj6IS4kGstCl78dLh7cZXv7Q3r jhnTwxUoQfi5izJZxkhfog+jHtr4HrWOU8QZvoFPAn0VDryZh+kSspD+YE7NPG8T Y/y4d/M1SkMeorJBUrTP =DVeX -----END PGP SIGNATURE----- |
|
From: Keith M. <kei...@us...> - 2017-06-03 19:21:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/06/17 16:47, David Gressett wrote: >> I note that "make install-strip" does not strip these DLLs; should >> it? (Ditto, for libgcc_s_dw2-1.dll). > > No, stripping an Ada DLL will cause it to lose its relocatability. Why? I don't understand. Surely all Windows DLLs are inherently relocatable? Stripping doesn't modify the relocation tables, so why would it have any such effect? - -- 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) iQIcBAEBAgAGBQJZMwwjAAoJEMCtNsY0flo/SgwQAI0hgM1656xjqZqIKwWRgzET W/ZEralDrzXIEzAAOb9+C068LeXs32fBcQMqglIC61E1+lVAqHva3JZn4X9GZJwI y/Yas9rsEQF7tn8/WLUQBTpgCfGdvQwGvmnMCBBJChGbUaLGIlvtq4+ct9cI0ou6 obt8ZEjH5xfs9AiudkrWdP18TuoeLwykNb9mAYL4le/LZM6fqSeLj1C2X++21ZpT TnTKSR7ins8GfBaMBg9J/NVZqM5pR3ijSFRKb4tnukCKOJCEzeQ90hKqoTFefc51 9PtG1s8/BCbSsANc0HeNoQUfZDvTV/p4mnPhvIeNaz9HxCVDEx50ws3Hfh9v7gZu DazxySF0nJdEYLgkyQsEpRNOakMwUwT7OsFkfCIfq0FAKOaonGt0sc63RNfPWnOf RqcWQ5JKNbuujawduowKULe6b3FUrTsE+145CHu/7WaWH0q3MsDf1aZh4ag9pj6k F67agvebZ7VHBJbb/xW7P70w+FDtQZM+Mn9nr1B8aNmUFx+JLCMyiSX8umNlIpFv 1XVfFzN1M7MxN1kEHNC7ZGWcU39yXHPajsF91E91W0u/zFg3P4z8FiH6/YI2X+To SpF0jReAGtU4H59yhaDia/qHcNubkAlwWfT775GP2rpIN/WNEERhd0rM2AslhB2m 7txpPhSUwAZJ04KARSLn =kuw4 -----END PGP SIGNATURE----- |
|
From: David G. <jdg...@ho...> - 2017-06-03 22:37:49
|
On Saturday, June 3, 2017 2:21 PM, Keith Marshall wrote: 1 >On 03/06/17 16:47, David Gressett wrote: >>> I note that "make install-strip" does not strip these DLLs; should >>> it? (Ditto, for libgcc_s_dw2-1.dll). >> >> No, stripping an Ada DLL will cause it to lose its relocatability. >Why? I don't understand. Surely all Windows DLLs are inherently >relocatable? Stripping doesn't modify the relocation tables, so why >would it have any such effect? It has been several years since I looked at the Gnat user's guide, so I went back to it to double-check my memory. It is indeed documented in the Gnat user's guide that stripping will cause problems. In section 9.3.5.12 of the Gnat user's guide: "Note that a relocatable DLL stripped using the strip binutils tool will not be relocatable anymore. To build a DLL without debug information pass -largs -s to gnatdll. This restriction does not apply to a DLL built using a Library Project." I have no idea at present as to whether the part of the makefile that builds the gnat runtime invokes a library project or not; I would have to dig through the build log to find out, and I have not done that yet. - -- 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) iQIcBAEBAgAGBQJZMwwjAAoJEMCtNsY0flo/SgwQAI0hgM1656xjqZqIKwWRgzET W/ZEralDrzXIEzAAOb9+C068LeXs32fBcQMqglIC61E1+lVAqHva3JZn4X9GZJwI y/Yas9rsEQF7tn8/WLUQBTpgCfGdvQwGvmnMCBBJChGbUaLGIlvtq4+ct9cI0ou6 obt8ZEjH5xfs9AiudkrWdP18TuoeLwykNb9mAYL4le/LZM6fqSeLj1C2X++21ZpT TnTKSR7ins8GfBaMBg9J/NVZqM5pR3ijSFRKb4tnukCKOJCEzeQ90hKqoTFefc51 9PtG1s8/BCbSsANc0HeNoQUfZDvTV/p4mnPhvIeNaz9HxCVDEx50ws3Hfh9v7gZu DazxySF0nJdEYLgkyQsEpRNOakMwUwT7OsFkfCIfq0FAKOaonGt0sc63RNfPWnOf RqcWQ5JKNbuujawduowKULe6b3FUrTsE+145CHu/7WaWH0q3MsDf1aZh4ag9pj6k F67agvebZ7VHBJbb/xW7P70w+FDtQZM+Mn9nr1B8aNmUFx+JLCMyiSX8umNlIpFv 1XVfFzN1M7MxN1kEHNC7ZGWcU39yXHPajsF91E91W0u/zFg3P4z8FiH6/YI2X+To SpF0jReAGtU4H59yhaDia/qHcNubkAlwWfT775GP2rpIN/WNEERhd0rM2AslhB2m 7txpPhSUwAZJ04KARSLn =kuw4 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ MinGW-dvlpr mailing list Min...@li... https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
|
From: Keith M. <kei...@us...> - 2017-06-03 23:10:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/06/17 23:37, David Gressett wrote: > In section 9.3.5.12 of the Gnat user's guide: > > "Note that a relocatable DLL stripped using the strip binutils > tool will not be relocatable anymore." As a professional engineer, I'm conditioned to treat such claims with suspicion; it's inconsistent with the behaviour I see for every other regular DLL built for Windows, so I'd like to see concrete evidence in support of the claim. > "To build a DLL without debug information pass -largs -s to gnatdll. > This restriction does not apply to a DLL built using a Library > Project." What does that mean? The makefile rules to build libgnat-6.dll, and libgnarl-6.dll, don't use gnatdll; they use "gcc -shared ...", just as any C language (or indeed any other language) DLL is built, and such DLLs don't cease to be relocatable when stripped. > I have no idea at present as to whether the part of the makefile > that builds the gnat runtime invokes a library project or not; > I would have to dig through the build log to find out, and I have > not done that yet. Viewing my build.log in "less", and searching with "/libgna[tr]l*-6", is sufficient to show me those "gcc -shared ..." commands, and takes only a few seconds. - -- 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) iQIcBAEBAgAGBQJZM0HzAAoJEMCtNsY0flo/2pQP+gJ589yhEvCBxNZQTv83hlLA qiCwcu6MZ/v9d1ENZPk+ZM/eZrWbVoXa+jmjvV3341ZbqTPJRwZ036+gGHupSnqg BZ0Gp1Nm7Aoe1KyxOvwkuQYIE6Fd+w95FXriAbIWcmM3ab0jYCngeBwcUO//3pyT TrnRZJmORke7Ihz/r7vRVvDwxvbc/W2rrkABZDaXia516PtQyzn5Eb2+24i3JGt5 vx5wPAGpgd4ZQ+c1z8Y00JLI1bT/FOjBrlHjUsmD3PtN+0K/+aAcN/UZuZVcYHI2 C4OVql8VnNLTabEmRP8MO2ImnlpM1F/usrSMVqYHHzhMui1QlJULZV51fI8mvVzU Gl9e4+7MdNxwemzIIddGUvXwlO3dBsxaWrUj1mnL+MJNnGfu6N9BfrVNQGZZ7nZw UFUD0e1S33RVytYrh8JCU4/U2dL5R2cOTIOBH5lc17EjKJ2UQB/ZYu4+MaeMl3me wlRO0S4JmAVJlRA/wRAmntu8S+J6kUC26r2fF1g79niNE25mzJJsqOfGasyQsSw3 CbgmQkYjwbbgPbyhGgdNm9vgJvGmN133fn/9ScpBXoPYmwZlQtym3MXK9Powkm65 SgfpWdYAOyFnf3cm25BEXSBw4PqXySLX0a+gBS5xN22GKAAU9+Bmh5Ch4CEn3Yya Zvpk1hY49Qd25U8CXkPo =SaP7 -----END PGP SIGNATURE----- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X