Hello!

On Sun, Nov 18, 2007 at 08:57:43PM +0100, I wrote:
> What am I doing wrong if building the trunk natively on i686-pc-gnu-linux
> with ``--disable-nls --enable-languages=c --with-arch=i586'' has been
> failing as follows for several days already?

> In file included from ../../../trunk/libgcc/../gcc/unwind-dw2.c:40:
> ../../../trunk/libgcc/../gcc/unwind-pe.h:133: error: expected declaration specifiers or '...' before '_uleb128_t'
> ../../../trunk/libgcc/../gcc/unwind-pe.h: In function 'read_uleb128':
> ../../../trunk/libgcc/../gcc/unwind-pe.h:137: error: '_uleb128_t' undeclared (first use in this function)
> [...]
> make[3]: *** [unwind-dw2.o] Error 1
> make[3]: Leaving directory `/fs/data/mount/home/thomas/tmp/source/gcc/clean/trunk.build/i686-pc-linux-gnu/libgcc'
> make[2]: *** [all-stage1-target-libgcc] Error 2

I'm glad that nobody answered.  I've been doing nothing wrong.  And also
it's not someone else's fault.  But let me tell you what in fact was
going wrong.

I had a some-months-old checkout of GCC trunk on my disk.  Now I needed
such a checkout and thought: ``Good that the old one -- which I only used
once for compiling and didn't do any modifications to it -- is still
laying around: I'll simply use that one after having ran a ``svn update''
in there.''  I also ran a ``svn diff''.  No modifications shown.  Also, I
attempted a ``svn status'', but as that one -- apart from completely
saturating the system's disk I/O (Pentium M with 1.7 GHz, 768 MiB of RAM)
-- didn't give any output after having it had running for half a minute,
I terminated it again.  After all, both ``svn update'' and ``svn diff''
had made me think that the tree was as clean as it could be.  (SVN was
made for easy transition from CVS, right?)

But in fact that tree had modifications.  530 files, as I figured out
just now by diffing against a fresh checkout and by having ``svn status''
saturate the systems disk I/O for 4.22 min (unbelievable -- do you people
really use this day in, day out?).  So, I had 530 files in my tree that
were no longer (?) in the upstream trunk.  How could this happen?  All I
was ever doing was running ``svn update''.

One of these files was a stale `gcc/unwind.h', which induced the above
build breakage.


What to learn from this?  Don't use SVN?  ``What then?'' is the next
question.  And I'm sure you've been debating a lot before switching to
SVN.


Does someone provide a Git mirror of the GCC repository?  Or a CVS
mirror?  (With CVS you at least know what to expect...)


Regards,
 Thomas


PS: I'll now try to forget these wasted hours (literally hours :-|).