Opened 5 years ago
Closed 5 years ago
#1637 closed defect (fixed)
Build fails on Debian/armel
Reported by: | felix winkelmann | Owned by: | |
---|---|---|---|
Priority: | critical | Milestone: | 5.2 |
Component: | core libraries | Version: | 5.1.0 |
Keywords: | Cc: | ||
Estimated difficulty: | medium |
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.
Change History (7)
comment:1 Changed 5 years ago by
comment:3 Changed 5 years ago by
Potentially caused by code generation issue. https://svnweb.freebsd.org/ports/head/lang/gcc8-devel/Makefile?view=markup&pathrev=507194 fixes that.
comment:4 Changed 5 years ago by
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)
comment:5 Changed 5 years ago by
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)
comment:6 Changed 5 years ago by
Commit 4746bd9556b7650c279c718bb0d5edf2c5ca5b01 fixes the problem for me.
It would be nice to get confirmation that the original problem is gone too.
comment:7 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Davide Puricelli got back to us and the bug is gone on this platform.
Relevant part from the build logs: