Problem building gcc

[Pavel Pavlov]

> From: Ralf Wildenhues
> Sent: Friday, May 07, 2010 3:03 PM
> To: Pavel Pavlov
> Cc: gcc-help@gcc.gnu.org
> Subject: Re: Problem building gcc
> 
> Hello Pavel,
> 
> * Pavel Pavlov wrote on Thu, May 06, 2010 at 07:39:54AM CEST:
> > My problem is identical to this one:
> > http://gcc.gnu.org/ml/gcc-help/2008-03/msg00044.html
> > It fails on configure step of binutils in libiberty. I have no idea
> > what's the problem: everything is good, I have all the headers
> > installed and I use gcc-4.4.0 as toolset to build crosscompiler.
> >
> > In that particular case I have this config.status :
> > http://pastebin.com/PSsaya6F
> > Yet, the final config.h is absolutely identical to config.in:
> > http://pastebin.com/ecL4qkqT with the only change added is the single
> > line at the top:
> > /* config.h.  Generated from config.in by configure.  */
> >
> > Details of my environment: win7+msys and I'm trying to build cegcc
> > crosscompiler. The src that I'm using is ok, I built it on Cygwin
> > without that error, yet on msys/mingw it fails at the beginning.
> 
> Which version of MSYS and MinGW packages do you have installed?  In your
> MinGW shell, do you have $PATH set to also point to some Cygwin tools, and if
> yes, please show the value of $PATH, and when you last updated your Cygwin
> installation.
> 
> Can you please download a pristine Autoconf 2.64 tarball from
> ftp.gnu.org/gnu/autoconf and './configure && make && make check' it and
> report back the results, preferably to the bug-autoconf list?
> Thanks.

[Pavel Pavlov] 
I really have no idea what versions I have ;) they at mingw-msys have bunch of installers, plain zip files etc... overall, it's a soup of random bits and I don't know what version of what I have.
I followed this guide to install mingw/msys: http://ffmpeg.arrozcru.org/wiki/index.php?title=MSys_MinGW, there I also took these: GNU Binutils BIN v2.20.1 MinGW Runtime DLL v3.18 MinGW Runtime DEV v3.18 MinGW API for MS-Windows DEV v3.14  and gcc-full-4.4.0-mingw32-bin-2.tar.lzma. Then I installed MSYS-1.0.11.exe coreutils-5.97-MSYS-1.0.11-snapshot.tar.bz2 and I followed this autotools guide: http://ffmpeg.arrozcru.org/wiki/index.php?title=Installling_newest_autotools and built m4-1.4.12. When it didn't work I took m4 from msys sf page but had the same results. Since my config.h mentions autoheader I searched autoheader, which is a perl script. So, I tried to check if there is an issue with perl, tried to replace with activestate-perl but had the same error. After I tried it all I decided to ask on gcc-help and while writing that letter I guessed CRLF issue and that appeared to be source of the problem. When I fixed that I also had other problems and some ppl might be interested to know about that issues:
==
  As part of build of gcc/binutils, there are some temporary executables created that generate some tables. One of that I had problem with was getgtype.c. When it was run as part of build or configure it would simply report something like gengtype.exe input.h No such file or directory  [http://lmgtfy.com/?q=gengtype.exe+input.h+No+such+file+or+directory ]. This problem is also reported all over web, but no clear solution anywhere. The problem was that gengtype while building under msys did not link to msys subsystem, so it can't find /local/whatever/gcc/input.h. While trying to understand what's going on I figured out that msys is similar to cygwin (uses its own file system access library), while mingw uses native win32 access; and the problem was that while building an arm crosscompiler that should run from win32/mingw a temporary executable [gengtype] was built for win32/mingw instead of msys, basically there was some mix-up. I could find out how to properly link to msys subsystem so that gengtype.exe could properly read paths such as "/local/whatever/gcc/inpu.h", but I didn't know quick solution for that, so to fix that problem I had to hardlink (junction in windows) /msys/local to c:\local so that gengtype.exe could open these files and so that I wouldn't need to mess with any code or configs of gcc. I was building cegcc from svn, but I was building gcc based on 4.0.1 because it builds much smaller dll's for arm than the latest cegcc which is based on 4.4.0. SO, I can't tell if the same issu exists in latest or 4.4.0 gcc. I downloaded 4.4.0 src tarball from mingw and looked at their patches to gcc three and saw some proper changes to gcc's tree to properly distinguish mingw and msys or cygwin.
==


Here's the result of make check (from autoconf 2.64):

Summary:
410 tests were successful.
16 tests were skipped.

Skipped tests wrere:

176: parallel test execution                         skipped (autotest.at:1115)
177: parallel truth                                  skipped (autotest.at:1147)
178: parallel fallacy                                skipped (autotest.at:1152)
179: parallel skip                                   skipped (autotest.at:1157)
180: parallel syntax error                           skipped (autotest.at:1162)
181: parallel errexit                                skipped (autotest.at:1181)
182: parallel autotest and signal handling           skipped (autotest.at:1199)

235: AC_PROG_CPP without warnings                    skipped (c.at:146)
236: AC_PROG_CPP via CC                              skipped (c.at:186)

271: Erlang                                          skipped (erlang.at:32)
272: AC_ERLANG_CHECK_LIB                             skipped (erlang.at:54)
273: AC_ERLANG_SUBST_ROOT_DIR                        skipped (erlang.at:74)
274: AC_ERLANG_SUBST_LIB_DIR                         skipped (erlang.at:91)

277: AC_ERLANG_SUBST_ERTS_VER                        skipped (erlang.at:130)

278: AC_CHECK_LIB                                    skipped (semantics.at:35)

425: Libtool                                         skipped (foreign.at:60)


> 
> > I'm absolute ZERO or NULL in that black magic gibberish autoxxx
> > scripts, so I'm asking for your help to resolve that issue. It seems
> > that some of that atotools fail somehow to properly modify/parse some
> > of the input files (CRLF issue maybe?).
> 
> I am probably the one responsible for most of the recent work in that.
> We've tried to make sure that things work well for most setups we can think of
> (and test), but bugs can still happen.  On the upside there was algorithmic
> improvement coming along with the changes.
> 
> > PS: That same problem was once raised on cegcc list but with the same
> > outcome (unresolved):
> > http://www.mail-archive.com/cegcc-devel@lists.sourceforge.net/msg02642
> > .html
> 
> Again, please report to the Autoconf bug list when you suspect a bug in
> Autoconf.  We're glad to hear about reports, even if they turn out to be in other
> pieces of the build system afterwards.
> 
> Thanks,
> Ralf