Changes between Version 153 and Version 154 of CygwinPort


Ignore:
Timestamp:
07/25/12 17:46:17 (10 years ago)
Author:
jpflori
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • CygwinPort

    v153 v154  
    168168 * in modules_list.pyx, farey_symbol.pyx should include gmpxx AND gmp; but that's not enough yet: undefined reference to convert_to_long and things defined in farey_symbol.pyx, to solve this second problem, one can add a extra_compiler_flags="-Wl,--enable-auto-import" to the farey stuff in module_list. A better way could be to let Cytohn add _declspec(dll[im|exp]port) things in farey_symbol.h
    169169 * complex_double linking fails because of -lmc not found -> indeed, this was not built (don't know what it should be), solution: remove it from module_list
    170  * expression.pyx fails, seems related to http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg163112.html. Somehow g++ does not realize that the infinity class used in the templates is the one from pynac. Maybe some name clash with Python/Cython/Sage things in sage.rings.infinity[.infinity]. So letting g++ know that infinity is GiNaC::infinity should do the trick (I did that by modifying the cpp file produced by Cython which was hackish but quick)
     170 * expression.pyx fails, seems related to http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg163112.html. Somehow g++ does not realize that the infinity class used in the templates is the one from pynac. Maybe some name clash with Python/Cython/Sage things in sage.rings.infinity[.infinity]. So letting g++ know that infinity is GiNaC::infinity should do the trick (I did that by modifying the cpp file produced by Cython which was hackish but quick), explicitly writing GiNaC::infinity in ginac.h in sage.libs solves the problem
    171171 * undefined references in stl_vectors solved by adding the correct library dependencies in modules_list
    172  * 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.
     172 * 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. It seems that there are incorrect __imp_ prefix added to the symbols of the interp_* functions when wrapper_*.o is built. Because of that, the functions are looked to be imported from some .dll rather .o file.
     173Indeed, building an independent .dll for interp_* and then linking wrapper_* to it to produce wrapper_*.dll works. To only have one wrapper_*.dll I've added an header file for interp_*.c and included it as cdef extern from "interp_*.h" in wrapper_*.pyx rather than without the from part as before. This seems functional, but needs non-trivial modifications to gen_interpreter.py.
     174* Apart from that, one of the modules built by gen_interpreter.py linked to the mc library which is not available on my system (also had that problem for some module build in module_list.py).