wrapper_*.pyx fail to build on Cygwin

[jpflori]

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

Apply attachment: trac_13339-headers.patch

CC: @dimpase

Component: porting: Cygwin

Author: Jean-Pierre Flori

Reviewer: Dmitrii Pasechnik

Merged: sage-5.3.rc0

Issue created by migration from https://trac.sagemath.org/ticket/13339

[dimpase]

comment:1

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).

[jpflori]

comment:2

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.

[dimpase]

comment:3

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).

[dimpase]

comment:4

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/

[jpflori]

comment:5

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.

[jpflori]

comment:6

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.

[jpflori]

Author: Jean-Pierre Flori

[jpflori]

comment:9

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.

[jpflori]

comment:10

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?

[dimpase]

comment:11

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.

[jpflori]

comment:12

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.

[dimpase]

comment:13

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!

[dimpase]

comment:14

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.

[jpflori]

comment:15

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.

[jpflori]

comment:16

Attachment: trac_13339-headers.patch.gz

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

[dimpase]

comment:18

looks and works good. Positive review.

[jdemeyer]

Reviewer: Dmitrii Pasechnik

[jdemeyer]

Merged: sage-5.3.rc0