[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#753791: simgrid: FTBFS on hurd-i386

On 07/06/2014 10:45 AM, Matthias Klose wrote:
> Am 06.07.2014 19:06, schrieb Samuel Thibault:
>> Gabriele Giacone, le Sat 05 Jul 2014 03:41:09 +0200, a écrit :
>>> It FTBFS on hurd
>>> [...]
>>> cd /home/user/port/simgrid/simgrid-3.11.1/doc && /usr/bin/javadoc -quiet -d /home/user/port/simgrid/simgrid-3.11.1/doc/html/javadoc/ /home/user/port/simgrid/simgrid-3.11.1/src/bindings/java/org/simgrid/*.java /home/user/port/simgrid/simgrid-3.11.1/src/bindings/java/org/simgrid/*/*.java
>>> Segmentation fault (core dumped)
>> Well, we have been seeing gcj-4.9 crashes in various packages recently.
>> I don't think it's up to simgrid maintainers to look for the bug...
> #753791 and #753604 are two java related build failures on the Hurd, reported on
> July 3 and July 5.  I'm not aware of any changes in GCJ-4.9 itself, which is
> used since May 5.  Is anybody aware of uploads which cause these packages to
> fail to build?
> candidates are the over-eager update of ecj-3.10, and maybe uploaded class files
> built with java8.

Java8 isn't the default-jdk, so local test builds may be done with it,
but we shouldn't see class files in the archive built with it (unless
someone is going out of their way and building in a dirty build

If it's the ecj version, it should be trivial to regress with the latest
upload of ecj to unstable.  But that's not building on hurd [1]:

>  dpkg-source --before-build ecj-3.10.0+3.9.0
>  /usr/bin/fakeroot debian/rules clean
> ls: cannot access /usr/bin/gcj: No such file or directory
>  debian/rules build-arch
> ls: cannot access /usr/bin/gcj: No such file or directory
> Using built-in specs.
> COLLECT_GCC=gcj-4.9
> Target: i486-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.0-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --disable-libmudflap --disable-libitm --disable-libsanitizer --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-hurd-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-hurd-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-hurd-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-multiarch --with-arch=i586 --with-tune=gen
eric --enable-checking=release --build=i486-gnu --host=i486-gnu --target=i486-gnu
> Thread model: posix
> gcc version 4.9.0 (Debian 4.9.0-10) 
> COLLECT_GCC_OPTIONS='-ffilelist-file' '-fsaw-java-file' '-v' '-foutput-class-dir=build/bin' '-C' '-g' '-fbootclasspath=/usr/share/ant/lib/ant.jar:build/bin/:./:/usr/share/java/libgcj-4.9.jar' '-fsyntax-only' '-femit-class-files' '-S' '-o' 'NONE' '-shared-libgcc' '-mtune=generic' '-march=i586'
>  /usr/lib/gcc/i486-gnu/4.9/ecj1 /tmp/cc3tJLfYjx -g -fbootclasspath=/usr/share/ant/lib/ant.jar:build/bin/:./:/usr/share/java/libgcj-4.9.jar -ffilelist-file -foutput-class-dir=build/bin -g -fsource=1.5 -ftarget=1.5 -fzip-dependency /tmp/ccWNinlM.zip
> gcj-4.9: internal compiler error: Segmentation fault (program ecj1)
> libbacktrace could not find executable to open
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
> make: *** [build/stamp-bytecode] Error 4
> dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

I'm trying to get my hurd-i386 VM updated and will look into getting ecj
to build this week.  There are also ecj 3.9 packages for hurd available
on snapshot.debian.org.



Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: