It seems this can be fixed on arm64 by replacing "-1" with "2" in
these two lines in Kmeans/kmeans.pp:
($_tmp = $var_a($ibad, )) .= -1;
$var_a->inplace->setvaltobad(-1);
However, I don't know whether that's the right way to fix the problem
as I don't know how Perl's and PDL's type system
The patch "fftw3_3.3.3-7-arm64-neon-support-config.patch", posted to
this bug on 2014-01-09, is still basically good, I think, and there
seem to be no internal compiler errors any more.
A good set of changes against 3.3.4-2 is:
In configure.ac, do what the earlier patch says:
- if test "$h
Source: bup
Version: 0.25-1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=bup&suite=sid
The warnings and error were:
! t/test.sh save --strip-path (no match):
df: Warning: cannot read table of mounted file systems: No such file
or directory
df: Warning
Source: kmplayer
Version: 1:0.11.3d-2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=kmplayer&suite=sid
The error was:
/«PKGBUILDDIR»/src/moz-sdk/prcpucfg.h:764:2: error: #error "Unknown
CPU architecture"
#error "Unknown CPU architecture"
The values needed for arm6
Source: ruby-ferret
Version: 0.11.8.5-1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=ruby-ferret&suite=sid
The error was:
posh.h:516:4: error: #error POSH cannot determine target CPU
# error POSH cannot determine target CPU
It seems trivial to fix. You can just
Source: cigi-ccl
Version: 3.3.3a+svn818-7
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=cigi-ccl&suite=sid
The error was:
/usr/bin/c++ -DCIGI_LITTLE_ENDIAN -Dcigicl_shared_EXPORTS -g -O2
-fstack-protector-strong -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2
Source: ruby-inotify
Version: 0.0.2-7
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=ruby-inotify&suite=sid
The error was:
ext/inotify.c: In function 'inotify_init':
ext/inotify.c:20:18: error: '__NR_inotify_init' undeclared (first use
in this function)
return sysc
Source: libexplain
Version: 1.4.D001-2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=libexplain&suite=sid
The error was:
libexplain/buffer/enfile.c: In function 'get_maxfile':
libexplain/buffer/enfile.c:74:21: error: 'SYS__sysctl' undeclared
(first use in this funct
Source: lttngtop
Version: 0.2-2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=lttngtop&suite=sid
The error was:
iostreamtop.c: In function 'add_file':
iostreamtop.c:60:22: error: '__NR_open' undeclared (first use in this function)
tmp_file->flag = __NR_open;
Source: readahead-fedora
Version: 2:1.5.6-5.2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=readahead-fedora&suite=sid
The error was:
readahead-collector.c: In function 'parse_events':
readahead-collector.c:1081:21: error: '__NR_open' undeclared (first use in this
Source: openvdb
Version: 2.3.0-2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=openvdb&suite=sid
The error was:
dh_auto_test || true
make[2]: Entering directory '/«PKGBUILDDIR»'
Testing libopenvdb
export LD_LIBRARY_PATH=:/«PKGBUILDDIR»; ./vdb_test > /dev/null
E: Cau
Source: fribid
Version: 1.0.4-2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=fribid&suite=sid
The error was:
../npapi/prcpucfg.h:705:2: error: #error "Unknown CPU architecture"
#error "Unknown CPU architecture"
It seems easy to fix. You could replace
#elif defin
Source: libkqueue
Version: 2.0.3-1.1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=libkqueue&suite=sid
The error was:
src/linux/platform.c: In function 'linux_eventfd_init':
src/linux/../common/../linux/platform.h:29:31: error: 'SYS_eventfd' undeclared
(first use i
Source: librep
Version: 0.90.2-1.4
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=librep&suite=sid
The error was:
REPLISPDIR=../lisp REP_DL_LOAD_PATH=../src/.libexec REPDOCFILE=../doc-strings
../src/rep --batch -l rep.vm.compiler \
-f compile-batch rep-xgettext.jl
Source: trafficserver
Version: 5.1.1-1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=trafficserver&suite=sid
The error was:
Building LuaJIT 2.0.3
make -C src
make[5]: Entering directory '/«PKGBUILDDIR»/lib/luajit/src'
lj_arch.h:55:2: error: #error "No supp
Source: uid-wrapper
Version: 1.0.2-1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=uid-wrapper&suite=sid
The error was:
/«PKGBUILDDIR»/tests/testsuite.c: In function 'test_uwrap_syscall':
/«PKGBUILDDIR»/tests/testsuite.c:201:15: error: 'SYS_access'
undeclared (first
Here are my latest thoughts on what the run-time test for NEON should
probably look like.
Previous proposals used two static variables instead of just one, but
I think that would be less thread-safe.
The variable "cached" is used in only two places, so, provided the
access to it is atomic, the co
Kamal Mostafa :
> Edmund et al., I would appreciate your expertise here... Does it also appear
> to
> you that my minimodem (0.20-1) failure[0] could be caused by the fftw3 "NEON
> is
> perhaps broken" bug? Does it make sense that abel.d.o would be affected by
> it, but harris and asachi would
There is no need for the cast. Just use:
int c;
while (true)
{
c = gnulib::fgetc (fp);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Source: octave
Version: 3.8.2-3
On arm64 mkoctfile -M goes into an infinite loop:
echo > t.c
mkoctfile -M t.c
# it runs for ever
This may be because of this code in src/mkoctfile.in.cc:
get_line (FILE *fp)
{
static std::vector buf (100);
unsigned int idx = 0;
char c;
while (true)
{
Source: uhub
Version: 0.4.1-3
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=uhub&suite=sid
The error was:
/«PKGBUILDDIR»/src/core/hub.c: In function 'hub_set_variables':
/«PKGBUILDDIR»/src/core/hub.c:929:71: error: expected ')' before 'CPUINFO'
tmp = adc_msg_esc
This can be fixed on arm64 at least by fixed this bug in htslib:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770162
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Source: htslib
Version: 1.1-1
The code looks like this:
faidx_t *fai_build_core(BGZF *bgzf)
{
char c, *name;
...
while ( (c=bgzf_getc(bgzf))>=0 ) {
Clearly on architectures where plain char is unsigned (arm64, armhf,
...) this won't work (infinite loop).
I'd suggest changing the type of
Source: ltrsift
Version: 1.0.2-1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=ltrsift&suite=sid
The error was:
[compile obj/src/preprocess_visitor.o]
cc: error: unrecognized command line option '-m64'
cc: error: unrecognized command line option '-m64'
make[2]: ***
Source: uc-echo
Version: 1.12-7
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=uc-echo&suite=sid
The error was:
g++ -c -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -m64 -Wall -O3 -D_FORTIFY_SOURCE=2 DNASeq.cpp
-o DNASeq.o
g++: error: unrecognized
While you're at it, could you add "defined(__aarch64__)" to that test
so that it will build on arm64?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Source: fhist
Version: 1.18-1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=fhist&suite=sid
The error was:
/bin/sh test/00/t0001a.sh
Segmentation fault
FAILED test of basic fcomp functionality
This seems to be an example of a kind of bug that has become quite
fashi
Source: inotail
Version: 0.5-2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=inotail&suite=sid
The error was:
In file included from inotail.c:37:0:
inotify-syscalls.h:83:3: error: #error "inotify not supported on this
architecture!"
# error "inotify not supported o
Source: doomsday
Version: 1.10.4-2
It failed to build on several ARM architectures:
http://buildd.debian.org/status/package.php?p=doomsday&suite=sid
In each case the error was:
src/con_main.cpp: In function 'void conPrintf(int, const char*, va_list)':
src/con_main.cpp:1842:31: error: invalid op
And to make it work on arm64 too, please make it:
#if defined(__x86_64) || defined(__PPC64__) || defined(__aarch64__)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Source: gcc-h8300-hms
Version: 1:3.4.6+dfsg2-2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=gcc-h8300-hms&suite=sid
The error was:
/«BUILDDIR»/gcc-h8300-hms-3.4.6+dfsg2/builddir-h8300-hitachi-coff/gcc/../../gcc/emit-rtl.c:571:(.text+0xfd4):
relocation truncated to
That patch, flexpart_mcmodel.patch, would fix the FTBFS on arm64, too.
(So, if you're thinking of making it conditional on the architecture
in some way, test for "arm64" as well as "ppc64el".)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe".
Source: nwchem
Version: 6.5+r26243-3
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=nwchem&suite=sid
The error was:
gfortran -c -m64 -ffast-math -Warray-bounds -fdefault-integer-8 -O2
-g -fno-aggressive-loop-optimizations -I.
-I/«BUILDDIR»/nwchem-6.5+r26243/src/inc
Some good news: the code doesn't seem to need a lot of changes to make
it work on arm64. I did this:
* Changed the type of the local variables to which the value returned
from fgetc, getopt or get_next is assigned from char to int.
* Made get_next return int instead of char, and, to make it ret
There are also several places where the value returned from getopt is
assigned to a variable of type char before being compared with -1. I
would guess that the programs are going into an infinite loop while
trying to parse their command-line arguments when char is unsigned.
--
To UNSUBSCRIBE, em
>> By the way, it might be a good idea to remove the ">/dev/null 2>&1"
>> from the command lines in case the compiler wants to warn you about
>> this sort of thing. (I don't know whether GCC does in this particular
>> case.)
>>
>
> Please could you specify the place of this code.
I was wrong. The
By the way, it might be a good idea to remove the ">/dev/null 2>&1"
from the command lines in case the compiler wants to warn you about
this sort of thing. (I don't know whether GCC does in this particular
case.)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subjec
>From the buildd logs it appears that the tests are timing out.
A quick look at apop_conversions.c suggests a plausible explanation.
In that file there is code like this:
char c = fgetc(infile);
...
while(c!='\n' && c !=EOF){
EOF is negative, and plain char is unsigned on ARM architectu
> 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
The build failure on the buildds may be caused by this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767138
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> > Is this signal-handling approach the best way of detecting NEON? The
> > following blog suggests using HWCAP, but I don't know if that would
> > work with the freebsd kernels:
>
> looks like a better way to do it, freebsd doesn't matter for us as we
> don't have a arm port of that.
> I don't k
Source: fftw3
Version: 3.3.4-1.1
In simd-support/neon.c I found:
static int really_have_neon(void)
{
void (*oldsig)(int);
oldsig = signal(SIGILL, sighandler);
if (setjmp(jb)) {
signal(SIGILL, oldsig);
return 0;
} else {
/* parano
Source: cernlib
Version: 20061220+dfsg3-4.1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=cernlib&suite=sid
The error was:
gcc -g OptimizationLevel -D_FORTIFY_SOURCE=2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -
Did you accidentally upload this without the change in debian/rules?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Source: scalapack
Version: 1.8.0-10
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=scalapack&suite=sid
The error was:
# The shared library is installed via debian/*.install, to avoid
# creating an empty package if default MPI implementation changes on
# the arch
dh_i
Source: libtrio
Version: 1.16+dfsg1-2
It failed to build on arm64:
https://buildd.debian.org/status/package.php?p=libtrio&suite=sid
The error was:
Verification failed in regression.c:620.
Expected "03.142e+03"
Got "03.141e+03"
The test is expecting 3141.5 to be rounded up to 3142 rath
Source: ogre-1.8
Version: 1.8.0+dfsg1-7
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=ogre-1.8&suite=sid
The error was:
/«BUILDDIR»/ogre-1.8-1.8.0+dfsg1/OgreMain/include/OgreStringConverter.h:
At global scope:
/«BUILDDIR»/ogre-1.8-1.8.0+dfsg1/OgreMain/include/OgreSt
This looks just like bug #745969, where a fix is described:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745969
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Source: blacs-mpi
Version: 1.1-32
It's not building on arm64:
http://buildd.debian.org/status/package.php?p=blacs-mpi&suite=sid
The error is:
dh_install: libblacs-mpich1 missing files (libblacs-mpich.so.*), aborting
Seeing the recent changelog and bug #761946, and the dependencies of
mpi-defau
Source: pyzmq
Version: 14.3.1-1
It's not building on arm64:
http://buildd.debian.org/status/fetch.php?pkg=pyzmq&arch=arm64&ver=14.3.1-1&stamp=1412167624
The error is:
Assertion failed: pfd.revents & POLLIN (signaler.cpp:193)
This is exactly what used to happen on mips:
http://buildd.debian.or
In case anyone still wants to build guile-1.8, a fix (remove
declarations of 'yy*' functions in c-tokenize.lex) is described here:
http://lists.gnu.org/archive/html/guile-devel/2010-03/msg00081.html
It seems to work on arm64.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.or
Source: erlang-jiffy
Version: 0.8.5+dfsg-1
It didn't build on arm64:
https://buildd.debian.org/status/package.php?p=erlang-jiffy&suite=sid
The error was:
c_src/double-conversion/utils.h:71:2: error: #error Target
architecture was not detected as supported by Double-Conversion.
#error Target ar
Source: sope
Version: 2.2.9-1
Thanks for trying to patch for arm64 in 2.2.9-1. Unfortunately it
still failed to build:
https://buildd.debian.org/status/package.php?p=sope&suite=sid
EOSQLQualifier.m: In function '-[EOSQLQualifier
initWithEntity:qualifierFormat:argumentsArray:]':
EOSQLQualifier.m:
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
Source: aegisub
Version: 3.1.2-1
See http://buildd.debian.org/status/package.php?p=aegisub&suite=sid
The error is: internal compiler error: Segmentation fault
It looks like a problem with precompiled headers, quite possibly the
same bug (762702) that prevented qtbase-opensource-src from building
Package: qtbase-opensource-src
Version: 5.3.2+dfsg-2
See:
https://buildd.debian.org/status/package.php?p=qtbase-opensource-src&suite=sid
The error is this:
.obj/qcryptographichash.o: In function `__bswap_32':
/usr/include/aarch64-linux-gnu/bits/byteswap.h:46: undefined reference
to `MD5Context:
Hi,
Have you looked into this idzebra bug at all?
Sorry that I can't easily contribute to bugs.debian.org.
Some observations for you:
1. There are three places in the source code where a char is passed to
isalpha or isspace. You should cast to unsigned char here, I think, to
avoid getting diffe
Package: zlibc
Version: 0.9k-4.1
Currently it fails to build thus:
filetype.c: In function 'zlib_initialise':
filetype.c:167:16: error: 'SYS_open' undeclared (first use in this function)
fd=syscall(SYS_open,"/proc/self/cmdline", O_RDONLY);
^
filetype.c:167:16: note: each unde
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
"Martin v. Löwis" <[EMAIL PROTECTED]>:
> #include
> #include
>
> int main()
> {
> WINDOW *win = initscr();
> waddstr(win, "\303\244\n");
> waddstr(win, "\342\200\242\n");
> waddstr(win, "\344\272\272\n");
> refresh();
> sleep(3);
> endwin(
00 +0100
@@ -0,0 +1,119 @@
+/*
+ * This is an implementation of wcwidth() and wcswidth() as defined in
+ * "The Single UNIX Specification, Version 2, The Open Group, 1997"
+ * <http://www.UNIX-systems.org/online.html>
+ *
+ * Markus Kuhn -- 2000-02-08 -- public domain
+ */
+
+/
301 - 361 of 361 matches
Mail list logo
