Bug#892167: gcc-8: go and libgo testsuites fails on amd64 (and other arches)
Source: gcc-8 Version: 8-20180218-1 Severity: important Tags: sid, buster Usertags: testsuite, gccgo, libgo, amd64 Hi, Running the testsuite for go and libgo with the command make -C build check-go 2>&1 | tee ../make-check-go-8-8-20180218-1.log reveals that most go tests fails: (The test suite is disabled in the buildds compilation of gcc-8) tail build/gcc/testsuite/go/go.sum === go Summary === # of expected passes518 # of untested testcases 834 This is due to the following: less build/gcc/testsuite/go/go.log checksyms: found unexpected symbol "__libc_start_main@@GLIBC_2.2.5" FAIL: checksyms Also four libgo tests fail: tail build/x86_64-linux-gnu/libgo/libgo.sum === libgo Summary for unix === # of expected passes158 # of unexpected failures4 less build/x86_64-linux-gnu/libgo/libgo.log FAIL: crypto/sha1 FAIL: golang_org/x/crypto/chacha20poly1305/internal/chacha20 FAIL: golang_org/x/crypto/curve25519 FAIL: golang_org/x/net/lex/httplex All fails are due to: (the error is repeated hundreds of times) /tmp/ccjPhx1C.s:9920: Error: leb128 operand is an undefined symbol: .LVU42 FAIL: crypto/sha1 /tmp/ccJQhkXG.s:8490: Error: leb128 operand is an undefined symbol: .LVU355 FAIL: golang_org/x/crypto/chacha20poly1305/internal/chacha20 /tmp/ccsHI96b.s:18224: Error: leb128 operand is an undefined symbol: .LVU1591 FAIL: golang_org/x/crypto/curve25519 /tmp/ccidCXTz.s:17050: Error: leb128 operand is an undefined symbol: .LVU531 FAIL: golang_org/x/net/lex/httplex The above errors does also happen on other atchtectures, but only reported here for amd64. Thanks!
Bug#892217: [PATCH] libffi: Please add support for the riscv64 architecture
Source: libffi Version: 3.3~20180131 Severity: wishlist X-Debbugs-CC: debian-ri...@lists.debian.org Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, we are in the process of bootstrapping a Debian port for the riscv64 architecture (https://wiki.debian.org/RISC-V). The libffi package is part of the build-dependency chain for the essential package set, so we need to build it for riscv64 to be able to complete the bootstrap process. Current upstream libffi doesn't yet have support for the RISC-V architecture, but a pull request to add it has been submitted: https://github.com/libffi/libffi/pull/281/ respectively https://patch-diff.githubusercontent.com/raw/libffi/libffi/pull/281.patch The pull request has been authored by one of the Fedora riscv64 porters and the Fedora riscv64 port already uses this patchset. It would be great if you could add the patchset to the Debian libffi package as well. The RISC-V support provided by the patchset is not all-encompassing (please cf. the last comment from Stefan O'Rear in the pull request), but it provides the same amount of features that libffi has for a number of other Debian-supported architectures, so that shouldn't be a problem. The symbols file would need to be adjusted, though: dh_makeshlibs -plibffi7 --add-udeb=libffi7-udeb dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libffi7/DEBIAN/symbols doesn't match completely debian/libffi7.symbols --- debian/libffi7.symbols (libffi7_3.3~20180131-2_riscv64) +++ dpkg-gensymbols50ytax 2018-03-06 21:11:57.533480937 + @@ -2,5 +2,5 @@ (symver)LIBFFI_BASE_7.0 3.3~20170512 (symver)LIBFFI_BASE_7.1 3.3~20170512 (symver)LIBFFI_CLOSURE_7.0 3.3~20170512 - (symver|arch=!hppa !ia64 !m68k !mips !mipsel !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !sh4)LIBFFI_COMPLEX_7.0 3.3~20170512 - (symver|arch=!hppa !ia64 !m68k !sh4)LIBFFI_GO_CLOSURE_7.0 3.3~20170512 +#MISSING: 3.3~20180131-2# (symver|arch=!hppa !ia64 !m68k !mips !mipsel !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !sh4)LIBFFI_COMPLEX_7.0 3.3~20170512 +#MISSING: 3.3~20180131-2# (symver|arch=!hppa !ia64 !m68k !sh4)LIBFFI_GO_CLOSURE_7.0 3.3~20170512 Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Processed: Re: Bug#892221: python-jpype: FTBFS on hurd-i386: jni_md_platform is not defined
Processing control commands: > clone -1 -2 Bug #892221 [src:python-jpype] python-jpype: FTBFS on hurd-i386: jni_md_platform is not defined Bug 892221 cloned as bug 892225 > reassign -2 gcj-6 6.4.0-12 Bug #892225 [src:python-jpype] python-jpype: FTBFS on hurd-i386: jni_md_platform is not defined Bug reassigned from package 'src:python-jpype' to 'gcj-6'. No longer marked as found in versions python-jpype/0.6.2+dfsg-2. Ignoring request to alter fixed versions of bug #892225 to the same values previously set Bug #892225 [gcj-6] python-jpype: FTBFS on hurd-i386: jni_md_platform is not defined Marked as found in versions gcc-6/6.4.0-12. > retitle -2 gcj-6: jawt_md.h and jni_md.h are in linux subdirectory on > kFreeBSD and GNU/Hurd Bug #892225 [gcj-6] python-jpype: FTBFS on hurd-i386: jni_md_platform is not defined Changed Bug title to 'gcj-6: jawt_md.h and jni_md.h are in linux subdirectory on kFreeBSD and GNU/Hurd' from 'python-jpype: FTBFS on hurd-i386: jni_md_platform is not defined'. -- 892221: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892221 892225: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892225 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
