Yes, it's not an infinite loop; it just takes an inordinate amount of time.
The code that triggers this seems to be a long sequence of assignments
initialising elements of a multi-dimensional array.
There are some big variations in the build times on some other
architectures, too. For example on
The problem still seems to occurs with:
- version 6.4.0-3cross1 of gcc-6-arm-linux-gnueabi (on amd64)
- version 7.2.0-7 of gcc-7 (on armel)
It's perhaps not really an infinite loop but just an unreasonably long time.
Perhaps someone should try running it over the weekend...
Package: gcc-6-arm-linux-gnueabi
Version: 6.3.0-18cross1
This is not specific to cross-compiling and not even to gcc-6.
We noticed the infinite loop when the buildd tries to build rnahybrid:
https://buildd.debian.org/status/logs.php?pkg=rnahybrid&arch=armel
It seems to be easy to reproduce with
I'd say this is a bug in dpkg-shlibdeps in dpkg-dev.
Referring to the example above, on arm64 "test" does depend on
ld-linux-aarch64.so.1 because, although "__stack_chk_guard" is defined
in "test", there's also a relocation referring to the one in
/lib/ld-linux-aarch64.so.1:
$ nm test | grep stac
Package: g++-4.9
Version: 4.9.2-21
$ g++ -O3 -c source.i
cpxfiddle.cc: In function 'void functie(Type, Type, const
commandlineinput&) [with Type = float]':
cpxfiddle.cc:625:65: internal compiler error: in expand_fix, at optabs.c:5365
Please submit a full bug report,
with preprocessed source if app
Source: libffi
Version: 3.1-2
Tags: patch
The latest python-cffi (0.9.2-2) seems to have exposed a bug in libffi
on arm64:
https://buildd.debian.org/status/package.php?p=python-cffi&suite=sid
It seems to involve the case of small structs, that could be passed in
registers, being passed on the st
> please recheck with 4.9.2 and trunk (gcc-snapshot). In the past I had mixed
> results with precompiled headers on AArch64.
I was able to reproduce the problem with aegisub and with qtbase-opensource-src.
Replacing 4.9.1-16 with 4.9.2-1 or 20141017-1 made no difference.
It seems strange to me t
Package: gcc-4.9
Version: 4.9.1-16
There are a couple of Debian packages that failed to build on arm64
apparently because of problems with precompiled headers:
qtbase-opensource-src
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762702
aegisub
See http://bugs.debian.org/cgi-bin/bugreport.c
Package: gcc-4.9
Version: 4.9.0-11
When I try to build gnupg2 2.0.25-1 on arm64 using gcc-4.9 some of
the tests fail.
The object file involved is: agent/gpg_agent-gpg-agent.o
A particular test that fails is:
( cd tests/openpgp/ && make check TESTS=genkey1024.test )
Other, non-Debian, binaries
I tried this with gcc-2_95-branch and gcc-3_0-branch from CVS today.
The latest gcc-2.95 has the same problem, but the latest gcc-3.0
doesn't.
I expect gcc-3.0 will be out well before woody, but I don't know
whether that means you might use gcc-3.0 for building woody ...
Edmund
10 matches
Mail list logo
