Update on gcc 4.9.1 build project
David Gressett <[email protected]> Sun, 24 Aug 2014 21:03:54 -0500
| Newsgroups | gmane.comp.gnu.mingw.devel |
|---|---|
| Message-ID | <[email protected]> |
I have continued to work on gcc 4.9 (as free time allows) and am making some progress. I had previously built and installed gcc 4.8.3 using the V4 runtime and win32 api. That version of gcc 4.8.3 failed to build 4.9.1 with a failure to compile gcc/ada/adaint.c, as I reported in a previous message. I then used mingw-get to remove and replace the V4 runtime and win32 api with mingwrt 3.20 and w32api 3.17. I then made another attempt to build gcc 4.9.1. That one failed again, but adaint.c was not the problem. It compiled with no problems. The build proceeded much farther - it made it into the next stage of the build, when the result of the first stage, xgcc, was the compiler doing the work. The failure was again an Ada problem, but this one was an ada tool: gnatmake.exe. Had it been consistently named with xgcc, it would have been xgnatmake.exe. It was unable to open a file named system.ads. I was able to extract it, and its equivalent from the 4.8.3 build into test directories and run both with gdb to see where their behavior differed. gdb had problems displaying Ada variable contents, but it was obvious that there was very little difference between the 4.8.3 and 4.9.1 source code in gnatmake. The offending gnatmake could also not get its own name from the command line; it displayed in Chinese characters. At this point, things were not looking good for the V4 runtime and win32 api. At this point, I was suspicious of the runtime, so I did what I should have done earlier - I rebuilt gcc 4.8.3 with itself, installed it, and then rebuilt and installed again; this should have produced a gcc with a much smaller effect from the V4 runtime and win32 api. (I expect that the problems are in the runtime - the compiler should not need to know very much about the win32 api. gnatmake does make one win32 api call. I haven't investigated other pieces for win32 calls.) I don't know anything about how the gmp, mpfr, and mpc libraries were built. I am still using the most recent versions as installed by the mingw installer. I made another attempt at gcc 4.9.1. This one went much further. The gnatmake problems disappeared, and the xgcc stage of the build completed successfully. The failure was a bit surprising. The last good line in the log file is /bin/touch/exec_compile The failure message is make: *** No rule to make target `README.gcc-4.9.1-1-mingw32' needed by `stg/share/doc/gcc/4.9.1/README.gcc-4.9.1-1-mingw32'. Stop. A quick look through the makefile showed no obvious reason for the failure, but I did find a few explicit references to 4.8.1, which would have also been in my 4.8.3 makefile. I corrected both makefiles; None of the 4.8 items had any obvious connections to the README and caused no problems in the 4.8.3 build. Nevertheless, I will rebuild gcc 4.8.3 before my next attempt at gcc 4.9.1. At this point, it looks as if the V4 runtime and win32 api should be taken out behind the barn and shot. There are serious problems there. I have started trying builds of the both the V3 and V4 runtime and win32 api, and also gmp, mpfr, and mpc. All have had problems - the sources that I downloaded for gmp, mpfr, mpc, and the V4 runtime all resulted in build crashes on the first build attempt. The problems were all easily fixed, but it does appear that the sources that I downloaded are not quite the same things that were used to build the binary packages with the same version numbers that are installed by the installer. I did notice that there are some interesting differences in the warning messages in the 4.9.1 log file. The 4.8.3 build had a swarm of warnings about ISO C++98 not supporting the 'I64' ms_printf length modifier. These have all disappeared from the 4.9.1 build. They have been replaced with "unknown conversion type character 'l' in format", sometimes immediately followed by "too many arguments for format" It will probably be at least another week before my next update. ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/