Status on cross builds

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Status on cross builds

Joel Brobecker
Just as a sanity check before creating the 6.4 branch, I ran the
gdb_mbuild.sh script. Here are the results:

* Build fails, but succeeds if we remove -Werror:
        arm-elf: compile failed
        avr: compile failed
        frv-elf: compile failed
        h8300-elf: compile failed
        ia64-linux-gnu: compile failed
        m32r-elf: compile failed
        m68hc11-elf: compile failed
        mips-elf: compile failed
        sh-elf: compile failed
        v850-elf: compile failed

  Andrew Stubbs just committed a patch so sh-elf should now compile
  with -Werror.

* Build fails, even without -Werror:
        ms1-elf: compile failed
        configure: error: "*** Gdb does not support target ms1-unknown-elf"

* Build fails, even without -Werror:
        sh64-elf: compile failed
        make[1]: *** No rule to make target `../sim/sh64/libsim.a', needed by `gdb'.  Stop.


I haven't had time to look at the two real build failures, but I don't
think we should delay the branch for them. Similarly, being able to build
all the cross configurations above without warnings is not, in my opinion,
a must have for the release. It would be nice to have everything fixed in
head, though.

--
Joel
Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Daniel Jacobowitz-2
On Wed, Nov 02, 2005 at 10:17:56AM -0800, Joel Brobecker wrote:
> Just as a sanity check before creating the 6.4 branch, I ran the
> gdb_mbuild.sh script. Here are the results:
>
> * Build fails, but succeeds if we remove -Werror:

A huge number of configurations do not currently build without -Werror,
due to unfinished gdb_byte changes.

Honestly, I recommend we disable -Werror for this release, if we aren't
going to spend a month fixing them.  You think the cross builds are
bad?  It's the natives that really break badly.

--
Daniel Jacobowitz
CodeSourcery, LLC
Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Eli Zaretskii
> Date: Wed, 2 Nov 2005 13:24:27 -0500
> From: Daniel Jacobowitz <[hidden email]>
> Cc: [hidden email]
>
> Honestly, I recommend we disable -Werror for this release, if we aren't
> going to spend a month fixing them.

I concur.
Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Mark Kettenis
In reply to this post by Daniel Jacobowitz-2
> Date: Wed, 2 Nov 2005 13:24:27 -0500
> From: Daniel Jacobowitz <[hidden email]>
>
> Honestly, I recommend we disable -Werror for this release, if we aren't
> going to spend a month fixing them.  You think the cross builds are
> bad?  It's the natives that really break badly.

But it's only enabled in gdb_mbuild.sh.  That hardly matters for the
release.  By default, we still configure without -Werror.  I really
think that's why so many stuff has problems with -Werror.  So instead
I think, we should *enable* -Werror by default on the main branch
after the release branch has been made.  I volunteer to do the
necessary legwork and create a suitable patch.

Mark



Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Mark Kettenis
In reply to this post by Joel Brobecker
> Date: Wed, 2 Nov 2005 10:17:56 -0800
> From: Joel Brobecker <[hidden email]>
>
> Just as a sanity check before creating the 6.4 branch, I ran the
> gdb_mbuild.sh script. Here are the results:
>
> * Build fails, but succeeds if we remove -Werror:
>         arm-elf: compile failed
>         avr: compile failed
>         frv-elf: compile failed
>         h8300-elf: compile failed
>         ia64-linux-gnu: compile failed
>         m32r-elf: compile failed
>         m68hc11-elf: compile failed
>         mips-elf: compile failed
>         sh-elf: compile failed
>         v850-elf: compile failed

This is an interresting list.  It might be a bit biased by the version
of GCC used by Joel, but it either means that these targets aren't
properly maintained, or that its maintainer needs to be educated about
-Werror.  Or perhaps we should enable -Werror by default on the main
branch.  Anyway, we should consider these targets aa candidates for
removal after 6.4.

> * Build fails, even without -Werror:
>         ms1-elf: compile failed
>         configure: error: "*** Gdb does not support target ms1-unknown-elf"

Kevin, looks like you forgot to check in some crucial part for ms1.

Mark
Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Stephane Carrez
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Kettenis wrote:

>>Date: Wed, 2 Nov 2005 10:17:56 -0800
>>From: Joel Brobecker <[hidden email]>
>>
>>Just as a sanity check before creating the 6.4 branch, I ran the
>>gdb_mbuild.sh script. Here are the results:
>>
>>* Build fails, but succeeds if we remove -Werror:
>>        arm-elf: compile failed
>>        avr: compile failed
>>        frv-elf: compile failed
>>        h8300-elf: compile failed
>>        ia64-linux-gnu: compile failed
>>        m32r-elf: compile failed
>>        m68hc11-elf: compile failed
>>        mips-elf: compile failed
>>        sh-elf: compile failed
>>        v850-elf: compile failed
>
>
> This is an interresting list.  It might be a bit biased by the version
> of GCC used by Joel, but it either means that these targets aren't
> properly maintained, or that its maintainer needs to be educated about
> -Werror.  Or perhaps we should enable -Werror by default on the main
> branch.  Anyway, we should consider these targets aa candidates for
> removal after 6.4.
>

I'll speak for m68hc11-elf and say: NO!

It builds without warnings with gcc 3.2.  gcc 3.4 has warnings
due to introduction of gdb_byte (not detected by gcc 3.2).

I have a fix and will commit as soon as possible.

Stephane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDanmJNyQxO2LzKT0RAr9vAKCWbHuE+G2S7Osg05YHzPOqFrnuDwCgvkDk
VToOC8TYjFUdcZF/8g94Erk=
=X56U
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Mark Kettenis
> Date: Thu, 03 Nov 2005 21:56:41 +0100
> From: Stephane Carrez <[hidden email]>
>
> Mark Kettenis wrote:
> >>Date: Wed, 2 Nov 2005 10:17:56 -0800
> >>From: Joel Brobecker <[hidden email]>
> >>
> >>Just as a sanity check before creating the 6.4 branch, I ran the
> >>gdb_mbuild.sh script. Here are the results:
> >>
> >>* Build fails, but succeeds if we remove -Werror:
> >>        arm-elf: compile failed
> >>        avr: compile failed
> >>        frv-elf: compile failed
> >>        h8300-elf: compile failed
> >>        ia64-linux-gnu: compile failed
> >>        m32r-elf: compile failed
> >>        m68hc11-elf: compile failed
> >>        mips-elf: compile failed
> >>        sh-elf: compile failed
> >>        v850-elf: compile failed
> >
> >
> > This is an interresting list.  It might be a bit biased by the version
> > of GCC used by Joel, but it either means that these targets aren't
> > properly maintained, or that its maintainer needs to be educated about
> > -Werror.  Or perhaps we should enable -Werror by default on the main
> > branch.  Anyway, we should consider these targets aa candidates for
> > removal after 6.4.
> >
>
> I'll speak for m68hc11-elf and say: NO!

:-)

> It builds without warnings with gcc 3.2.  gcc 3.4 has warnings
> due to introduction of gdb_byte (not detected by gcc 3.2).

So the list is a bit biased then.

> I have a fix and will commit as soon as possible.

Great!

Mark
Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Daniel Jacobowitz-2
In reply to this post by Mark Kettenis
On Thu, Nov 03, 2005 at 12:28:02AM +0100, Mark Kettenis wrote:

> > Date: Wed, 2 Nov 2005 13:24:27 -0500
> > From: Daniel Jacobowitz <[hidden email]>
> >
> > Honestly, I recommend we disable -Werror for this release, if we aren't
> > going to spend a month fixing them.  You think the cross builds are
> > bad?  It's the natives that really break badly.
>
> But it's only enabled in gdb_mbuild.sh.  That hardly matters for the
> release.  By default, we still configure without -Werror.  I really
> think that's why so many stuff has problems with -Werror.  So instead
> I think, we should *enable* -Werror by default on the main branch
> after the release branch has been made.  I volunteer to do the
> necessary legwork and create a suitable patch.

Sorry, we get -Werror by default for the various directories from
binutils.  I was close.

After a release would be the right time to switch it on for gdb, if
ever.  But we would need broad build testing from CVS on the native
platforms, and I don't think we've _ever_ had that.

--
Daniel Jacobowitz
CodeSourcery, LLC
Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Mark Kettenis
> Date: Thu, 3 Nov 2005 16:12:21 -0500
> From: Daniel Jacobowitz <[hidden email]>
>
> On Thu, Nov 03, 2005 at 12:28:02AM +0100, Mark Kettenis wrote:
> > > Date: Wed, 2 Nov 2005 13:24:27 -0500
> > > From: Daniel Jacobowitz <[hidden email]>
> > >
> > > Honestly, I recommend we disable -Werror for this release, if we aren't
> > > going to spend a month fixing them.  You think the cross builds are
> > > bad?  It's the natives that really break badly.
> >
> > But it's only enabled in gdb_mbuild.sh.  That hardly matters for the
> > release.  By default, we still configure without -Werror.  I really
> > think that's why so many stuff has problems with -Werror.  So instead
> > I think, we should *enable* -Werror by default on the main branch
> > after the release branch has been made.  I volunteer to do the
> > necessary legwork and create a suitable patch.
>
> Sorry, we get -Werror by default for the various directories from
> binutils.  I was close.

Ah yes, we might want to switch that off for the release.  I think
-Werror there caused a few issues on some HP-UX versions, and I'm not
sure I fixed all of those.  But then there's always --disable-werror.

> After a release would be the right time to switch it on for gdb, if
> ever.  But we would need broad build testing from CVS on the native
> platforms, and I don't think we've _ever_ had that.

Well, I think it's safe to assume that native platforms that haven't
been built during the 6.3 -> 6.4 cycle, will be broken anyway.  If we
really care about -Werror (and I think we should, bacause it catches
sloppy code and real bugs) then the only way to keep our code
warning-free is enabling it.  That forces people to fix the problems
in the code they care about.  We can always disable it again shortly
before release if we're not confident that all problems have been
fixed.

Mark
Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Daniel Jacobowitz-2
On Thu, Nov 03, 2005 at 11:51:06PM +0100, Mark Kettenis wrote:
> Well, I think it's safe to assume that native platforms that haven't
> been built during the 6.3 -> 6.4 cycle, will be broken anyway.  If we

This I'm not sure about...

> really care about -Werror (and I think we should, bacause it catches
> sloppy code and real bugs) then the only way to keep our code
> warning-free is enabling it.  That forces people to fix the problems
> in the code they care about.  We can always disable it again shortly
> before release if we're not confident that all problems have been
> fixed.

But this part is fine by me.

--
Daniel Jacobowitz
CodeSourcery, LLC
Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Corinna Vinschen
In reply to this post by Mark Kettenis
On Nov  3 00:34, Mark Kettenis wrote:

> > Date: Wed, 2 Nov 2005 10:17:56 -0800
> > From: Joel Brobecker <[hidden email]>
> >
> > Just as a sanity check before creating the 6.4 branch, I ran the
> > gdb_mbuild.sh script. Here are the results:
> >
> > * Build fails, but succeeds if we remove -Werror:
> >         arm-elf: compile failed
> >         avr: compile failed
> >         frv-elf: compile failed
> >         h8300-elf: compile failed
> >         ia64-linux-gnu: compile failed
> >         m32r-elf: compile failed
> >         m68hc11-elf: compile failed
> >         mips-elf: compile failed
> >         sh-elf: compile failed
> >         v850-elf: compile failed
>
> This is an interresting list.  It might be a bit biased by the version
> of GCC used by Joel, but it either means that these targets aren't
> properly maintained, or that its maintainer needs to be educated about
> -Werror.  Or perhaps we should enable -Werror by default on the main
> branch.  Anyway, we should consider these targets aa candidates for
> removal after 6.4.

I don't think so at all.  The -Werror results are just due to the usage
of gdb_byte and I don't think that qualifies for treating these targets
as broken.  It only means that nobody touched the targets after the
gdb_byte change has been introduced, but that doesn't invalidate the
targets as a whole.  This point of view is somewhat excessive, IMHO.

FWIW, I'll have a look into h8300-elf, sh-elf and v850-elf at one point,
but the change is very likely only mechanical and could have been done
by everybody who has build these targets lately.


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.
Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Andreas Schwab
Corinna Vinschen <[hidden email]> writes:

> I don't think so at all.  The -Werror results are just due to the usage
> of gdb_byte and I don't think that qualifies for treating these targets
> as broken.  It only means that nobody touched the targets after the
> gdb_byte change has been introduced, but that doesn't invalidate the
> targets as a whole.  This point of view is somewhat excessive, IMHO.

Especially since there are massive warnings in generic code.  For example:

valprint.c: In function 'partial_memory_read':
valprint.c:1047: warning: pointer targets in passing argument 2 of 'target_read_
memory' differ in signedness
valprint.c:1058: warning: pointer targets in passing argument 2 of 'target_read_
memory' differ in signedness
valprint.c: In function 'val_print_string':
valprint.c:1168: warning: pointer targets in passing argument 1 of 'extract_unsi
gned_integer' differ in signedness
valprint.c:1207: warning: pointer targets in passing argument 2 of 'target_read_
memory' differ in signedness
valprint.c:1208: warning: pointer targets in passing argument 1 of 'extract_unsi
gned_integer' differ in signedness
valprint.c:1230: warning: pointer targets in passing argument 2 of 'current_lang
uage->la_printstr' differ in signedness
valprint.c: In function '_initialize_valprint':
valprint.c:1388: warning: unused variable 'c'

Andreas.

--
Andreas Schwab, SuSE Labs, [hidden email]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Kevin Buettner
In reply to this post by Joel Brobecker
On Wed, 2 Nov 2005 10:17:56 -0800
Joel Brobecker <[hidden email]> wrote:

> Just as a sanity check before creating the 6.4 branch, I ran the
> gdb_mbuild.sh script. Here are the results:
>
> * Build fails, but succeeds if we remove -Werror:
>         arm-elf: compile failed
>         avr: compile failed
>         frv-elf: compile failed
>         h8300-elf: compile failed
>         ia64-linux-gnu: compile failed
>         m32r-elf: compile failed
>         m68hc11-elf: compile failed
>         mips-elf: compile failed
>         sh-elf: compile failed
>         v850-elf: compile failed

I'll take a look at ia64-linux-gnu and frv-elf.  Do you want -Werror cleanups
applied to both the release branch and mainline or mainline only?

> * Build fails, even without -Werror:
>         ms1-elf: compile failed
>         configure: error: "*** Gdb does not support target ms1-unknown-elf"

This is very strange.  I just did a clean checkout and managed to build
ms1-elf _with_ -Werror.  (I did the build on a Fedora Core 3 machine if that
matters.)
Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Joel Brobecker
> I'll take a look at ia64-linux-gnu and frv-elf.  Do you want -Werror cleanups
> applied to both the release branch and mainline or mainline only?

IMO, only mainline is fine, especially if the warnings do not point
at a blocking bug.

> > * Build fails, even without -Werror:
> >         ms1-elf: compile failed
> >         configure: error: "*** Gdb does not support target ms1-unknown-elf"
>
> This is very strange.  I just did a clean checkout and managed to build
> ms1-elf _with_ -Werror.  (I did the build on a Fedora Core 3 machine if that
> matters.)

Strange indeed. I'm redoing the build right now, so I'll let you know
if I still see some problems, and what they are if applicable.

--
Joel
Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Joel Brobecker
> > This is very strange.  I just did a clean checkout and managed to build
> > ms1-elf _with_ -Werror.  (I did the build on a Fedora Core 3 machine if that
> > matters.)
>
> Strange indeed. I'm redoing the build right now, so I'll let you know
> if I still see some problems, and what they are if applicable.

Just for the record, I indeed managed to build it without problems
using a different machine. Not sure what happened, perhaps an unwanted
side effect of restarting a build that previously failed, or something
like this. The 6.4 branch builds with -Werror if I apply the following
fix:

        [COMMIT] Fix warning in event-top.c
        http://sourceware.org/ml/gdb-patches/2005-11/msg00028.html

--
Joel
Reply | Threaded
Open this post in threaded view
|

Re: Status on cross builds

Kevin Buettner
In reply to this post by Joel Brobecker
On Mon, 7 Nov 2005 14:24:31 -0800
Joel Brobecker <[hidden email]> wrote:

> > I'll take a look at ia64-linux-gnu and frv-elf.  Do you want -Werror cleanups
> > applied to both the release branch and mainline or mainline only?
>
> IMO, only mainline is fine, especially if the warnings do not point
> at a blocking bug.

I've just committed some suitable fixes to the mainline which allow
ia64-linux-gnu and frv-elf to once again build using -Werror.

The frv-elf fixes were all gdb_byte related and the ia64 fix was a
one-liner which simply changed a floatformat related type.  As such,
I don't think these need to go on the release branch, though if someone
wants them there, I'm willing to commit to the branch as well.

Kevin