Re: How to trigger new build attempt on m68k?
On Thu, Sep 08, 2005 at 10:01:56PM +0200, Juergen Salk wrote:
> Hi,
>
> my DCMTK 3.5.3-4 packages have recently FTBFS on m68k due to a
> toolchain problem with g++-4.0_4.0.1-3 ("internal compiler error").
> Please see [1] for a discussion about this issue on this list.
> Because this FTBFS on m68k prevents the DCMTK packages from
> entering Etch, I would like to retry the build on m68k with the
> current gcc/g++ version in Sid.
What makes you think it will build now, without any changes in your package?
Does a new gcc version fix the ICE? The last successful build of you package
on my amiga took about 25 hours, the failure on a4000 (about as fast as my
box) happened after 16 hours. With the current backlog on m68k, I would not
recommend requeueing your package without some evidence that it will not fail
with the same problem again. But of course, if you are a DD, you can just
log in to the public m68k machine(s) and try for yourself.
Some data points, that the ICE is probably not fixed yet, a failed log from
monday:
Log for failed build of liferea_0.9.7b-1
Toolchain package versions: libc6-dev_2.3.5-6
linux-kernel-headers_2.6.13+0rc3-1.1 gcc-4.0_4.0.1-6 g++-4.0_4.0.1-6
+binutils_2.16.1-2 libstdc++6-4.0-dev_4.0.1-6 libstdc++6_4.0.1-6
which failed with:
cookies.c: In function 'CookieCutter':
cookies.c:213: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see <URL:file:///usr/share/doc/gcc-4.0/README.Bugs>.
make[4]: *** [liblinet_a-cookies.o] Error 1
If the ICE is magically fixed, we'd be more than happy to know, I assume
that at least half of the 155 current failed builds are due to the gcc ICE.
Of course we will requeue all fails, one gcc-40 works again.
If the build tree on a400 has not been deleted yet, I would suggest starting
by compiling just the file that failed, to save a few hours of CPU time. And
maybe you can try compiling with -O2. Most fails I've seen were with -O3,
but maybe -O1 (or -O) is just as bad, stranger things have happened...
Christian
Reply to: