Results of a multi-build (not good)

Results of a multi-build (not good)

[Richard Earnshaw]

I've just tried my multi-build script out which uses the configurations 
specified in the MAINTAINERS file.  The results aren't particularly 
encouraging:

alpha-dec-osf4.0a build failed
arc-elf build failed
d10v-elf build failed
d30v-elf build failed
fr30-elf build failed
h8300hms build failed
h8500hms build failed
i386-aout build failed
i386-elf build failed
i586-pc-msdosdjgpp build failed
i960-coff build failed
ia64-linux build failed
m32r-elf build failed
m68hc11-elf build failed
m68k-elf build failed
mcore-elf build failed
mcore-pe build failed
mips-elf build failed
mips64-elf build failed
mn10200-elf build failed
mn10300-elf build failed
powerpc-eabi build failed
rs6000-ibm-aix4.1 build failed
s390-linux build failed
sh-elf build failed
sh-hms build failed
sparc-elf build failed
sparc64-elf build failed
v850-elf build failed
xstormy16-elf build failed
z8k-coff build failed

Which leaves only

arm-elf
cris-elf
m88k
ns32k-netbsd
vax-dec-vms5.5

that build successfully.  Not a surprise then to find that, with the 
exception of vax-dec-vms5.5, these are the only ports that don't use 
-Werror.


Most of these failures are the same: PR gdb/409

mn10300 is an exception: it dies somewhere in the sim directory.

R.

Re: Results of a multi-build (not good)

[Andrew Cagney]

What was the build machine?  This testing is, unfortunatly, very very 
sensative to the host.

Andrew

Re: Results of a multi-build (not good)

[Andrew Cagney]

I just relooked at the coma tweak:

	x86-64		(--target=x86_64-linux-gnu, broken)

It should be just:

	x86-64		(--target=x86_64-linux-gnu broken)

if you look at other examples:

	sh		--target=sh-hms,sh-elf ,-Werror

The first ``,'' is to separate the targets:

	sh-hms
	sh-elf

The ``,'' in ,-Werror is part of the list of flags vis:

	--enable-gdb-build-warnings=,-Werror

The ``--target=x86_64-linux-gnu, broken'' line confuses that bit of awk 
(but you won't notice if the output of the script is fed to ``grep -v 
broken''.

Andrew

Re: Results of a multi-build (not good)

[Eli Zaretskii]

On Mon, 11 Mar 2002, Richard Earnshaw wrote:

> that build successfully.  Not a surprise then to find that, with the 
> exception of vax-dec-vms5.5, these are the only ports that don't use 
> -Werror.

IMHO, -Werror is a Bad Idea (tm).  With the current trend in GCC and 
other compilers to print warnings for perfectly valid C, -Werror tends to 
break good code with every new release of GCC, to say nothing of 
development snapshots people use.

I think we should stop using -Werror, except maybe in maintainer's mode.

Re: Results of a multi-build (not good)

[Richard Earnshaw]

> What was the build machine?  This testing is, unfortunatly, very very 
> sensative to the host.
> 
> Andrew
> 

Red Hat 7.1 (x86)  6 cpus 8G Ram

R.

Re: Results of a multi-build (not good)

[Richard Earnshaw]

> I just relooked at the coma tweak:
> 
> 	x86-64		(--target=x86_64-linux-gnu, broken)
> 
> It should be just:
> 
> 	x86-64		(--target=x86_64-linux-gnu broken)
> 

That was part of my fix to MAINTAINERS that went in yesterday.

R.

Re: Results of a multi-build (not good)

[Richard Earnshaw]

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

I've been asked if I could release the multi-build script.  It's attached 
below.

Note that it only builds the debuggers, it doesn't run any tests on them.  
To do that I would need to build and install about 36 sets of complete 
tool chains, which I just don't have space for.  Further, most of them 
wouldn't be much use without either a simulator or a real piece of 
hardware to test them on.

You will need to tweak the variables at the top of the script to your 
local configuration.

R.



[-- Attachment #2: build_gdb_all --]
[-- Type: text/x-script , Size: 2994 bytes --]

#! /bin/sh

# Copyright (C) 2002 Free Software Foundation.
#
# This file is part of GDB.
#
# GDB is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# GDB is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GDB; see the file COPYING.  If not, write to
# the Free Software Foundation, 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
#
########################################################################
#
# VARIOUS OPTIONS YOU WILL NEED TO CONFIGURE FOR LOCAL USE

# Where builds will live
builddir=/home/rearnsha/gnu/gdb-allcross

# Where the sources live
srcdir=/home/rearnsha/gnusrc/utils/src

# Where logs will go.  NB. Must not be a sub-dir of builddir or you 
# will loose them.
logdir=/home/rearnsha/gnu/gdb-logdir

# Must be GNU awk
awk=awk

# Where to look for the list of targets to test
maintainers=${srcdir}/gdb/MAINTAINERS

# Version of make to use; must be GNU make for parallel makes
make=gnumake

# Number of parallel make jobs
par="10"

# END OF CONFIGURATION OPTIONS
#
########################################################################


# Get the list of targets and the build options
alltarg=`${awk} < "${maintainers}" '
  $2 ~ /--target=.*/ {
    targets = gensub (/^.*--target=/, "", 1, $2)
    warnings = gensub (/[)]*$/, "", 1, $3)
    split (targets, targ, /,/)
    for (i in targ) {
        print targ[i], warnings
    }
  }'`

# Back up the log files
cd ${logdir}

if [ -f build.out ]
then
	mv build.out build.old
fi
if [ -f config.out ]
then
	mv config.out config.old
fi
if [ -f fail.sum ]
then
	mv fail.sum fail.old
fi

if [ ! -d ${builddir} ]
then
	echo ${builddir} does not exist
	exit 1
fi

cd ${builddir}

MAKE=${make}
export MAKE

jobs=1
# For each target, configure and build it.
while read targ opts
do
	if [ ${opts} != "broken" ]
	then
		trap 'echo cleaning up ...; rm -rf ${builddir}/*; exit 1' 1 2 15
		echo ${targ}
		mkdir ${targ}
		cd ${targ}
		${srcdir}/configure --target=$targ \
		  --enable-gdb-build-warnings=$opts \
		  >> ${logdir}/config.tout.$targ 2>&1 &
		cd ..
		jobs=`expr ${jobs} + 1`
		if [ ${jobs} -gt ${par} ]
		then
			wait
			jobs=1
		fi
	fi
done << EOF
$alltarg
EOF

wait

cat ${logdir}/config.tout.* > ${logdir}/config.out
rm -f ${logdir}/config.tout.*

for targ in *
do
	cd $targ
	if  ${make} -j ${par} all-gdb >> ${logdir}/build.out 2>&1
	then
		true
	else
		echo ">>>>>>>>>>>>>" >> ${logdir}/fail.sum
		echo "$targ (${opts})" >> ${logdir}/fail.sum 
		tail -20 ${logdir}/build.out >> ${logdir}/fail.sum
		echo >> ${logdir}/fail.sum
		echo $targ build failed
	fi
	rm -rf *
	cd ..
done

Re: Results of a multi-build (not good)

[Andrew Cagney]

> On Mon, 11 Mar 2002, Richard Earnshaw wrote:
> 
> 
>> that build successfully.  Not a surprise then to find that, with the 
>> exception of vax-dec-vms5.5, these are the only ports that don't use 
>> -Werror.
> 
> 
> IMHO, -Werror is a Bad Idea (tm).  With the current trend in GCC and 
> other compilers to print warnings for perfectly valid C, -Werror tends to 
> break good code with every new release of GCC, to say nothing of 
> development snapshots people use.
> 
> I think we should stop using -Werror, except maybe in maintainer's mode.

-Werror is only enabled when someone explicitly specifies it with 
--enable-gdb-warnings=,-Werror.

I don't think -Werror on its own is a problem.  Rather, I think things 
go wrong when it is combined with some options (-Wunused-param) or 
headers (solaris 1.5.1 was bad).  This is also why it isn't enabled by 
default and only a very select set of options are included.

BTW, I currently get only one (valid) failure when doing a build on 
{Free,Net}BSD.

enjoy,
Andrew

Re: Results of a multi-build (not good)

[Andrew Cagney]

> I just relooked at the coma tweak:
>> 
>> x86-64		(--target=x86_64-linux-gnu, broken)
>> 
>> It should be just:
>> 
>> x86-64		(--target=x86_64-linux-gnu broken)
>> 
> 
> 
> That was part of my fix to MAINTAINERS that went in yesterday.


Oops, sorry.

Andrew

Re: Results of a multi-build (not good)

[Andrew Cagney]

> I've been asked if I could release the multi-build script.  It's attached 
> below.
> 
> Note that it only builds the debuggers, it doesn't run any tests on them.  
> To do that I would need to build and install about 36 sets of complete 
> tool chains, which I just don't have space for.  Further, most of them 
> wouldn't be much use without either a simulator or a real piece of 
> hardware to test them on.
> 
> You will need to tweak the variables at the top of the script to your 
> local configuration.


Nice.  Having a script to run is going to be easier than pointing at 
that awk.

One tweak is to try starting each GDB after it is built - this catches 
many multi-arch problems.  Having the script restartable (and leave 
around broken builds) can also be useful.

Andrew

Re: Results of a multi-build (not good)

[Richard Earnshaw]

> > I've been asked if I could release the multi-build script.  It's attached 
> > below.
> > 
> > Note that it only builds the debuggers, it doesn't run any tests on them.  
> > To do that I would need to build and install about 36 sets of complete 
> > tool chains, which I just don't have space for.  Further, most of them 
> > wouldn't be much use without either a simulator or a real piece of 
> > hardware to test them on.
> > 
> > You will need to tweak the variables at the top of the script to your 
> > local configuration.
> 
> 
> Nice.  Having a script to run is going to be easier than pointing at 
> that awk.
> 
> One tweak is to try starting each GDB after it is built - this catches 
> many multi-arch problems.  Having the script restartable (and leave 
> around broken builds) can also be useful.

These are all useful possibilities.   Unfortunately, I don't have enough 
disk quota to leave that many builds lying around.  So I have to clean up 
after each one.

Anyway, you're free to do with the script whatever you want (within the 
constraints of the GPL :-)

R.

Re: Results of a multi-build (not good)

[Eli Zaretskii]

> Date: Tue, 12 Mar 2002 12:11:05 -0500
> From: Andrew Cagney <ac131313@cygnus.com>
> > 
> > IMHO, -Werror is a Bad Idea (tm).  With the current trend in GCC and 
> > other compilers to print warnings for perfectly valid C, -Werror tends to 
> > break good code with every new release of GCC, to say nothing of 
> > development snapshots people use.
> > 
> > I think we should stop using -Werror, except maybe in maintainer's mode.
> 
> -Werror is only enabled when someone explicitly specifies it with 
> --enable-gdb-warnings=,-Werror.

Then how come Richard has failures on platforms that didn't use
that?  Richard, did you enable -Werror explicitly?

Re: Results of a multi-build (not good)

[Richard Earnshaw]

> > > I think we should stop using -Werror, except maybe in maintainer's mode.
> > 
> > -Werror is only enabled when someone explicitly specifies it with 
> > --enable-gdb-warnings=,-Werror.
> 
> Then how come Richard has failures on platforms that didn't use
> that?  Richard, did you enable -Werror explicitly?

I'm using the specifications extracted from the MAINTAINERS file with the 
awk script listed there.

R.

Re: Results of a multi-build (not good)

[Richard Earnshaw]

rearnsha@arm.com said:
> I've just tried my multi-build script out which uses the
> configurations  specified in the MAINTAINERS file.  The results aren't
> particularly  encouraging: 

So with my recent patch for PR 409 applied, things look a little more rosy:

fr30-elf build failed
m32r-elf build failed
mn10300-elf build failed
powerpc-eabi build failed
sh-elf build failed
v850-elf build failed

fr30-elf:
/home/rearnsha/gnusrc/utils/src/sim/fr30/traps.c:22:23: targ-vals.h: No such file or directory

m32r-elf:
/bin/sh /home/rearnsha/gnusrc/utils/src/sim/m32r/../../move-if-change eng.hin engx.h
/bin/sh /home/rearnsha/gnusrc/utils/src/sim/m32r/../../move-if-change mloop.cin mloopx.c
/bin/sh /home/rearnsha/gnusrc/utils/src/sim/m32r/../../move-if-change eng.hin eng.h
mv: cannot stat `eng.hin': No such file or directory

mn10300-elf:
/home/rearnsha/gnusrc/utils/src/sim/mn10300/sim-main.h:43:20: itable.h: No such file or directory
/home/rearnsha/gnusrc/utils/src/sim/mn10300/sim-main.h:44:21: idecode.h: No such file or directory
/home/rearnsha/gnusrc/utils/src/sim/mn10300/sim-main.h:45:21: idecode.h: No such file or directory

powerpc-eabi:
gnumake[2]: *** No rule to make target `hw.h', needed by `corefile.o'.  Stop.

sh-elf:
cc1: warnings being treated as errors
/home/rearnsha/gnusrc/utils/src/gdb/remote-e7000.c: In function `write_small':
/home/rearnsha/gnusrc/utils/src/gdb/remote-e7000.c:1088: warning: long unsigned int format, different type arg (arg 3)
/home/rearnsha/gnusrc/utils/src/gdb/remote-e7000.c:1094: warning: long unsigned int format, different type arg (arg 3)
/home/rearnsha/gnusrc/utils/src/gdb/remote-e7000.c: In function `e7000_read_inferior_memory':
/home/rearnsha/gnusrc/utils/src/gdb/remote-e7000.c:1247: warning: long unsigned int format, different type arg (arg 3)
/home/rearnsha/gnusrc/utils/src/gdb/remote-e7000.c: In function `e7000_read_inferior_memory_large':
/home/rearnsha/gnusrc/utils/src/gdb/remote-e7000.c:1326: warning: long unsigned int format, different type arg (arg 3)
/home/rearnsha/gnusrc/utils/src/gdb/remote-e7000.c:1326: warning: long unsigned int format, different type arg (arg 4)
/home/rearnsha/gnusrc/utils/src/gdb/remote-e7000.c: In function `e7000_insert_breakpoint':
/home/rearnsha/gnusrc/utils/src/gdb/remote-e7000.c:1708: warning: long unsigned int format, different type arg (arg 4)
/home/rearnsha/gnusrc/utils/src/gdb/remote-e7000.c:1713: warning: long unsigned int format, different type arg (arg 3)
/home/rearnsha/gnusrc/utils/src/gdb/remote-e7000.c: In function `e7000_remove_breakpoint':
/home/rearnsha/gnusrc/utils/src/gdb/remote-e7000.c:1752: warning: long unsigned int format, different type arg (arg 3)
/home/rearnsha/gnusrc/utils/src/gdb/remote-e7000.c:1770: warning: long unsigned int format, different type arg (arg 2)


v850-elf:
/home/rearnsha/gnusrc/utils/src/sim/v850/interp.c:5:20: itable.h: No such file or directory

Re: Results of a multi-build (not good)

[Andrew Cagney]

> rearnsha@arm.com said:
> 
>> I've just tried my multi-build script out which uses the
>> configurations  specified in the MAINTAINERS file.  The results aren't
>> particularly  encouraging: 
> 
> 
> So with my recent patch for PR 409 applied, things look a little more rosy:
> 
> fr30-elf build failed
> m32r-elf build failed
> mn10300-elf build failed
> powerpc-eabi build failed
> sh-elf build failed
> v850-elf build failed

Richard,

Using Red Hat Linux 7.2, I got:

	sh-elf (will change to -w and file separate bug report)
	xstormy16-elf (totally puzzling, it didn't configure!)

but not the others.  The only problem I can think of, off hand, is gmake 
vs make (but this is GNU/Linux) or related (configured with absolute vs 
relative paths?).

puzzled,
Andrew

Re: Results of a multi-build (not good)

[Richard Earnshaw]

> > rearnsha@arm.com said:
> > 
> >> I've just tried my multi-build script out which uses the
> >> configurations  specified in the MAINTAINERS file.  The results aren't
> >> particularly  encouraging: 
> > 
> > 
> > So with my recent patch for PR 409 applied, things look a little more rosy:
> > 
> > fr30-elf build failed
> > m32r-elf build failed
> > mn10300-elf build failed
> > powerpc-eabi build failed
> > sh-elf build failed
> > v850-elf build failed
> 
> Richard,
> 
> Using Red Hat Linux 7.2, I got:
> 
> 	sh-elf (will change to -w and file separate bug report)
> 	xstormy16-elf (totally puzzling, it didn't configure!)
> 
> but not the others.  The only problem I can think of, off hand, is gmake 
> vs make (but this is GNU/Linux) or related (configured with absolute vs 
> relative paths?).

I was using -j10 on the make.  Maybe it's missing dependencies.

R.

Re: Results of a multi-build (not good)

[Andrew Cagney]

> Richard,
>> 
>> Using Red Hat Linux 7.2, I got:
>> 
>> sh-elf (will change to -w and file separate bug report)
>> xstormy16-elf (totally puzzling, it didn't configure!)
>> 
>> but not the others.  The only problem I can think of, off hand, is gmake 
>> vs make (but this is GNU/Linux) or related (configured with absolute vs 
>> relative paths?).
> 
> 
> I was using -j10 on the make.  Maybe it's missing dependencies.
> 
> R.

Ah, yes.  The sim directories have a reputation for poor dependency 
specs.  New separate bug.

Andrew