Opened 7 years ago

Closed 7 years ago

#13339 closed defect (fixed)

wrapper_*.pyx fail to build on Cygwin

Reported by: jpflori Owned by: tbd
Priority: major Milestone: sage-5.3
Component: porting: Cygwin Keywords: cygwin
Cc: dimpase Merged in: sage-5.3.rc0
Authors: Jean-Pierre Flori Reviewers: Dmitrii Pasechnik
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by jpflori)

Same problem as in #13336 with _ _ imp _ _ problems. As a fix, gen_interpreter.py now produces header files for the C interpreters.

Apply trac_13339-headers.patch

Attachments (1)

trac_13339-headers.patch (51.5 KB) - added by jpflori 7 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 7 years ago by dimpase

here a fix will be a bit more involved. What happens is that ext/interpreters/wrapper/wrapper_rdf.c, which is Cython-autogenerated from the .pyx file, which in turn is generated by ext/gen_interpreters.py, has the line

 __PYX_EXTERN_C DL_IMPORT(double) interp_rdf(double *, double *, PyObject **, double *, int *);

which should be

 __PYX_EXTERN_C double interp_rdf(double *, double *, PyObject **, double *, int *);

And the same holds for ext/interpreters/wrapper/wrapper_cdf.c (and ext/interpreters/wrapper/wrapper_rr.c, ..._py.c, ..._el.c), just replace rdf (resp. rr, etc.) by cdf in every place above.

After I do the corresponding changes in these C files, ./sage -b completes.


Now the attempt to start Sage ends with

Traceback (most recent call last):
  File "/home/Dima/sage-5.2.rc1/local/bin/sage-ipython", line 18, in <module>
    import IPython
ImportError: No module named IPython

(which is OK, I just have to run make build).

Last edited 7 years ago by dimpase (previous) (diff)

comment:2 follow-up: Changed 7 years ago by jpflori

I've already a fix which consists in generating h files for the interp_*.c files which get included in wrapper_*.c files and avoid the Cython/import/_ _ imp _ _ stuff as desrcibed in the CygwinPort page, I'll post it a little later.

The IPython stuff was expected IIRC. I'll confirm that later as well, but were closing to finishing the build and starting Sage.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 7 years ago by dimpase

Replying to jpflori:

The IPython stuff was expected IIRC.

Sure. By the way, I just encountered a GAP-specific problem (some ln hack, no longer needed, fails), which is easy to fix, but needs a new spkg. Have you dealt with this too? Or it worked for you without a problem? (In case, I can open a ticket for this and post a new spkg, just let me know).

comment:4 follow-up: Changed 7 years ago by dimpase

and one more trivial stop: I got SAGELOCAL/lib/crypto.lib file, from PARI or Singular, or at least it an ASCII file with crypto-related code written in one of these languages, and it stopped PyOpen?-ssl thing to install properly. Removing the file fixed the problem.

Probably there is a CYGWIN-only script somewhere that copies *.lib files to SAGELOCAL/lib/

comment:5 in reply to: ↑ 3 Changed 7 years ago by jpflori

Replying to dimpase:

Replying to jpflori:

The IPython stuff was expected IIRC.

Sure. By the way, I just encountered a GAP-specific problem (some ln hack, no longer needed, fails), which is easy to fix, but needs a new spkg. Have you dealt with this too? Or it worked for you without a problem? (In case, I can open a ticket for this and post a new spkg, just let me know).

Oh yeah I now remember about that problem. We used to create a symlink from gap to gap.exe (or conversely) but my Cygwin was making the name conversion automatically and the symlink creation failed.

Anyway, let's create another ticket for that. Not sure if the trick must be completely discrded or tthe error ignored if it fails.

This is now #13341.

Last edited 7 years ago by jpflori (previous) (diff)

comment:6 in reply to: ↑ 4 ; follow-up: Changed 7 years ago by jpflori

Replying to dimpase:

and one more trivial stop: I got SAGELOCAL/lib/crypto.lib file, from PARI or Singular, or at least it an ASCII file with crypto-related code written in one of these languages, and it stopped PyOpen?-ssl thing to install properly. Removing the file fixed the problem.

Probably there is a CYGWIN-only script somewhere that copies *.lib files to SAGELOCAL/lib/

I don't think I got that one with 5.1.rc1. So either its a new problem, or I somehow got through it. I'll confirm when I'm getting there.

Last edited 7 years ago by jpflori (previous) (diff)

comment:7 Changed 7 years ago by jpflori

  • Authors set to Jean-Pierre Flori
  • Description modified (diff)
  • Status changed from new to needs_review

comment:8 Changed 7 years ago by jpflori

  • Description modified (diff)

comment:9 Changed 7 years ago by jpflori

Please be aware that I also fixed all the EXAMPLES block with this patch.

And I did not have the chance to test the doctests yet.

comment:10 in reply to: ↑ 6 ; follow-up: Changed 7 years ago by jpflori

Replying to jpflori:

Replying to dimpase:

and one more trivial stop: I got SAGELOCAL/lib/crypto.lib file, from PARI or Singular, or at least it an ASCII file with crypto-related code written in one of these languages, and it stopped PyOpen?-ssl thing to install properly. Removing the file fixed the problem.

Probably there is a CYGWIN-only script somewhere that copies *.lib files to SAGELOCAL/lib/

I don't think I got that one with 5.1.rc1. So either its a new problem, or I somehow got through it. I'll confirm when I'm getting there.

This is indeed an issue with the new sage notebook. Wouldn't you mind opening a ticket and posting an update spkg?

comment:11 in reply to: ↑ 10 ; follow-up: Changed 7 years ago by dimpase

Replying to jpflori:

This is indeed an issue with the new sage notebook. Wouldn't you mind opening a ticket and posting an update spkg?

I got stuck with #13343 (something I knew about, but forgot). So I'll have to rebuild Sage from scratch, as moving the half-built tree to another directory doesn't seem to work well.

comment:12 in reply to: ↑ 11 ; follow-up: Changed 7 years ago by jpflori

Replying to dimpase:

Replying to jpflori:

This is indeed an issue with the new sage notebook. Wouldn't you mind opening a ticket and posting an update spkg?

I got stuck with #13343 (something I knew about, but forgot). So I'll have to rebuild Sage from scratch, as moving the half-built tree to another directory doesn't seem to work well.

I've crafted a new spkg for the crypto.lib problem, just moving it to crypto.xxx before installing pyOpenSSL and movind it back afterward.

You can test it at http://perso.telecom-paristech.fr/~flori/sage/sagenb-0.9.1.p0.spkg As I'm not sure whether there's a special procedure for updating the sagenb spkg, nothing is committed yet and no ticket created.

comment:13 in reply to: ↑ 12 Changed 7 years ago by dimpase

Replying to jpflori:

Replying to dimpase:

Replying to jpflori:

This is indeed an issue with the new sage notebook. Wouldn't you mind opening a ticket and posting an update spkg?

I got stuck with #13343 (something I knew about, but forgot). So I'll have to rebuild Sage from scratch, as moving the half-built tree to another directory doesn't seem to work well.

I've crafted a new spkg for the crypto.lib problem, just moving it to crypto.xxx before installing pyOpenSSL and movind it back afterward.

That's a fix, but not a proper cure to the problem. See #13344. It's a bug somewhere else. That crypto.lib does not belong there at all!

comment:14 Changed 7 years ago by dimpase

  • Status changed from needs_review to needs_work

I tried this on (upgraded from Sage 5.2) Sage 5.3.rc0 (on x86_64 Ubuntu 12.04), and got

sage -t  --long -force_lib devel/sage/sage/ext/gen_interpreters.py
**********************************************************************
File "/tmp/sage-5.2/devel/sage-main/sage/ext/gen_interpreters.py", line 2530:
    sage: print interp.h_header
Expected:
    #include <mpfr.h>
Got:
    <BLANKLINE>
    #include <mpfr.h>
    <BLANKLINE>
    extern int rr_py_call_helper(PyObject*, PyObject*, int, mpfr_t*, mpfr_t*);
    <BLANKLINE>
**********************************************************************
File "/tmp/sage-5.2/devel/sage-main/sage/ext/gen_interpreters.py", line 3353:
    sage: print rdf_interp_h
Expected:
    /* Automatically generated by ext/gen_interpreters.py.  Do not edit! */
    #include <Python.h>
Got:
    /* Automatically generated by ext/gen_interpreters.py.  Do not edit! */
    #include <Python.h>
    <BLANKLINE>
    #include <gsl/gsl_math.h>
    <BLANKLINE>
    double interp_rdf(double* args,
            double* constants,
            PyObject** py_constants,
            double* stack,
            int* code);
    <BLANKLINE>
... and more similar failures in this file, 5 in total...

Please have a look.

Last edited 7 years ago by dimpase (previous) (diff)

comment:15 Changed 7 years ago by jpflori

My bad, I rewrote the doctests by hand and did not actually test them... The fixes should be trivial, I'll have a look next week.

Changed 7 years ago by jpflori

comment:16 Changed 7 years ago by jpflori

The new patch has correct BLANKLINE tags in the doctests and passes them on Linux with Sage-5.3.beta2.

comment:17 Changed 7 years ago by jpflori

  • Cc dimpase added
  • Keywords cygwin added
  • Status changed from needs_work to needs_review

comment:18 Changed 7 years ago by dimpase

  • Status changed from needs_review to positive_review

looks and works good. Positive review.

comment:19 Changed 7 years ago by jdemeyer

  • Merged in set to sage-5.3.rc0
  • Resolution set to fixed
  • Reviewers set to Dmitrii Pasechnik
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.