Le forum de XCAS

Bonjour,
J'ai un probleme avec la version de giac compilee avec les librairies de sage comme par exemple pour le spkg:

http://people.math.jussieu.fr/~han/xcas/giac-0.9.8.spkg


si je fais
sage -sh

puis giac alors cette version me donne:


0>> solve(cos(x)>0)
[x<0,x>0]
// Time 0.01


alors que le binaire ou la version sous freeBSD marchent.

Est ce que vous arrivez a le reproduire ou est ce chez moi?

Quelle librairie me manque t'il pour que ca ait change d'algo?
ldd /usr/local/sage-5.0.1/local/bin/giac
linux-vdso.so.1 => (0x00007fff679ff000)
libgiac.so.0 => /usr/local/sage-5.0.1/local/lib/libgiac.so.0 (0x00007ffd20cb2000)
libreadline.so.6 => /usr/local/sage-5.0.1/local/lib/libreadline.so.6 (0x00007ffd20a6b000)
libgsl.so.0 => /usr/local/sage-5.0.1/local/lib/libgsl.so.0 (0x00007ffd20646000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffd20406000)
libcblas.so => /usr/local/sage-5.0.1/local/lib/libcblas.so (0x00007ffd201e7000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ffd1fee6000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffd1fcd0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffd1f913000)
libntl.so => /usr/local/sage-5.0.1/local/lib/libntl.so (0x00007ffd1f53e000)
libpari-gmp.so.3 => /usr/local/sage-5.0.1/local/lib/libpari-gmp.so.3 (0x00007ffd1eebc000)
libgslcblas.so.0 => /usr/local/sage-5.0.1/local/lib/libgslcblas.so.0 (0x00007ffd1ec82000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ffd1ea79000)
liblapack.so => /usr/local/sage-5.0.1/local/lib/liblapack.so (0x00007ffd1e1b5000)
libatlas.so => /usr/local/sage-5.0.1/local/lib/libatlas.so (0x00007ffd1dc24000)
libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007ffd1d90c000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffd1d708000)
libpng12.so.0 => /usr/local/sage-5.0.1/local/lib/libpng12.so.0 (0x00007ffd1d4d3000)
libmpfr.so.4 => /usr/local/sage-5.0.1/local/lib/libmpfr.so.4 (0x00007ffd1d27a000)
libgmp.so.7 => /usr/local/sage-5.0.1/local/lib/libgmp.so.7 (0x00007ffd1d00a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffd1cd10000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffd21ac7000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007ffd1cad9000)
libz.so.1 => /usr/local/sage-5.0.1/local/lib/libz.so.1 (0x00007ffd1c8c2000)

Fred

Ca ressemble fort à un problème que j'avais rencontré il y a quelques années de mauvais ordre de chargement des fichiers objets lors du chargement de la libgiac, qui fait que pi est évalué en 0.
Est-ce que pi s'évalue en pi?
Quelle configuration as-tu? Le flag de compilation important est GIAC_GENERIC_CONSTANTS (cf. usual.cc), essaie de le definir ou de le désactiver pour voir si ça change.

lors de la compilation je vois bien des -DGIAC_GENERIC_CONSTANTS
(en 64bits)
j'ai:
CPPFLAGS="-I$SAGE_LOCAL/include"; export CPPFLAGS
LDFLAGS="-L$SAGE_LOCAL/lib/"; export LDFLAGS

et
./configure --prefix="$SAGE_LOCAL" --disable-gui


eval(pi) donne pi

0>> solve(sin(x)>0)
donne bien
[((x>0) and (x<pi))]

1>> solve(cos(x)>1/2)
[((x>((-pi)/6)) and (x<(pi/6)))]

mais
solve(cos(x)>0) ne marche pas.

je ne vois pas. Il faudrait executer au debuggueur. Je suppose que quand tu as lance un calcul avec giac, il y a un executable qui tourne? Si oui, il faudrait lancer gdb et faire attach no_de_process, puis mettre un point d'arret par exemple dans in_solve de solve.cc pour voir ce qu'il fait.

C'est peut etre du cote d'acos:

le spkg me donne cela:

22>> acos(1)
0
// Time 0
23>> acos(0)
0
// Time 0
24>> acos(-1)
0

Fred

Que dit asin?
le code de acos est essentiellement de renvoyer pi/2-asin.
Si asin marche, ca doit etre la constante cst_pi_over_2 qui pose probleme (peut-etre parce que la constante pi n'est pas encore chargee lorsqu'il definit pi/2, il faudrait essayer si tu peux compiler sans GIAC_GENERIC_CONSTANTS, sinon controler l'ordre de chargement de identificateur.o et usual.o, par exemple en inversant l'ordre dans le Makefile.am), ou alors normal().

Ca y est,

J'ai fait cette permutation:

diff Makefile.am Makefile.am~
9c9
< pari.cc cocoa.cc unary.cc identificateur.cc usual.cc gen.cc tinymt32.cc first.cc \
---
> pari.cc cocoa.cc unary.cc usual.cc identificateur.cc gen.cc tinymt32.cc first.cc \

et cette fois cela marche

Fred

bon, mais le probleme c'est que je ne peux pas generaliser ca, car l'ordre de chargement en fonction de l'ordre du Makefile depend de l'OS (de ld je suppose)

J'ai fait un changement dans le chargement de pi, qui devrait le forcer a etre correct independamment de l'ordre de chargement des .o. Tu peux tester si ca marche?

Salut,

non ca ne marche pas.

D'un autre cote c'est peut etre plus simple de patcher le spkg vu que je dois deja le faire a cause de lapack?

Fred

Oui, c'est plus simple de patcher. Mais es-tu sur que le patch fonctionne sur différentes machines?

Salut,
en fait j'ai teste sur une autre machine et la effectivement le spkg n'avait pas de pb sans avoir a patcher.

Ca me semble donc plutot etre un probleme avec ma compil sous ubuntu. La c'est une 12.04.

a+
Fred

est ce que c'est un probleme similaire a celui ci:
http://sourceware.org/bugzilla/show_bug.cgi?id=13720

d'un cote j'ai ld version 2.20 et de l'autre 2.22

Fred