[gccsdk] Building GCC4 in Cygwin

John Tytgat John.Tytgat at aaug.net
Tue Jan 29 14:44:00 PST 2008


In message <c090ed684f.admin at snowstone.org.uk>
          Adam <lists at snowstone.org.uk> wrote:

> In message <a8bd68684f.Jo at hobbes.bass-software.com>, John Tytgat wrote:
> 
> > That's very good news.  Could you add your experience & specifics you
> > had to do to <URL:http://www.riscos.info/index.php/Cygwin_setup> page ?
> 
> I've added a few bits. The main problem is the lack of an official
> autogen package in Cygwin.

How did you get around it ? Somehow the situation is not right yet for you.
Quoted from your log:

--8<--
cd /home/adamr/gccsdk/gcc/srcdir && autogen Makefile.def
AutoGen aborting on signal 11 (Segmentation fault) in state DONE
--8<--

> > > [ 20h build time]
> > A day ?! That's possibly the overhead of having a Windows subsystem
> > then as it takes about 20 minutes on one core of AMD64 X2 4400
> > processor here (Linux).
> 
> Strange. I haven't built GCC3.4.6 in a while, but I seem to remember it
> taking minutes, not hours - how long does 3.4.6 take for you?

I've done the test:

  3.4.6: about 7 minutes real time
  4.1.1: about 25 minutes real time
  
> > I don't mind to have a look at it (zip it first) and compare it with mine.
> 
> http://www.snowstone.org.uk/temp/gcc.zip

The missing cmp is definately something which I see regulary in your
log files and that should be fixed IMHO.  I also see this also happening
during configure stage:

  creating libtool
  /home/adamr/gccsdk/gcc/srcdir/bfd/../ltconfig: line 2860: cmp: command not found

which could perhaps explain that when you restart the build it detects
reconfiguration.

> [...]
> > What you see is the internal build detection going off on the fact that
> > it detects meaningful configuration differences.  I'm not sure why this
> > goes off in your case (as I don't think you have reconfigured one of the
> > parts of the build tree) but it could be because of the failing 'cmp'
> > binary. I would install it and see if you have this problem when:
> > 
> >   $ cd builddir-cross
> >   $ make
> >   $ make install
> 
> Hmm, well this time I got:
> 
> 
>   configure: error: changes in the environment can compromise the build
>   configure: error: run `make distclean' and/or `rm ./config.cache' and start over
> 
>   make[1]: *** [configure-target-libunixlib] Error 1
>   make[1]: Leaving directory `/home/adamr/gccsdk/gcc/builddir-cross'
>   make: *** [all] Error 2
> 
> 
> If I do a "make distclean" is that going to take another 20 hours?

As your configuration is not in a sane state you risk to have end up with
the same error when doing "make distclean".  One of the first things all
Makefile do there is to check if the configuration has changed and if so
regenerate the Makefile again (yes, the one you're executing) and restart
it with the same target.  A bit bizar the first time you realise this (well
at least to me) but that's part of the gnu autotools magic.

So feel free to do "make distclean" for its entertaining value ;-) but
I would rather go for the following:

1) Do a 'svn update' so you have this fix
<URL:http://www.riscos.info/websvn/listing.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2F&rev=3281&sc=1>
   That's a fix for feedback I got from Peter and ensures that ./build-it
   will always start from scratch and doesn't reuse anything.  The ultimate
   restart point.
2) Restart your build from scratch with ./build-it as you did before.

I'm interested in your build log file afterwards as I can compare it with
mine and perhaps we can find other meaningful differences.

After a succesful build, you should be able to run
"$GCCSDK_INSTALL_CROSSBIN/arm-unknown-riscos-gcc --version" and that should
say something like:

--8<--
arm-unknown-riscos-gcc (GCC) 4.1.1 (GCCSDK GCC 4.1.1 pre-release 2)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--8<--

[ And as said before, after a ./install-env you can use Autobuilder. ]

And finally:
3) Check if you can reuse an existing build, by:

   $ cd builddir-cross
   $ make
   $ make install

That should be finished in less than a couple of minutes and rebuild
whatever changes you would have made in srcdir (which you haven't but just
to see if that checking is happening).

John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven




More information about the gcc mailing list