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/