Build failure of trunk on i686-pc-gnu-linux

Build failure of trunk on i686-pc-gnu-linux

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

Hello!

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?

#v+
[...]
/home/thomas/tmp/source/gcc/clean/trunk.build/./gcc/xgcc -B/home/thomas/tmp/source/gcc/clean/trunk.build/./gcc/ -B/home/thomas/tmp/source/gcc/clean/trunk.build.install/i686-pc-linux-gnu/bin/ -B/home/thomas/tmp/source/gcc/clean/trunk.build.install/i686-pc-linux-gnu/lib/ -isystem /home/thomas/tmp/source/gcc/clean/trunk.build.install/i686-pc-linux-gnu/include -isystem /home/thomas/tmp/source/gcc/clean/trunk.build.install/i686-pc-linux-gnu/sys-include -g -fkeep-inline-functions -O2  -O2 -g -O2   -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc -I../../../trunk/libgcc -I../../../trunk/libgcc/. -I../../../trunk/libgcc/../gcc -I../../../trunk/libgcc/../include -I../../../trunk/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c ../../../trunk/libgcc/../gcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS
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
make[2]: Leaving directory `/fs/data/mount/home/thomas/tmp/source/gcc/clean/trunk.build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/fs/data/mount/home/thomas/tmp/source/gcc/clean/trunk.build'
make: *** [all] Error 2
#v-

I found this problem reported by Marco Trudel at
<http://gcc.gnu.org/ml/gcc/2007-01/msg00963.html>, but that's from
January.


Regards,
 Thomas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: Build failure of trunk on i686-pc-gnu-linux

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 2612 bytes --]

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 :-|).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: Build failure of trunk on i686-pc-gnu-linux

[Ismail Dönmez]

Tuesday 20 November 2007 Tarihinde 03:12:35 yazmıştı:
> Does someone provide a Git mirror of the GCC repository?  Or a CVS
> mirror?  (With CVS you at least know what to expect...)

Nice people over infradead.org does, 
http://git.infradead.org/?p=gcc.git;a=summary .

To clone 
git clone git://git.infradead.org/gcc.git

Regards,
ismail

-- 
Faith is believing what you know isn't so -- Mark Twain

Re: Build failure of trunk on i686-pc-gnu-linux

[Andrew Pinski]

On 11/19/07, Thomas Schwinge <tschwinge@gnu.org> wrote:
> 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 think the reason why nobody answered is because we are all busy
doing real work.


> 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?)

I use svn stat all the time without any issues.  It does take over a
half a minute for some of my local trees (they are not FSF GCC checks
and include a lot more files) but it is reasonable.

What version of svn are you using?  It might be something which is
already fixed in a newer version of svn.


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

Really svn is not the issue if you know what you are doing.  See above.

Really what version of svn are you using because some older versions
of svn created many empty files which were not needed.

Thanks,
Andrew Pinski

Re: Build failure of trunk on i686-pc-gnu-linux

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 2249 bytes --]

Hello!

On Mon, Nov 19, 2007 at 05:22:52PM -0800, Andrew Pinski wrote:
> On 11/19/07, Thomas Schwinge <tschwinge@gnu.org> wrote:
> > 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 think the reason why nobody answered is because we are all busy
> doing real work.

Now I'm not sure about how to take that one.  I for sure didn't mean to
blame or even insult someone of you GCC people.  But then, why do you now
in turn think I wasn't trying to get ``real work'' done?


> > 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?)
> 
> I use svn stat all the time without any issues.  It does take over a
> half a minute for some of my local trees (they are not FSF GCC checks
> and include a lot more files) but it is reasonable.

On a freshly booted, otherwise idle system:

#v+
$ time svn status
M      libgcc/config.host
M      gcc/config.gcc
M      gcc/unwind-generic.h
M      gcc/config/i386/gnu.h
M      gcc/config/gnu.h

real    2m17.461s
user    0m2.972s
sys     0m2.736s
#v-

Subsequent runs, as long as the data is still being cached, are much
faster, of course.

> What version of svn are you using?  It might be something which is
> already fixed in a newer version of svn.

This is what Ubuntu feisty ships, which is version 1.4.3 (r23084), Ubuntu
package version 1.4.3dfsg1-1ubuntu1.2.


Regards,
 Thomas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]