> 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
