Source: lua-torch-torch7
Version: 0~20170720-gaed3171-2
User: debian-...@lists.debian.org
Usertags: arm64
This package may work on arm64 now that luajit is available on that
architecture.
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
This robopatch seems to fix the problem on arm64 with 48-bit addresses:
perl -i -pe 's/longlong/ulonglong/g if /\(\s*longlong.*(<<|>>)/ &&
!/gen\(longlong/;' src/*.cc
The idea is to change the type whenever there seems to be a cast
followed by a shift. The last condition is to avoid a couple of
So giac was supposed to be working now on arm64, but it failed on the buildd:
https://buildd.debian.org/status/package.php?p=giac=sid
Having recently seen something similar I think I can guess what's happening.
User virtual addresses on Linux arm64 may have 39, 42 or 48 bits,
depending on how
Trying this same short program with version 20061220+dfsg3-4.3 of
cernlib in a Stretch chroot on amd64:
$ gfortran hbktst.f -o hbktst `cernlib packlib`
$ ./hbktst
RZMAKE. Unit 1003 Initializing with LREC= 1024, OPT= X?C
LOCB/LOCF:
I was able to build giac 1.2.3.25+dfsg1-3 on arm64 with this "patch":
perl -i -pe 's/^#ifdef __x86_64__$/#if 1/;' src/gen.h
perl -i -pe 's/^#ifndef __x86_64__$/#if 0/;' src/first.h
Obviously that change would break it on 32-bit architectures. A proper
fix might be to use something like
On arm64, if you run under GDB and look at the address that faulted it's
clear that the address has been truncated to 32 bits. And there's some
obvious code in src/gen.h that looks as if it's truncating addresses
to 32 bits on any architecture that isn't x86_64. However, I don't
think gen.h is the
Source: sivp
Version: 0.5.3+svn287-2.1
I think this package can probably be built on arm64, now that scilab
is working (bug #791990). Should it be "Architecture: any"?
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
I see now that there's already a separate bug for this issue on arm64:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791990
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
There's the same problem on arm64:
$ /usr/bin/scilab
Could not find the Java configuration for the model . Please
contact us on http://bugzilla.scilab.org
/usr/bin/scilab-bin: error while loading shared libraries: libjava.so:
cannot open shared object file: No such file or directory
(However,
The upstream trunk has support for arm64 since 2015-07-13:
https://github.com/polyml/polyml/commit/9d84a491c4ec5fa95c085ddcc8f9cca84bbea870
It looks like a simple patch that might apply to the last released
version (still 5.5.2).
--
debian-science-maintainers mailing list
Source: ovito
Version: 2.3.3+dfsg1-1
Severity: wishlist
It is being built for a variety of architectures:
https://buildd.debian.org/status/package.php?p=ovito=sid
I didn't notice anything architecture-specific in the source code.
It seems to build on arm64.
Should arm64 be added to the
The same test failed on ppc64el:
https://buildd.debian.org/status/fetch.php?pkg=mclibs=ppc64el=20061220%2Bdfsg3-3=1438302711
Also on arm64, where the failure looks very like the mips64el failure
reported above:
Control: tag -1 patch
> Then those two changes can be turned into a patch that can be
> installed at debian/patches/140-arm64.dpatch
Perhaps they can, but I can't now see how to do it. I don't understand
the package's patch management system.
However, the changes described above belong quite
Gmsh fails to build on weak archs often. It is annoying to
request give-backs all the time or even remove accidental
builds on those platforms.
What do you mean by weak arch here? If you mean architectures with
unreliable or slow buildds then arm64 should be no weaker than armel
and armhf.
--
Firstly, I wasn't able, just now, to reproduce the build failure in
either jessie or unstable.
Secondly, I found a couple of old build logs from March. They were
done with sbuild on different but identical systems, and there is no
difference in the versions of the packages installed as reported
Source: freemat
Version: 4.0-5
Is there a good reason that this package Build-Depends on libffcall1-dev?
Note that the binary freemat package does not depend on libffcall1.
I built freemat on amd64 then rebuilt it after uninstalling libffcall1
and libffcall1-dev and found no significant
Source: 3depict
Version: 0.0.18-1
Tags: patch
I think you need to apply something like the attached patch. However,
you should probably read https://wiki.debian.org/Autoreconf yourself.
With the patch it built on arm64 for me. It wasn't in a fresh chroot,
but I've probably got the
Source: gmsh
Version: 2.8.5+dfsg-1.1
I was unable to build this from source on amd64. It went wrong near
the end:
make[1]: Leaving directory '/tmp/gmsh/gmsh-2.8.5+dfsg/debian/build'
dh_install -O--buildsystem=cmake
-O--builddirectory=/tmp/gmsh/gmsh-2.8.5\+dfsg/debian/build -O--parallel
Source: atlas
Version: 3.10.2-7
It failed to build on arm64 in Jessie. The error was:
make[3]: Entering directory '/«PKGBUILDDIR»/build/atlas-base/lib'
mkdir tmp
cd tmp \
ar x ../libatlas.a \
if test -f ../libptf77blas.a -a -f ../libptcblas.a; then \
ar x
The changes described above are now in the git repo:
http://github.com/b-k/apophenia
Do you want to add them as a patch to the Debian version?
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
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
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
By the way, it might be a good idea to remove the /dev/null 21
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 /dev/null 21
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.
--
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
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
By the way, it might be a good idea to remove the /dev/null 21
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.)
--
debian-science-maintainers mailing list
really_have_neon is probably inlined into fftwf_have_simd_neon, because
The assembler code you quoted looks like the translation of
X(have_simd_neon) with bl 0xa9f84 being the call to
really_have_neon().
--
debian-science-maintainers mailing list
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 {
/*
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 know arm
30 matches
Mail list logo
