Summary

Build fails on Debian/armel

Metadata

Description

Reported by Davide Puricelli:

 > Some days ago I uploaded the amd64 package to Debian unstable, 
 > so our porting teams could recompile it on every architecture that
 > Debian supports; unfortunately the build process didn't go well
 > everywhere, as you can see from this report page:
 > 
 > https://buildd.debian.org/status/package.php?p=chicken&suite=sid
 > 
 > For now, we can ignore the architectures with a grey background on that
 > page, as they're not full supported by Debian, but the armel fail is
 > serious because it prevents Chicken migration from unstable to testing
 > distribution.
 > 
 > I'm not so up-to-date on chicken internals (and on armel even worse),
 > so I was thinking if you could take a look at build log and tell me
 > if you have a clue about what went wrong and how we can fix it.

Changes and comments

[2019-07-27 22:08:21 UTC] felix wrote:

Relevant part from the build logs:

 old: #s8(-128 -127 -2 -1 0 1 2 126 127)
 new: #s8(127 126 2 1 0 -1 -2 -127 -128)
 
 old: #u16(0 1 2 65534 65535)
 new: #u16(65535 65534 2 1 0)
 
 old: #s16(-32768 -32767 -2 -1 0 1 2 32766 32767)
 new: #s16(32767 32766 2 1 0 -1 -2 -32767 -32768)
 
 old: #u32(0 1 2 4294967294 4294967295)
 new: #u32(4294967295 4294967294 2 1 0)
 make[1]: *** [rules.make:974: check] Error 70
 make[1]: Leaving directory '/<<PKGBUILDDIR>>'
 dh_auto_test: make -j1 check returned exit code 2
 make: *** [debian/rules:16: build-arch] Error 255

[2019-07-28 20:53:35 UTC] sjamaan wrote:

Perhaps fixed by 0f65f998e9af551be9201594651794263f582666?

[2019-11-04 15:09:39 UTC] sjamaan wrote:

Potentially caused by code generation issue. https://svnweb.freebsd.org/ports/head/lang/gcc8-devel/Makefile?view=markup&pathrev=507194 fixes that.

[2019-11-06 19:26:24 UTC] kooda wrote:

I can reproduce the bug (segfault when interpreting the lolevel tests) under these conditions:

CHICKEN 5.1.0 and master (e25965cdd25e521a5622f9712b76843458e887f2) using gcc 9.2.0:

 Using built-in specs.
 COLLECT_GCC=/usr/bin/gcc
 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv6-alpine-linux-musleabihf/9.2.0/lto-wrapper
 Target: armv6-alpine-linux-musleabihf
 Configured with: /home/buildozer/aports/main/gcc/src/gcc-9.2.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --build=armv6-alpine-linux-musleabihf --host=armv6-alpine-linux-musleabihf --target=armv6-alpine-linux-musleabihf --with-pkgversion='Alpine 9.2.0' --enable-checking=release --disable-fixed-point --disable-libstdcxx-pch --disable-multilib --disable-nls --disable-werror --disable-symvers --enable-__cxa_atexit --enable-default-pie --enable-default-ssp --enable-cloog-backend --enable-languages=c,c++,objc,fortran,ada --with-arch=armv6zk --with-tune=arm1176jzf-s --with-fpu=vfp --with-float=hard --with-abi=aapcs-linux --disable-libquadmath --disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer --enable-shared --enable-threads --enable-tls --disable-libitm --with-system-zlib --with-linker-hash-style=gnu
 Thread model: posix
 gcc version 9.2.0 (Alpine 9.2.0)

However, building and testing both CHICKEN 5.1.0 and master with gcc 6.4.0 doesn’t trigger the error.

 COLLECT_GCC=gcc-6
 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv6-alpine-linux-musleabihf/6.4.0/lto-wrapper
 Target: armv6-alpine-linux-musleabihf
 Configured with: /home/buildozer/aports/community/gcc6/src/gcc-6.4.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --build=armv6-alpine-linux-musleabihf --host=armv6-alpine-linux-musleabihf --target=armv6-alpine-linux-musleabihf --program-suffix=-6 --with-pkgversion='Alpine 6.4.0' --enable-checking=release --disable-bootstrap --disable-fixed-point --disable-libstdcxx-pch --disable-multilib --disable-nls --disable-werror --disable-libatomic --disable-libgomp --disable-libitm --disable-libquadmath --disable-symvers --enable-__cxa_atexit --enable-default-pie --enable-cloog-backend --enable-version-specific-runtime-libs --enable-languages=c,c++,java --with-arch=armv6zk --with-tune=arm1176jzf-s --with-fpu=vfp --with-float=hard --with-abi=aapcs-linux --disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer --enable-shared --enable-threads --enable-tls --with-system-zlib --with-jvm-root=/usr/lib/jvm/java-1.5-gcj --with-linker-hash-style=gnu
 Thread model: posix
 gcc version 6.4.0 (Alpine 6.4.0)

[2019-11-06 19:30:04 UTC] kooda wrote:

This (smaller) test case triggers the segfault:

 (import chicken.locative chicken.gc srfi-4)
 
 (define old (u32vector 0 1 2 4294967294 4294967295))
 
 (define new (make-u32vector 5))
 
 (do ((i 0 (add1 i)))
      ((= i 5))
   (let ((loc-src (make-locative old i))
         (loc-dst (make-locative new (- 5 i 1))))
     (locative-set! loc-dst (locative-ref loc-src))))
 
 (assert (eqv? (u32vector-ref old 4) (u32vector-ref new 0)))
 
 (gc #t)

[2019-11-28 13:32:30 UTC] kooda wrote:

Commit 4746bd9556b7650c279c718bb0d5edf2c5ca5b01 fixes the problem for me.

It would be nice to get confirmation that the original problem is gone too.

[2019-12-01 12:48:50 UTC] sjamaan changed status from new to closed

[2019-12-01 12:48:50 UTC] sjamaan set resolution to fixed

[2019-12-01 12:48:50 UTC] sjamaan wrote:

Davide Puricelli got back to us and the bug is gone on this platform.