Re: Problems building farey_symbol.pyx on Cygwin

[Jean-Pierre Flori]

I'll do when I'm finished, for the moment, I'll just keep track of the progress on the wiki page.
Hopefully there is only one problematic file left: expression.pyx.
I've looked into this all night long but failed to solve the problem.

g++ complains about a template instantiation (parse error, blah, cannot find function, blah) using the infinity class (from pynac).
More precisely functions like "bool is_a<infinity>(const &ex)", "ex_to<infinity>" and similar ones.
The link I posted on the wiki page does not seem useful after all, although the problem shall dwell in this part of the code.
What's strange is that the same functions are used with different classes, even earlier in expression.cpp and are not problematic.
Looking at infinity.c/h and e.g. relational.h/c, and what's about them in basic.h/c and ex.h/c I can not spot an obvious difference.
As I'm not really an expert of templates I hope I have missed something obvious.

I'll try to cc Burcin about that, as he's surely the more acquainted with pynac source code and organization.

Best,
JP

[Burcin Erocal]

Hi Jean-Pierre,

The infinity class is a recent addition to pynac by Volker. It is
possible that we missed something there, but I cannot spot any obvious
problems just by looking at the (pynac) code. Can you post the error
messages?


Cheers,
Burcin

[Jean-Pierre Flori]

Here it is:

Executing 9 commands (using 1 thread)
gcc -fno-strict-aliasing -fwrapv -I/usr/include/ncurses -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/home/jp/sage-5.1.rc1/local/include -I/home/jp/sage-5.1.rc1/local/include/csage -I/home/jp/sage-5.1.rc1/devel/sage/sage/ext -I/home/jp/sage-5.1.rc1/local/include/python2.7 -c sage/symbolic/expression.cpp -o build/temp.cygwin-1.7.16-i686-2.7/sage/symbolic/expression.o -Wl,--enable-auto-import -w
cc1plus: attention : l'option de la ligne de commande "-Wstrict-prototypes" est valide pour Ada/C/ObjC mais pas pour C++
sage/symbolic/expression.cpp: In function ‘PyObject* __pyx_f_4sage_8symbolic_10expression_10Expression_pyobject(__pyx_obj_4sage_8symbolic_10expression_Expression*, int)’:
sage/symbolic/expression.cpp:3047:15: erreur: parse error in template argument list
sage/symbolic/expression.cpp:3047:49: erreur: no matching function for call to ‘is_a(GiNaC::ex&)’
sage/symbolic/expression.cpp:3057:17: erreur: parse error in template argument list
sage/symbolic/expression.cpp:3057:52: erreur: no matching function for call to ‘ex_to(GiNaC::ex&)’
sage/symbolic/expression.cpp:3076:17: erreur: parse error in template argument list
sage/symbolic/expression.cpp:3076:52: erreur: no matching function for call to ‘ex_to(GiNaC::ex&)’
sage/symbolic/expression.cpp:3095:17: erreur: parse error in template argument list
sage/symbolic/expression.cpp:3095:52: erreur: no matching function for call to ‘ex_to(GiNaC::ex&)’
sage/symbolic/expression.cpp: In function ‘int __pyx_f_4sage_8symbolic_10expression_10Expression_is_infinity(__pyx_obj_4sage_8symbolic_10expression_Expression*, int)’:
sage/symbolic/expression.cpp:9117:13: erreur: parse error in template argument list
sage/symbolic/expression.cpp:9117:47: erreur: no matching function for call to ‘is_a(GiNaC::ex&)’
sage/symbolic/expression.cpp: In function ‘int __pyx_pf_4sage_8symbolic_10expression_10Expression_52__nonzero__(PyObject*)’:
sage/symbolic/expression.cpp:9514:17: erreur: parse error in template argument list
sage/symbolic/expression.cpp:9514:41: erreur: no matching function for call to ‘is_a(GiNaC::ex&)’
sage/symbolic/expression.cpp:9517:19: erreur: parse error in template argument list
sage/symbolic/expression.cpp:9517:43: erreur: no matching function for call to ‘is_a(GiNaC::ex&)’
error: command 'gcc' failed with exit status 1

Best,
JP

[Jean-Pierre Flori]

FYI, it seems that somehow the infinity class is not bound to GiNaC::infinity on the contrary to what happens to all the other pynac classes.
Not sure why, but maybe there is a name clash with sage.rings.infinity or the infinity variable declared therein.
At least, changing the <infinity> to <GiNaC::infinity> in the cpp file produced by Cython (that's bad, but the quickest way to go on compiling Sage) solved the problem.

After that, I got:
 * undefined references in stl_vectors solved by adding the correct library dependencies in modules_list
 * undefined references in wrapper_rdf because of a functions defined in interp_rdf and seemingly correctly shown by nm in both files. Changing the order of the files in the linking command, and adding -no-undefined flag, did not solve the problem yet.