Hi,
On 03/21/2017 07:33 AM, Jerry James wrote:
On Tue, Feb 28, 2017 at 2:05 PM, Jerry James <loganje...@gmail.com> wrote:
I'm really not sure what to check next. If an aarch64 box for
packagers will be available in the not too distant future, I will try
to debug this. Thanks for the information, Kevin.
This issue is now blocking a large update of sagemath and many of its
dependencies. Sagemath invokes maxima during its build. That
currently fails because the maxima in both F26 and Rawhide was built
with the pre-mass-rebuild version of ecl. If this issue is not
resolved, we will ship a nonfunctional sagemath with F26.
I either need access to an aarch64 box so I can try to figure out the
problem, or I need somebody with access to the aarch64 koji builders
to figure it out. I would file a bug, except I don't know which
component to file it against. Probably rpm, but I don't know that for
sure.
I started a local build of this and it appears to be hanging like this:
make check-TESTS
make[2]: Entering directory '/root/maxima/maxima-5.39.0/tests'
make[3]: Entering directory '/root/maxima/maxima-5.39.0/tests'
sed <"test.sh.in" >"gcl-test.sh" \
-e 's#!LOCAL_MAXIMA!#/bin/sh ../maxima-local#' \
-e 's#!LISPNAME!#gcl#' \
-e 's#!OUTPUT_LOG!#../tests/gcl.log#'
chmod a+x "gcl-test.sh"
FAIL: gcl-test.sh
sed <"test.sh.in" >"ecl-test.sh" \
-e 's#!LOCAL_MAXIMA!#/bin/sh ../maxima-local#' \
-e 's#!LISPNAME!#ecl#' \
-e 's#!OUTPUT_LOG!#../tests/ecl.log#'
chmod a+x "ecl-test.sh"
Breaking into maxima it seems to be stuck in:
(gdb) bt
#0 0x0000aaaaccdf2b3c in LC37testsuite (narg=0) at binary-ecl/mload.c:2800
#1 0x0000aaaaccdf2d8c in LC38__g239 (narg=0) at binary-ecl/mload.c:2967
#2 0x0000ffffb30532fc in L1do_time () from /lib64/libecl.so.16.1
#3 0x0000aaaaccdf2060 in L39run_testsuite (narg=<optimized out>) at
binary-ecl/mload.c:2692
#4 0x0000ffffb3108f48 in cl_apply () from /lib64/libecl.so.16.1
#5 0x0000aaaaccdead24 in L44_run_testsuite (narg=<optimized out>) at
binary-ecl/mload.c:3269
#6 0x0000ffffb3108f48 in cl_apply () from /lib64/libecl.so.16.1
#7 0x0000aaaaccc5c42c in L13meval1 (v1form=<optimized out>) at
binary-ecl/mlisp.c:1146
#8 0x0000aaaaccc41b1c in L10meval (v1form=0xaaaaed4c6991) at
binary-ecl/mlisp.c:631
#9 0x0000aaaaccdfc7d4 in L1meval_ (v1expr=<optimized out>) at
binary-ecl/suprv1.c:30
#10 0x0000aaaaccde4ec8 in L7toplevel_macsyma_eval (v1x=<optimized out>)
at binary-ecl/macsys.c:179
#11 0x0000aaaaccde85d4 in L9continue (narg=<optimized out>) at
binary-ecl/macsys.c:369
#12 0x0000aaaaccde75b8 in L24macsyma_top_level (narg=<optimized out>) at
binary-ecl/macsys.c:1154
#13 0x0000aaaacd3044c4 in L39common_lisp_user__run () at
binary-ecl/init-cl.c:1355
#14 0x0000ffffb310b840 in ecl_interpret () from /lib64/libecl.so.16.1
#15 0x0000ffffb310f82c in eval_form () from /lib64/libecl.so.16.1
#16 0x0000ffffb310f8e0 in execute_each_form () from /lib64/libecl.so.16.1
#17 0x0000ffffb310ec04 in compile_form () from /lib64/libecl.so.16.1
#18 0x0000ffffb310f4f8 in compile_with_load_time_forms () from
/lib64/libecl.so.16.1
#19 0x0000ffffb310f7d8 in eval_form () from /lib64/libecl.so.16.1
#20 0x0000ffffb31130d0 in si_eval_with_env () from /lib64/libecl.so.16.1
#21 0x0000ffffb30f1120 in si_safe_eval () from /lib64/libecl.so.16.1
#22 0x0000aaaaccbb9130 in main (argc=<optimized out>, argv=<optimized
out>) at /tmp/eclinitVioCS0.c:1843
So, I'm not sure how helpful that is. I will spend a little more time
looking at it.
In the mean time, linaro has instances for loan (
https://www.linaro.org/leg/servercluster/ ) That said, an aarch64 target
in fedora/qemu on x86 isn't a great solution, but on a high end machine
is actually fairly reasonable when compared with some of the low end
SOCs (particularly with regard to IO). So its possible to install
fedora/aarch64 and do basic builds. I wouldn't try building kernels on a
regular basis but it is doable.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
