From: David G. <jdg...@ho...> - 2016-12-30 02:23:55
|
I got mingw-pkg installed and started working on gcc 5.3.0 I immediately found a problem when mingw-pkg did a configure. It did not configure to build the Ada compiler. I found nothing obvious that would explain this in config.log, so I went to the MinGW installer to see if I had anything missing and found that the mingw-gnat dll is still at version 4.8.1-4 and the repository version number is also 4.8.1-4. I have only built one Ada program since I upgraded to gcc 5.3.0, and it compiles and runs with no problems, but this does look a bit odd, and I suspect that the gcc configure may be more demanding about runtime library compatibility than my little program is. There was also a 4.8.1-4 version number on the mingw32-gcc-ada info file. |
From: Keith M. <kei...@us...> - 2016-12-30 10:19:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/12/16 02:23, David Gressett wrote: > I immediately found a problem when mingw-pkg did a configure. > It did not configure to build the Ada compiler. I found nothing obvious > that would explain this in config.log, so I went to the MinGW installer > to see if I had anything missing and found that the mingw-gnat dll is > still at version 4.8.1-4 and the repository version number is > also 4.8.1-4. I *think* the libgnat-dll version thing is a red herring; ada builds fine for me, but libgnat.a is built as a static library only -- I can find no way to create a corresponding DLL, (short of brute force, by extracting and linking all of the objects from libgnat.a, which I didn't bother to try). For me, ada is a completely alien world, and I simply don't have the inclination to devote either time or energy to debugging its quirky build system. If you are willing to pursue it, I'll assist as best I can, but I have no ada expertise to offer. - -- 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) iQIcBAEBAgAGBQJYZjSlAAoJEMCtNsY0flo/mhMQAJS5I5zWIHupnFcbJEy0lIvA 0Q/pqDm/84DffdLw8R3A0Q6Pc7zT++Kwsvm0YAmKD/XxTk4gFyOGFMmdFb76GBxh F6NJLVZmCuhOZII4NgdvfPYgCgC7GjrBhyxZ3LLMCxBS+U8oZXzqSYOU02s5b59t IXt79BUsOynH+kapKfgBi4NhINkSopGXnaxRFaPticiF3mXqDU9TJj7pkaaRSKZH YQHV0qOWE8kRWrxSr6K3dbJgmmKiU9vT/UMy7dtmtlj4M9Mecjla1eV5xeNLgGzx JfTG2qbqDFoY45rxOy9s39vejGW0a1BpmQE9I60uJ3r/IxBH9XV/WZiKqYuMj6IJ v9JoGMi3xSgXS1MTmZYGCvk2y5aeYTE5Xzy2ctxm5FTjASNg/wiYlqd/fXRhHkmc 8V0Vbr67gq+0LP2I0XUmuWflm9VRlIjaAJLUt3A4Lac3HZaGcz2wM5l66lGuBAiG DJGPbsUaknunL+uBxxShTCXEsNZRsQS5HlNIC7OCyiMWaBCL8cKddcoJ8sIczq3/ b2+UU1gaQPzXM51zRpGLEGQACU92gktUN8uS/fulIf757mA3pt8xwR5ZxxUsRA87 /IQRH33P8QxdP/k3S/AHC2gNTqDwOyGPJeodzOZVUtNFyqZZrT4b0N5qDOJb1paq KbpAvqVNwANXjG54vc4d =DU1z -----END PGP SIGNATURE----- |
From: David G. <jdg...@ho...> - 2017-01-01 22:15:32
|
>On 30/12/16 02:23, David Gressett wrote: >> I immediately found a problem when mingw-pkg did a configure. >> It did not configure to build the Ada compiler. I found nothing obvious >> that would explain this in config.log, so I went to the MinGW installer >> to see if I had anything missing and found that the mingw-gnat dll is >> still at version 4.8.1-4 and the repository version number is >> also 4.8.1-4. >I *think* the libgnat-dll version thing is a red herring; ada builds >fine for me, but libgnat.a is built as a static library only -- I can >find no way to create a corresponding DLL, (short of brute force, by >extracting and linking all of the objects from libgnat.a, which I >didn't bother to try). >For me, ada is a completely alien world, and I simply don't have the >inclination to devote either time or energy to debugging its quirky >build system. If you are willing to pursue it, I'll assist as best >I can, but I have no ada expertise to offer. I have now learned a bit more. my first problem became visible when I used mingw-pkg to do the configure stage of the gcc build. configure displayed this: "The following languages will be built: c,c++,fortran,java,lto,objc" I did not get Ada, which i did expect, and got java, which I did not expect and was not configured in the pkgspec file. The objective-c languages also dropped out. I examined the config.log and found the command line that was used to run the gcc configure. I found a problem; it contained --build=x86_64-pc-linux-gnu instead of the expected -build=mingw32 I have a copy of .mingw-pkgrc in both my $HOME directory and the gcc build directory. I had constructed it by modifying the one that you included as an attachment by changing the build line to this: build=${build-"mingw32"} It seems that mingw-pkg ignored .mingw-pkgrc. I then removed the results of the configure step and reconfigured it using by directly issuing the configure command line to see if it the problem would go away: ../../src/gcc-5.3.0/configure --build=mingw32 --host=mingw32 , etc It did go away - I saw this: "The following languages will be built: c,ada,c++,fortran,lto,objc,obj-c++" I am now using mingw-pkg to run the compile step. It failed when it got to Ada, with a problem in adaint.c "error: 'fstat64' was not declared in this scope." That looks to me like a patch failure, as one of the patch files deals with fstat64. It appears that mingw-pkg is behaving badly in msys on my Windows 10 computer. My next step is to avoid mingw-pkg and do all the patching and configuration manually. |
From: Keith M. <kei...@us...> - 2017-01-01 22:57:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/01/17 22:15, David Gressett wrote: > I found a problem; it contained --build=x86_64-pc-linux-gnu - From whence is it picking that up? For me, that comes from my $HOME/.mingw-pkgrc; it should not be defined otherwise. > instead of the expected -build=mingw32 Why is this expected? If your $build == $host, (as would be the norm for a native build), your configure line should (ideally) not specify either --build or --host. > I have a copy of .mingw-pkgrc in both my $HOME directory and > the gcc build directory. Well, that's just plain wrong; if you need it at all, (which you may not, unless you have a burning desire to customize something), then it belongs in $HOME, and nowhere else. > It appears that mingw-pkg is behaving badly in msys on my > Windows 10 computer. My next step is to avoid mingw-pkg and > do all the patching and configuration manually. Well, okay as an interim measure, but we really need to debug this. Did you run 'mingw-pkg patch'? In the source or the build tree? If so, what was its (console) output? - -- 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) iQIcBAEBAgAGBQJYaYlSAAoJEMCtNsY0flo/2kEQAMeHeeUGlv2y0p7onCd2cjj9 65QahKxvkYb2nfismz7AYnqQadD2oiXkPqyBrOuhx7pGru26uS+pHlCh72DmOXJA xlrnEWDpzoknP65tV+N7goKpvdkAp6j1RPv7g6yDBxLHoWuCmdTqZH552K71nvob nMi0xyEqOXvAUtlub9p52PiQ45PnbXak2EchrOUUQgXlwzU25l58locHcClyCIeM DmYvxLkBVb+VYxdL/1TsjQnBPXWNHhLz3cNCiCoBkpsL4kyAPcZ4XghxE5HQkHOa IUSavfYSKApwE6e5k5sMU6AYIF4REgzcQxYDPSTuSg1NXdnAm05lLwUL4SsN8gCP o7bLYH3hIznC9OWfyii2tqHd9aE35cFypylIylaEzLj4kUlQ7eBvvlk1M3s4CNfA AlyDCgIIT4m7kxwndewEWwPYOmzaP+QJGbZxHc4KLdSW1A3Wl7/dq8M1pFC1LIBu CM0hF/kQ9SuWr/pa6k6ibvBMiWz6rIEK6enIjoODy7hMXER+ZwneYQN/KyHqtaqF UInkVHhpMr8IO79PpU5gVzjDBjGtWmFtFBnp0+m7b4h7vACLxOAuJAW1aybvGdb9 pWSe3Kgs7dYjGmkqi+51CA2QCwzpLpZ86KhavsZfhMfDsbz50D26/5dwaEGyoV/b Gi0ICqmkbWIKDOd4wOoB =8gDU -----END PGP SIGNATURE----- |
From: David G. <jdg...@ho...> - 2017-01-03 14:24:49
|
From: Keith Marshall <kei...@us...> Sent: Sunday, January 1, 2017 4:57 PM >On 01/01/17 22:15, David Gressett wrote: >> I found a problem; it contained --build=x86_64-pc-linux-gnu >- From whence is it picking that up? For me, that comes from my >$HOME/.mingw-pkgrc; it should not be defined otherwise. >> instead of the expected -build=mingw32 >Why is this expected? If your $build == $host, (as would be the >norm for a native build), your configure line should (ideally) >not specify either --build or --host. >> I have a copy of .mingw-pkgrc in both my $HOME directory and >> the gcc build directory. >Well, that's just plain wrong; if you need it at all, (which you >may not, unless you have a burning desire to customize something), >then it belongs in $HOME, and nowhere else. >> It appears that mingw-pkg is behaving badly in msys on my >> Windows 10 computer. My next step is to avoid mingw-pkg and >> do all the patching and configuration manually. >Well, okay as an interim measure, but we really need to debug this. >Did you run 'mingw-pkg patch'? In the source or the build tree? >If so, what was its (console) output? I ran it as you specified in you message in the MinGW list: $ cd $HOME/build/gcc-5.3.0-mingw32 $ mingw-pkg SRCDIR=../../src/gcc-5.3.0 patch For my next attempt, I removed both copies of .mingw-pkgrc., deleted all the remains of the previous attempt from my build directory and did the patch and configure steps again. This time, I used tee to save the console display and stayed to watch the patch step. $ mingw-pkg SRCDIR=../../src/gcc-5.3.0 patch | tee ../mingw-pkg-patch.log the console showed this: >>> apply patches >>> done. It completed so quickly that it is obvious that it really did no patches, rather than suppressing or redirecting any console output. I then did the configure: $ mingw-pkg SRCDIR=../../src/gcc-5.3.0 configure | tee ../mingw-pkg-configure.log The configure step produced exactly the same results as my previous configure, even though there was no .mingw-pkgrc: The console display still announced that it would build java but not ada and the configure command line still contained --build=x86_64-pc-linux-gnu. |
From: Keith M. <kei...@us...> - 2017-01-03 23:35:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/01/17 14:24, David Gressett wrote: >> Well, okay as an interim measure, but we really need to debug this. >> Did you run 'mingw-pkg patch'? In the source or the build tree? >> If so, what was its (console) output? > > I ran it as you specified in you message in the MinGW list: > $ cd $HOME/build/gcc-5.3.0-mingw32 > $ mingw-pkg SRCDIR=../../src/gcc-5.3.0 patch Right. The CWD *must* be set to the top of the source tree while applying patches; the 'mingw-pkg patch' command *should* use your specified SRCDIR, to make that so, but ... > For my next attempt, I removed both copies of > .mingw-pkgrc., deleted all the remains of the previous > attempt from my build directory and did the patch > and configure steps again. > > This time, I used tee to save the console display and > stayed to watch the patch step. > > $ mingw-pkg SRCDIR=../../src/gcc-5.3.0 patch | tee ../mingw-pkg-patch.log > > the console showed this: > >>>> apply patches > > >>>> done. ... this suggests that it didn't; it should have looked like: | $ mingw-pkg SRCDIR=../gcc-5.3.0 patch | | >>> apply patches | | >>> applying patch: arch/mingw32/01-mingw-w64-brain-damage.patch | patching file gcc/config/i386/mingw32.h | >>> applying patch: arch/mingw32/02-mingw32-float.h.patch | patching file gcc/ginclude/float.h | >>> applying patch: arch/mingw32/03-ada-largefile.patch | patching file gcc/ada/adaint.c | patching file gcc/ada/adaint.h | patching file gcc/ada/cstreams.c | >>> applying patch: arch/mingw32/04-eh-frame-begin.patch | patching file libgcc/config/i386/cygming-crtbegin.c | >>> applying patch: arch/mingw32/05-fortran-strings.patch | patching file libgfortran/intrinsics/selected_char_kind.c | patching file libgfortran/runtime/environ.c | patching file libgfortran/runtime/string.c | >>> applying patch: arch/mingw32/06-ssp-wincrypt.patch | patching file libssp/ssp.c | | >>> done. > It completed so quickly that it is obvious that it really did no > patches, I doubt if it even found the patch files, relative to the CWD in the build tree. The script fragment which deals with patches is missing a 'cd $SRCDIR' command; I can fix that ... in fact, I've already done so in my local code base, to get the above output. > rather than suppressing or redirecting any console output. > > I then did the configure: > $ mingw-pkg SRCDIR=../../src/gcc-5.3.0 configure | tee ../mingw-pkg-configure.log > > The configure step produced exactly the same results as my previous > configure, even though there was no .mingw-pkgrc: The console display > still announced that it would build java but not ada and the configure > command line still contained --build=x86_64-pc-linux-gnu. Well, it's getting that from somewhere, (and the only place it should be able to find it is $HOME/.mingw-pkgrc); FWIW, if I run the 'mingw-pkg configure' command in MSYS, as: $ sh -vx `which mingw-pkg` SRCDIR=../gcc-5.3.0 configure 2>&1 (and capture output via 'tee'), I see: | checking build system type... i686-pc-mingw32 | checking host system type... i686-pc-mingw32 | checking target system type... i686-pc-mingw32 so $build is *not* being set by --build=x86_64-pc-linux-gnu, (or by an other explicit option), but is correctly auto-detected as i686-pc-mingw32, (which is as it should be). However, I'm also seeing no evidence of *any* configure options be read from the package specification file ... indeed, I'm seeing evidence of an MSYS shell bug, which prevents mingw-pkg from even locating the package specification file: | # Ensure we have a PACKAGE name specification; if not, attempt to deduce | # a suitable default from the name of the top-level source code directory. | # | pkgspec_from_srcdir(){ | pkgspec_$1 $PACKAGE_ABS_SRCDIR | } | pkgspec_get_name(){ | IFS=-; set -- `basename "$1"`; value= IFS= | for part | do case $part in [0-9]*) break;; | *) value="$value$IFS$part" IFS=-;; | esac | done | echo "$value" | } | PACKAGE=${PACKAGE-"`pkgspec_from_srcdir get_name`"} | pkgspec_from_srcdir get_name | +++ pkgspec_from_srcdir get_name | +++ pkgspec_get_name /home/keith/gcc-5.3.0 | +++ IFS=- | basename "$1" | ++++ basename /home/keith/gcc-5.3.0 | +++ set -- gcc 5.3.0 | +++ value= | +++ IFS= | +++ for part in '"$@"' | +++ case $part in | +++ value=gcc | +++ IFS=- | +++ for part in '"$@"' | +++ case $part in | +++ value=gcc-5.3.0 | +++ IFS=- | +++ echo gcc-5.3.0 | ++ PACKAGE=gcc-5.3.0 | test "x$PACKAGE" = x && PACKAGE='<package>' | ++ test xgcc-5.3.0 = x Notice that it has failed to match the 'case [0-9]*)' pattern, as it should have, and consequently, has set 'PACKAGE=gcc-5.3.0', where it should have been just 'PACKAGE=gcc'; contrast the above with correct behaviour, when run using the dash shell, on my Linux box: | # Ensure we have a PACKAGE name specification; if not, attempt to deduce | # a suitable default from the name of the top-level source code directory. | # | pkgspec_from_srcdir(){ | pkgspec_$1 $PACKAGE_ABS_SRCDIR | } | pkgspec_get_name(){ | IFS=-; set -- `basename "$1"`; value= IFS= | for part | do case $part in [0-9]*) break;; | *) value="$value$IFS$part" IFS=-;; | esac | done | echo "$value" | } | PACKAGE=${PACKAGE-"`pkgspec_from_srcdir get_name`"} | + pkgspec_from_srcdir get_name | + pkgspec_get_name /home/keith/src/mingw/gcc-build/src/gcc-5.3.0 | + IFS=- | + basename /home/keith/src/mingw/gcc-build/src/gcc-5.3.0 | + set -- gcc 5.3.0 | + value= IFS= | + value=gcc IFS=- | + break | + echo gcc | + PACKAGE=gcc | test "x$PACKAGE" = x && PACKAGE='<package>' | + test xgcc = x (Do note that this is not an MSYS specific bug; if I substitute bash for dash, on the Linux box, I see the same mishandling of the case pattern; I'll have to explore possible work arounds). - -- 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) iQIcBAEBAgAGBQJYbDVVAAoJEMCtNsY0flo/xwEP/j/TDHNlnAB44qjaSwbIYTmH GMOU2E6j9iML5oU+m01U2KYqYw33JnOcIr8DdafmMrhmaOIzsRPVRM9ZuQ5fYoKo gluts7Dv1ZPr24UaQwpgSg8ELVFHO6jubHEYbkkijlza47SA/3ow7PVvk1S6Ar68 7cZYIRMsUbz15HYmeS5Jkn9OfWLhW0TW2yOmqM1FHLb8C8gHZxtDPyb3u0z+C1YF ZmV2JUoS50ybZZprTLsv6Gc6UhnmEA5MIAtV0KA1gCQxWCZqJukNrG/B5gNUZQeI 6vbBWTcsjwZLkr7aot9tG2XMBS4ChoKxnLGDHFw69ZTuvmGM5TiufafPEen+uWYC 8KQChf3SYvVpN8sO6BVOi9O7l3/5CEcfYNiurTajK7Mn0BNyBfWRNbaU2ambs8Ty kIkQLBMptdMb7pyAsA6kUSBaIJrQ2MKhjtU9eJYV+cWtHNk/ov3/MArgO2wsjYSm oix87xYzEBgw+SauooDBuFph4iW+D7akpcJHEdILrJUZ7/wD0OBvA2fB8A1WRVVx F7rL0aAVlFXdGqRLupoaG3BpdAo3Zn2bYPtGrR1z5pcJUOhcm+ikhF5WI2BsYhl5 hIoXnkhQuLOTeul9uW5gr5Co8yEZbHhc3qYIHOXT/MPF1Po8Z800dXB4VG7oTZwc xtr2p98+JjxeyvH1f3Cv =W8m0 -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2017-01-04 22:36:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/01/17 23:35, Keith Marshall wrote: > I'm seeing evidence of an MSYS shell bug, which prevents mingw-pkg > from even locating the package specification file: > > ... > > it has failed to match the 'case [0-9]*)' pattern, as it > should have, and consequently, has set 'PACKAGE=gcc-5.3.0', where it > should have been just 'PACKAGE=gcc' This issue appears to arise as a consequence of leaving the '-' in $IFS; the effect is as if bash performs IFS directed word splitting on the case pattern, (which I think is incorrect behaviour -- dash certainly handles it more intelligently -- but I cannot find any definitive specification for what would be "correct" behaviour). In any case the effect is that the '[0-9]' character range within the 'case [0-9]*)' pattern specification is misinterpreted. The issue is mitigated by clearing $IFS, and using a local, unrelated shell variable in its place, within the scope of the case statement. Today, I've pushed changes to circumvent this issue, and to correct the previously identified 'mingw-pkg patch' defect, to my SF user repository, so mingw-pkg should now work as originally suggested, regardless of any host shell deficiencies. - -- 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) iQIcBAEBAgAGBQJYbXj6AAoJEMCtNsY0flo/ENEQALt0g/RnJtxoHhlalkJI5bPj bDhxwTUOcGyBozgstk4YkqXTwQeXe0wEkTpjHqm3EETWN3W7hk2MrWNpvoORdaZI gpXoThIKgmrwxpopPu7dd2V9zuPjramYz+H1mWxJSCGHrY3abLk1Y+S33eyWVA15 j5dK64XjXhjRPsxvlJYEQmwejgvRr+JonMq77TUOYIgperXUwOdQK3HZ3FAFryuh UO0sQGJ08wP8u6+YRXj/mG1WZiQtdvUtnoeQdNx6RabujnBNiYo3q6w0Pz3PqXjX 5yIY57006YgvUplEXr/SuP4FFST2Ta9P2gSFIkGgvdogK49+K03JC55pLVuff2UC /aaBZXDekCOWN9aIAkIABTpndI/LHDoylfbHFuV2r/jKSJfaeLxI1IeV25HmhLUA u24AfCfP2sS6tNM4AHg1r3gerdwcnUfA6qFPv8wCxTt+X0SioViZAy5x2JQjf/S/ nIs1/QcEwZfn3vj6PCMNmFbBHZ2o+fDqbNv1dayKyz0kYQURlG4uUMj9EhJquU05 GMM9I4DfKloDP4D6/XoCqfjI71uN1wLIwkQutPgTc5UeFaLzqwE3tVGRjg2IaY/V TI1KIN8/hMrQOxf4vdnFPC567Ne5LzN38J+S2Tz9o9huUvwuvv8g8iSHMGTMTZ8X DdsmIKur59PYz8HqUB2m =swdI -----END PGP SIGNATURE----- |
From: David G. <jdg...@ho...> - 2017-01-05 17:07:50
|
>From: Keith Marshall <kei...@us...> >Sent: Wednesday, January 4, 2017 4:36 PM >To: min...@li... >Subject: Re: [MinGW-dvlpr] Problem with configure when trying to build gcc 5.3 >On 03/01/17 23:35, Keith Marshall wrote: >> I'm seeing evidence of an MSYS shell bug, which prevents mingw-pkg >> from even locating the package specification file: >> >> ... snip ... >> >> it has failed to match the 'case [0-9]*)' pattern, as it >> should have, and consequently, has set 'PACKAGE=gcc-5.3.0', where it >> should have been just 'PACKAGE=gcc' >This issue appears to arise as a consequence of leaving the '-' in >$IFS; --- snip ... >Today, I've pushed changes to circumvent this issue, and to correct >the previously identified 'mingw-pkg patch' defect, to my SF user >repository, so mingw-pkg should now work as originally suggested, >regardless of any host shell deficiencies. I tried it and it worked perfectly for the patch; however, I still have the problem with the ghost of .mingw-pkgrc that continues to haunt my build attempts by inserting --build=x86_64-pc-linux-gnu into my configure options. I have seen some evidence that this is part of a larger problem: some msys components are having problems with the Windows 10 file system. I found one problem when I was trying to build gcc 5.3.0 without mingw-pkg. Instead of doing a completely manual build, I modified Earnie's 4.8.1 build system. I set this up on my Windows C drive in C:/Build_gcc, which was /c/Build_gcc in msys. I found that when I used tee to copy stdout to ../make-patch.log that the resulting log file was invisible on the Windows side. A dir command in a cmd window could not list it and it was not visible in a Windows explorer window, but the msys ls could list it and rm could make it disappear. I moved everything down one level into a subdirectory of Build_gcc and the problem disappeared. I suspect that my use of rm .mingw-pkgrc was not completely successful and that it may have corrupted the file system rather than removing the file, leaving a file that could be read but not listed. I saw another possibly related problem with my build using Earnie's build system. I found that make prep, make patch, and make configure all apparently worked, but make stage did not work . I saw errors like /bin/cp: cannot stat stg/include/*': No such file or directory make quit shortly after that, leaving an empty stg/include directory. I saw that this build did create the Ada dll files but it did not give them the same names that I had set up in the makefile. I tweaked Earnie's makefile by replacing all instances of the string "4.8.1" with "5.3.0" and likewise changing "4.8" to "5.3". This gave me ada_DLL_FILES = libgnat-5.3.dll libgnarl-5.3.dll at line 66 in the makefile, but the build produced libgnarl-5.dll and libgnat-5.dll |
From: Earnie <ea...@us...> - 2017-01-06 14:50:52
|
On 1/5/2017 12:07 PM, David Gressett wrote: > >> From: Keith Marshall <kei...@us...> >> Sent: Wednesday, January 4, 2017 4:36 PM >> To: min...@li... >> Subject: Re: [MinGW-dvlpr] Problem with configure when trying to build gcc 5.3 > >> On 03/01/17 23:35, Keith Marshall wrote: >>> I'm seeing evidence of an MSYS shell bug, which prevents mingw-pkg >>> from even locating the package specification file: >>> >>> ... snip ... >>> >>> it has failed to match the 'case [0-9]*)' pattern, as it >>> should have, and consequently, has set 'PACKAGE=gcc-5.3.0', where it >>> should have been just 'PACKAGE=gcc' > >> This issue appears to arise as a consequence of leaving the '-' in >> $IFS; > --- snip ... > >> Today, I've pushed changes to circumvent this issue, and to correct >> the previously identified 'mingw-pkg patch' defect, to my SF user >> repository, so mingw-pkg should now work as originally suggested, >> regardless of any host shell deficiencies. > > I tried it and it worked perfectly for the patch; > however, I still have the problem with the ghost of .mingw-pkgrc > that continues to haunt my build attempts by inserting > --build=x86_64-pc-linux-gnu > into my configure options. I have seen some evidence that this is > part of a larger problem: some msys components are having > problems with the Windows 10 file system. I found one > problem when I was trying to build gcc 5.3.0 without > mingw-pkg. Instead of doing a completely manual build, > I modified Earnie's 4.8.1 build system. I set this up on > my Windows C drive in C:/Build_gcc, which was > /c/Build_gcc in msys. I found that when I used tee > to copy stdout to ../make-patch.log that the resulting > log file was invisible on the Windows side. A dir command in > a cmd window could not list it and it was not visible > in a Windows explorer window, but the msys ls could > list it and rm could make it disappear. I moved everything > down one level into a subdirectory of Build_gcc and > the problem disappeared. > > I suspect that my use of rm .mingw-pkgrc was not > completely successful and that it may have corrupted > the file system rather than removing the file, leaving > a file that could be read but not listed. > > I saw another possibly related problem with my > build using Earnie's build system. I found that > make prep, make patch, and make configure all > apparently worked, but make stage did not work . > > I saw errors like > /bin/cp: cannot stat stg/include/*': No such file or directory > > make quit shortly after that, leaving an empty stg/include > directory. > > I saw that this build did create the Ada dll files but it > did not give them the same names that I had > set up in the makefile. I tweaked Earnie's makefile by > replacing all instances of the string "4.8.1" with "5.3.0" > and likewise changing "4.8" to "5.3". This gave me > > ada_DLL_FILES = libgnat-5.3.dll libgnarl-5.3.dll > > at line 66 in the makefile, but the build produced > > libgnarl-5.dll and libgnat-5.dll Sounds to me like you have what Cygwin calls "BLODA" going on. Have you tried with AV off or ignoring your work environment? The one thing about ADA that I remember is that it required a previous build of ADA to build the new one. I'm sure there must be a bootstrap process other than building via cross but it was beyond what I had time to consider. -- Earnie |
From: Keith M. <kei...@us...> - 2017-01-05 22:32:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/01/17 17:07, David Gressett wrote: > I still have the problem with the ghost of .mingw-pkgrc > that continues to haunt my build attempts by inserting > --build=x86_64-pc-linux-gnu > into my configure options. There's not a lot we can do, to help you debug that; have you tried running 'mingw-pkg configure' under 'sh -vx ...', (as I suggested on Tuesday)? The output from that should show you where the bogus setting is creeping in. - -- 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) iQIcBAEBAgAGBQJYbsmWAAoJEMCtNsY0flo/0yUP/itVEfyfgUB68/1kIyWE0Kpx Q8opHXI9CALfpl4/MDC/Aon3mJOy7Dw0N/vL1kb6TmNYy6caI522Db4fPk434Mja gTsP84/RFhkJfM2OtKJVIZQB9yO8Qo68yj+Jn12tA977hTVcGzIO4ZqDArxPCGUT npMyK02vrkFLLKDvRLPTyzsngmiMCy48iYyWbsxg5ZX0O3/VfVt3iPZUxvmeEnsI LABYomX1q9XcA/o37Y1Jcrb9n5hO7karp2yTes91ew5BZlsrQjl9fYb4z2OtpmGX JrRu4S7/hxGobSFwQWFEbiaN8WgLO/2/m04sWmqC5m3VofglM0YQY67zAnREYX6q 6hUY0w0kT0CLw+X+I5oyC0yDbKCAdLc4eNL1s/5khMXnVhaEzliCyIeb6EDRMYO0 ptF4BHzcLkQTLKHFsXZTZgubWew/pLAITOX9ZgHa+HD9Rev94JE+N8oeDz7jDN4A YPWgJqxbB+B0icUdbdCi5gP6Ec+cKBgtkr+jwAdu7netUpPlwKXhNSxzvferpQdS DeCJDF38h9K7xp/b9ZIHyz9w/v6Nf2fgxpwckIztEfJNs9NQdffDtrt0QV5UvSkG bv4ju5nw5XRYNbmegQPBjVziH9g+fI6EoQBRtdTRse528mT+xjhCyVFeTw4pbYSS BNJxA1ieIF3KDDoaQa31 =IRv6 -----END PGP SIGNATURE----- |
From: David G. <jdg...@ho...> - 2017-01-07 20:10:18
Attachments:
error.txt
|
>From: Keith Marshall <kei...@us...> >Sent: Thursday, January 5, 2017 4:32 PM >To: min...@li... >Subject: Re: [MinGW-dvlpr] Problem with configure when trying to build gcc 5.3 >On 05/01/17 17:07, David Gressett wrote: >> I still have the problem with the ghost of .mingw-pkgrc >> that continues to haunt my build attempts by inserting >> --build=x86_64-pc-linux-gnu >> into my configure options. >There's not a lot we can do, to help you debug that; have you >tried running 'mingw-pkg configure' under 'sh -vx ...', (as I >suggested on Tuesday)? The output from that should show you >where the bogus setting is creeping in. I tried that and the result looked just like the example that you had in your Tuesday message. config.log still showed Configured with: ../src/gcc-5.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --prefix=/mingw ... config.status, however, contained an option list that had no --build option. At that point, I tried the compile step, using tee to save the console display. It eventually crashed with this message: C:\MinGW\mingw32\bin\ld.exe: cannot find dllcrt2.o: No such file or directory I then looted Earnie's package.ini for configure options that were not originally in your gcc-5.3.0-mingw32.pkgspec and added them into it and tried again, with exactly the same results. This struck me as odd, since the compilation with Earnie's build system completed successfully. I have attached a bit of the compile log file that shows the context of the error. |
From: Cesar S. <ces...@gm...> - 2017-01-08 18:59:50
|
On 01/07/2017 20:09, David Gressett wrote: > I tried that and the result looked just like the example that you > had in your Tuesday message. config.log still showed > > Configured with: ../src/gcc-5.3.0/configure > --build=x86_64-pc-linux-gnu --host=mingw32 --prefix=/mingw ... This is harmless. It is simply echoing how your native gcc (installed via mingw-get) was configured. Try running gcc -v: $ gcc -v Using built-in specs. COLLECT_GCC=c:\programas\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/programas/mingw/bin/../libexec/gcc/mingw32/5.3.0/lto-wrapper.exe Target: mingw32 Configured with: ../src/gcc-5.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --prefix=/mingw --disable-win32-registry --target=mingw32 --with-arch=i586 --enable-languages=c,c++,objc,obj-c++,fortran,ada --enable-static --enable-shared --enable-threads --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --with-libintl-prefix=/mingw --enable-libstdcxx-debug --with-tune=generic --enable-libgomp --disable-libvtv --enable-nls : (reconfigured) ../src/gcc-5.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --prefix=/mingw --disable-win32-registry --target=mingw32 --with-arch=i586 --enable-languages=c,c++,objc,obj-c++,fortran,ada --enable-static --enable-shared --enable-threads --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --with-tune=generic --enable-libgomp --disable-libvtv --enable-nls Thread model: win32 gcc version 5.3.0 (GCC) > config.status, however, contained an option list that had no --build > option. Then it's OK. It should not be picking any "ghost" of .mingw-pkgrc. Regards, Cesar |
From: Keith M. <kei...@us...> - 2017-01-08 13:29:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/01/17 20:09, David Gressett wrote: >> There's not a lot we can do, to help you debug that; have you >> tried running 'mingw-pkg configure' under 'sh -vx ...', (as I >> suggested on Tuesday)? The output from that should show you >> where the bogus setting is creeping in. > > I tried that and the result looked just like the example that > you had in your Tuesday message. config.log still showed > > Configured with: ../src/gcc-5.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --prefix=/mingw ... I meant you to search in the echoed shell commands, as executed by mingw-pkg, to identify which of them is adding that bogus option; if you can't find it there, then do you, perhaps, have a stale config.cache in your build tree, from whence it may be inherited? If so, get rid of it; ideally, 'rm -rf' the entire build tree, and start with a clean slate. > config.status, however, contained an option list that had no --build > option. At that point, I tried the compile step, using tee to save > the console display. It eventually crashed with this message: > > C:\MinGW\mingw32\bin\ld.exe: cannot find dllcrt2.o: No such file or directory Hmm. dllcrt2.o is a component of mingwrt; for me it lives in '/home/keith/mingw32/lib`, (under the '/home/keith/mingw32' prefix, where my Linux hosted mingw32-gcc cross-compiler is installed). For the crossed-native build, I didn't appear to need to do anything in particular, to have that found, but, when building the cross-compiler itself, I need to: 1) Configure and 'make install-headers' for mingwrt/w32api, with prefix configured as /home/keith/mingw32 2) Configure, make, and 'make install' GNU binutils, with this same prefix, (also specified for '--with-sysroot'), and with `--target=mingw32' 3) Symbolically link /home/keith/mingw32/mingw to its own containing directory; (this is a ludicrously defective requirement of the GCC build system itself -- without it, the build will fail with 'the directory which should contain the system headers does not exist', in spite of them being correctly installed in prefix/sysroot at step (1)). 4) Configure the GCC build, again with /home/keith/mingw32 as prefix, and sysroot; (sysroot is appropriate in the case of cross-compilers, but not native builds). 5) Perform the first 'make all-gcc' phase, of a two stage GCC build. 6) 'make install-gcc' the partial GCC built in step (5). 7) Use that partially built and installed step (6) GCC to make and 'make install' mingwrt/w32api. 8) Complete the GCC build, with 'make', then 'make install' Once the above is in place, the crossed-native build is much simpler: 1) Configure, as per mingw-pkg specification. 2) Build it; all that seems to be required is 'make', which is all that 'mingw-pkg compile' does, for the GCC case. I've never tried to build GCC natively on Windows; the whole process is much too painful! Perhaps you need something like the stage-by-stage procedure used for my cross-compiler? Or maybe, a 'make bootstrap' procedure, (for which the mingw-pkg specification isn't set up, in the 'mingw-pkg compile' case)? - -- 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) iQIcBAEBAgAGBQJYcj6bAAoJEMCtNsY0flo/AXwQALOYw7T8UDacxKOnwu3M86S6 PNGC+yI88qKPROZxNAIYOkhc7gRyLdbYkXTuHtCsYtMl5+4bpkdEaDktBORbo740 4SUo/O9+WhUwoYS9DZ4niEa8xW/aBPRpiSFjlX6Voodqhb9DA6t04H5J3ImKuUjA 0wcLaTdDX9j/hrOsSzVfaoUEIyHkcu/z333w9/0Ov6+UiL9GYQS/O0tKWeFJe3/s IzRWyALyH6jsQHhYtdNx472b/WY4knNzWoCyYxi1HvORdlZ7R8xdgFAMmnsOL8O0 hrdF1W+MoPx1/nHRvkanMQ3zaA+GIITV0E0bqYU1cUAkDxlUsPbmPIcRo1FYQ/Lj 6Vps1ls/MlNG9ctfTsEAkV3iFDMtK5DGOFRQCoM1sygx0IYDa9E7FLYS6FWj6DzB +NxrlCDERYtAtX8PcTI8vPoObNODbtos84LGe0vQPyzC5l/XzjhUf+ORR/OcMqwT /i5VxPRx5N58HgKwmReDhsoK4OVFOLT6jduNT+CcQ9Kb2GIpJh0xYlMtiUW3LecC ZztlOsGypeLtcwXRc3a2M1qloqCokg0HgOnLlOUVGE8NdKWBqQPagV8pwjWl83xM XpWWE/f+9cSBnfNhKbk8MRIdlgcT+kVcnEWzmEhDsObnb4apLuEe+Wc+Zd8pR4KC OgT81+5Jy+wVhPZOZ2P3 =aFUb -----END PGP SIGNATURE----- |
From: David G. <jdg...@ho...> - 2017-01-09 19:39:56
|
>From: Keith Marshall <kei...@us...> >Sent: Sunday, January 8, 2017 7:28 AM ... snip ... >> config.status, however, contained an option list that had no --build >> option. At that point, I tried the compile step, using tee to save >> the console display. It eventually crashed with this message: >> >> C:\MinGW\mingw32\bin\ld.exe: cannot find dllcrt2.o: No such file or directory Hmm. dllcrt2.o is a component of mingwrt; for me it lives in '/home/keith/mingw32/lib`, (under the '/home/keith/mingw32' prefix, where my Linux hosted mingw32-gcc cross-compiler is installed). ... snip ... >I've never tried to build GCC natively on Windows; the whole >process is much too painful! Perhaps you need something like >the stage-by-stage procedure used for my cross-compiler? Or >maybe, a 'make bootstrap' procedure, (for which the mingw-pkg >specification isn't set up, in the 'mingw-pkg compile' case)? There should be a clue to the dllcrt2.0 problem in Earnie's build system that was used for the 4.8.1 release - when I hack it to build 5.3.0, I have problems with make stage, as I previously mentioned, but the the make compile step completes with no dllcrt2.o problem. I did a test builds of gcc 5.3.0 using both Earnie's system and mingw-pkg. In order to make a better comparison, I modified the build options in gcc-5.3.0-mingw32.pkgspec to be an exact duplicate of the ones that I lifted from the package.ini file in Earnie's 4.8.1 build. The builds had the same result as before - The compile step succeeded in Earnie's system and failed with the dllcrt.o problem with the mingw-pkg system I did a diff of the config.log and config.status files that were produced by the two build systems. I found that the only difference was the path relationship between the build and source directories, which is a trivial difference. >From that, I conclude that mingw-pkg in a native Windows environment is doing something that causes problems for make; I will need to do some more analysis to find out what is happening. It would help if I knew what command line that mingw-pkg creates for make in the compile stage, but 'sh -vx' should be useful there. |