I've built the package on another amd64 system and it builds smoothly as well. Are there any other comments on the package? On 04.12.2011 20:53, Arno Töll wrote: > Hello, > > On 04.12.2011 20:15, Andrea Veri wrote: >> On Sun, 04 Dec 2011, Mikołaj Izdebski wrote: > >>> If it builds on your box it doesn't mean it does on mine. I also used >>> up-to-date sid. I tried 3 times in row with similar results. > >> If you build a package on a "dirty" system and not on a clean chroot >> you'll get many many FTBFS you wouldn't get on a pbuilder. > >> Get yourself into a chroot and try again, I'm sure the result will be >> the same as mine. > > I can confirm Andrea's observation. The package builds fine in a clean, > up to date pbuilder chroot. Your build failure indicates a problem where > Oliver - as the maintainer of the affected package - isn't to blame for > anyway. > > Such errors: > > 22:55:31 O: [ 2%] Building CXX object > gemrb/core/CMakeFiles/gemrb_core.dir/Animation.o > 22:55:31 E: g++: internal compiler error: Bus error (program as) > 22:55:31 E: Please submit a full bug report, > 22:55:31 E: with preprocessed source if appropriate. > 22:55:31 E: See <file:///usr/share/doc/gcc-4.6/README.Bugs> for > instructions. > 22:55:31 E: make[3]: *** > [gemrb/core/CMakeFiles/gemrb_core.dir/Animation.o] Error 4 > 22:55:31 E: make[2]: *** [gemrb/core/CMakeFiles/gemrb_core.dir/all] Error 2 > 22:55:31 E: make[1]: *** [all] Error 2 > 22:55:31 E: make: *** [debian/stamp-makefile-build] Error 2 > > > would indicate a problem in the build utils, in this case the GNU as > assembler which crashed. That should never happen, regardless how you > (ab-)use it. Hence, that would be a bug in as if anything. > > However, as neither Andrea nor could I reproduce that and the gcc suite > virtually never crashes in my experience, I'd suspect a hardware failure > on your side. Malfunctioning RAM is a common problem when observing gcc > faults for example. > > >
Attachment:
signature.asc
Description: OpenPGP digital signature