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 :-|).
signature.asc
Description: Digital signature
