Re: m68k toolchain status?

[Michael Schmitz <schmitz@mail.biophys.uni-duesseldorf.de>]

> Michael Schmitz writes:
> > > - gcc-snapshot builds are missing for m68k.
> >
> > Bad build dependency on xulrunner, by brainfart of yours truly. I'll
> > manually queue that one as well.
>
> tell me what is wrong with
>
>   libxul-dev [!kfreebsd-amd64 !knetbsd-i386 !netbsd-i386 !hurd-i386]
>
> please stop your foul language and pass this on the right people, the
> xulrunner maintainers.

Sorry, you got my meaning wrong, or I picked the wrong terms, or both.

What I meant to say is that I ('yours truly') had made a mistake in
assigning the dep-wait for gcc-snapshot (the dep-wait had been logged from
q650, which is one of the buildds I operate). OTOH, xulrunner still
hasn't been built in a more recent version. Maybe I need to get the last
version of libxul-dev from snapshot.

I do not think there is any point in taking this up with the xulrunner
maintainers; the failure to build xulrunner seems to be a matter of
binutils or libc or some other toolchain problem.

Last successful build of xulrunner was on aahz, with the following
versions of toochain packages:

Toolchain package versions: libc6-dev_2.5-3 linux-kernel-headers_2.6.18-7
gcc-4.1_4.1.1-21 g++-4.1_4.1.1-21 binutils_2.17cvs20070426-6
libstdc++6-4.1-dev_4.1.1-21 libstdc++6_4.1.1-21

First failed build was on vault13, using:

Toolchain package versions: libc6-dev_2.5-3 linux-kernel-headers_2.6.18-7
gcc-4.1_4.1.2-12 g++-4.1_4.1.2-12 binutils_2.17cvs20070426-8
libstdc++6-4.1-dev_4.1.2-12 libstdc++6_4.2-20070516-1

followed by vivaldi:

Toolchain package versions: libc6-dev_2.5-11 linux-kernel-headers_2.6.18-7
gcc-4.1_4.1.2-12 g++-4.1_4.1.2-12 binutils_2.17cvs20070426-8
libstdc++6-4.1-dev_4.1.2-12 libstdc++6_4.2-20070609-1

and now kullervo:

Toolchain package versions: libc6-dev_2.5-10 linux-kernel-headers_2.6.18-1
gcc-4.1_4.1.2-13 g++-4.1_4.1.2-13 binutils_2.17cvs20070426-8
libstdc++6-4.1-dev_4.1.2-13 libstdc++6_4.2-20070609-1

Looking at it from a distance, here's a stupid question: is
libstdc++6-4.1-dev_4.1.2-13 supposed to work together with
libstdc++6_4.2-20070609-1?

Anyway, I remeber we investigated the ld failure with a simple test case
at that time and could not find out where the problem originated. Can't
find the mails right now, but I think Stephen came up with the test case
(mid-June).

Hope this helps to explain the situation, and please accept my apology for
the misleading language,

	Michael