Le forum de XCAS

Here is the report in Debian: https://bugs.debian.org/cgi-bin/bugrepo ... bug=855078

I have added some debugging details on that report - it seems there is some inconsistency (on the same architecture) whether SMARTPTR64 is defined or not in that architecture.

You can see the exact build failure logs here: https://buildd.debian.org/status/package.php?p=giac

For example: https://buildd.debian.org/status/fetch. ... 8475&raw=0 or set raw=1 to download the plain text.

I understand that these are low-priority architectures, so there is no rush, take your time. In Debian we try to support quite a lot of architectures but we understand not all projects have the resources for this, and it is less important for end applications (that have fewer build-dependants).

I can not fix myself if I don't have access to one of these archs. src/first.h should indeed not undef SMARTPTR64, it should undef it for 32 bit archs, but I don't know how to check that properly.

Perhaps would work?

Unfortunately this does not work either, the segfault still occurs.

Is there a way to bypass SMARTPTR64 and just use normal pointers?

Also what is the purpose of this:

What happens if you define -DDOUBLEVAL (or in config.h)? This force representing double without truncation and therefore gen are using normal pointers.
If my recollection is correct, #undef _I386_ avoids using some i386 assembly code.

The geogebra team had the same problem with arm64, and we made some progresses thanks to arm64 emulation http://www.ecliptik.com/Emulating-ARM64-on-Linux/. It seems the segfault happens only if you link icas/xcas with the dynamic libgiac.so, in that case ./icas '2+2' segfaults. If you link statically with libgiac.a instead, then icas works, I already checked a few regression tests (it's sometimes very slow with arm64 emulation...).
This is perhaps related to the order ld is using to load object files, it's possible that some static initializations in some object files must be done after other initializations.

I confirm that I get a working icas with I guess it's possible to use this workaround to build giac debian packages on arm64 architectures.

Hi bernard,
there are also some debugging sessions in this sage ticket:
https://trac.sagemath.org/ticket/22280

on ppc64 in comment 25 compiled statically doesn't look better.

Like for arm64, I can't fix anything myself if I don't have access to a system like that, the stack trace is not really useful.
Fortunately, ppc64 is not as popular as arm64.

I have tried with qemu on a debian stable:
with giac source 1.2.3-31
(so I have only 1core and the thread value is 1) I have just built giac with libgmp-dev and libmpfr-dev.
with the default compiler (gcc-4.9) I was able to reproduce the problem (1+1 crashes and also: e) with a similar debug session as infinity0.

But I tried again with gcc-4.8 and now it works...

Some more info here: https://bugs.debian.org/cgi-bin/bugrepo ... =855078#19

There is apparently misuse of the __x86_64__ macro throughout the code.

Most portable is probably to check sizeof(void*) == 4 or 8 rather than the architecture specifically.

Ok, I will define SMARTPTR64 only if sizeof(void *)==8. I'm also modifying in gen.h with ~(uintptr_t)3 instead of 0xf...fffc. This will perhaps fix the dynamic arm64 binaries. I'll make a source distribution next week.

I have updated giac_stable to giac-1.2.3-47. The dynamic binary is (almost) working on my qemu arm64: by almost, I mean that some regression tests seems to run indefinitely, but a native run would perhaps finish.

Thanks, that seems to be fixed, all tests are passing for me on arm64 with 1.2.3-51.

However the Sage folks are reporting that it's necessary to give on ppc64. (I haven't yet tested this myself though.)