Folks,

Is Cygwin supported by Python? We met the following error when compiling Python 3.3.2 on Cygwin 1.7.17:

gcc -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes     -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Modules/main.o Modules/main.c
Modules/main.c:17:0: warning: "PATH_MAX" redefined
/usr/include/limits.h:336:0: note: this is the location of the previous definition
Modules/main.c: In function ‘Py_Main’:
Modules/main.c:561:5: warning: implicit declaration of function ‘_setmode’
gcc -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes     -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Modules/gcmodule.o Modules/gcmodule.c
gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes     -I. -IInclude -I./Include    -DPy_BUILD_CORE  -c ./Modules/_threadmodule.c -o Modules/_threadmodule.o
gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes     -I. -IInclude -I./Include    -DPy_BUILD_CORE  -c ./Modules/signalmodule.c -o Modules/signalmodule.o
./Modules/signalmodule.c: In function ‘fill_siginfo’:
./Modules/signalmodule.c:745:5: error: ‘siginfo_t’ has no member named ‘si_band’
Makefile:1501: recipe for target `Modules/signalmodule.o' failed
make: *** [Modules/signalmodule.o] Error 1

Any lights would be appreciated.

Thanks,

> ./Modules/signalmodule.c:745:5: error: ‘siginfo_t’ has no member named ‘si_band’

This code is conditional, it is surrounded by:

#if defined(HAVE_SIGWAITINFO) || defined(HAVE_SIGTIMEDWAIT)

Does Windows support sigwaitinfo() or sigtimedwait()? I would be surprised. You used configure? Check pyconfig.h for these two constants.

cygwin is not officially supported.  We do accept patches that improve cygwin support when they are narrowly targted and well motivated.

Victor,

I did do ./configure, without any parameters. Should I use it with "--without-signal-module" option? Will all signals be disabled if this option is specified?

From Python document, it mentions Windows support the following signals:
signal.SIGINT, signal.SIGTERM, signal.SIGABRT, signal.SIGFPE, signal.SIGILL, signal.SIGSEGV
 
The following are found in pyconfig.h.in

 804 /* Define to 1 if you have the `sigtimedwait' function. */
 805 #undef HAVE_SIGTIMEDWAIT
 810 /* Define to 1 if you have the `sigwaitinfo' function. */
 811 #undef HAVE_SIGWAITINFO


Br,
Li

dellair jie: would you like to work on a patch?

It's fine if not, but it may then be that there is no resolution to this issue for the coming months or years (unless somebody else volunteers to write a patch).

Running configure should have created pyconfig.h. Please report what this file has; pyconfig.h.in is not configured.

Yes, my pleasure. 

After configure on Cygwin, there is pyconfig.h generated, variables are as following:
/* #undef HAVE_SIGTIMEDWAIT */
/* #define HAVE_SIGWAITINFO 1 */

The error disappeared once changed HAVE_SIGWAITINFO to undef.
However, it encountered another issue mentioned here:
http://bugs.python.org/issue13756

The patches provided seem only for 3.2.2, not sure if it is ok to apply them directly on 3.3.2?

Applied the patch 0001-CYGWIN-issue13756-Python-make-fail-on-cygwin.patch in case: http://bugs.python.org/issue13756

The build failed with parser module:
building 'parser' extension
gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I./Include -I. -IInclude -I/cygdrive/c/temp/Python-3.3.2/Include -I/cygdrive/c/temp/Python-3.3.2 -c /cygdrive/c/temp/Python-3.Modules/parsermodule.c -o build/temp.cygwin-1.7.17-i686-3.3/cygdrive/c/temp/Python-3.Modules/parsermodule.o
gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.7.17-i686-3.3/cygdrive/c/temp/Python-3.Modules/parsermodule.o -L. -L/usr/local/lib -lpython3.3m -o build/lib.cygwin-1.7.17-i686-3.3/parser.dll
build/temp.cygwin-1.7.17-i686-3.3/cygdrive/c/temp/Python-3.Modules/parsermodule.o: In function `parser_sizeof':
/cygdrive/c/temp/Python-3.Modules/parsermodule.c:371: undefined reference to `__PyNode_SizeOf'
collect2: ld returned 1 exit status

Could anyone shed some lights please?

Br,
Li

dellair jie: please focus on one issue at a time. The issue you reported here is the compile error with si_band; I will not discuss any other problems you bring up in this issue.

Note that editing pyconfig.h is not a solution. It's a generated file, so it must not be edited.

To diagnose this further, add the -dD option to the preprocessor output of signalmodule.c, i.e. run

gcc -dD -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes     -I. -IInclude -I./Include    -DPy_BUILD_CORE  -E ./Modules/signalmodule.c 

and attach the resulting file (or else study the output yourself).

BTW, please also understand that Python 3.3 is no longer maintained; it would be good if you could run this porting project on Python 3.4 instead.

Martin,

Certainly running on 3.4 now.
The output of the command is attached.

Will try to look into it tomorrow if no immediate follow up post.

Br,
Li

I found this patch:
https://github.com/Alexpux/MSYS2-packages/blob/master/python3/3.3.2-cygwin-siginfo.patch

Can you try to comment si_band code in signalmodule.c, and then run test_signal to see if sigwaitinfo works on Windows? test_sigwaitinfo() uses signal.alarm(1): does it work on Windows (with Cygwin)? (sigwaitinfo doc says "Availability: Unix.")

dellair: According to the compiler output, ./pyconfig.h has

#define HAVE_SIGWAIT 1


#define HAVE_SIGWAITINFO 1

So why did you say (in msg215221) that the file had

/* #undef HAVE_SIGTIMEDWAIT */
/* #define HAVE_SIGWAITINFO 1 */

(i.e. where do the comment signs come from)

Martin,

Thanks for the analysis!

The following values came from Python 3.3.2, the #define HAVE_SIGWAITINFO 1 was without comment sign, I commented it out for the build to go through.
/* #undef HAVE_SIGTIMEDWAIT */
/* #define HAVE_SIGWAITINFO 1 */

The output was from 3.4, haven't checked the values yet, might be different. Will check it tomorrow.

Br,
Dellair

STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> I found this patch:
> https://github.com/Alexpux/MSYS2-packages/blob/master/python3/3.3.2-cygwin-siginfo.patch

Sure. It seems to me it is extracted from issue3871 .

dellair jie wrote:
>
> dellair jie added the comment:
>
> Applied the patch 0001-CYGWIN-issue13756-Python-make-fail-on-cygwin.patch in case: http://bugs.python.org/issue13756
>
> The build failed with parser module:
> building 'parser' extension
> gcc ......   .../parsermodule.o: In function `parser_sizeof':
> /cygdrive/c/temp/Python-3.Modules/parsermodule.c:371: undefined reference to `__PyNode_SizeOf'
> collect2: ld returned 1 exit status
>
> Could anyone shed some lights please?

See  issue18637

Martin,

Here is the values presented on Python 3.4.0, in fact they are the same as 3.3.2, please note the key difference.
/* #undef HAVE_SIGTIMEDWAIT */
#define HAVE_SIGWAIT 1
#define HAVE_SIGWAITINFO 1
The SIGTIMEDWAIT is undef while the SIGWAIT is defined.
The patch Victor found (https://github.com/Alexpux/MSYS2-packages/blob/master/python3/3.3.2-cygwin-siginfo.patch) to modify sigalmodule.c works on both 3.3.2 and 3.4 (at least the build went through the sign failure.) 
So shall we close this issue?

Petrov,
Thanks a loot!
The patch you offered about parser works with 3.3.2 and 3.4. 
There is further issues with the build on Cygwin and I will raise it in a separate issue.

Br,
Dellair

> So shall we close this issue?

Nope. Could you please try the test described in msg215249?

We might integrate https://github.com/Alexpux/MSYS2-packages/blob/master/python3/3.3.2-cygwin-siginfo.patch but it would be better to fix sigwaitinfo() if it works without si_band.

Victor,

Would you please be more specific on test_signal?

Br,
Dellair

> Would you please be more specific on test_signal?

Please try to compile Python 3.4 with the attached cygwin_si_band.patch applied, and then run test_signal. I would like to know if all tests pass, and if not, which tests are failing. I also would like to know if test_sigwaitinfo() runs on Cygwin. I'm not sure that signal.alarm(1) is available on Windows, whereas test_sigwaitinfo() uses this function.

Or you can test manually sigwaitinfo(). Example on Windows using SIGINT and CTRL+c to send a signal:

>>> import signal
>>> info = signal.sigwaitinfo({signal.SIGINT})
^C
>>> info
signal.struct_siginfo(si_signo=2, si_code=128, si_errno=0, si_pid=0, si_uid=0, si_status=3, si_band=0)

I don't know how to test sigwaitinfo() on Windows.

Victor,

I suppose that Python needs to be built successfully before running test_signal.
Three patches were applied in Python 3.4.0. However, the build failed to build _struct module.

Should I open another Issue to track it?

As long as the build goes through completely on Cygwin, I will go back and do the signal test.

Br,
Dellair

Finally got it compiled on Cygwin! :)

Victor,

I am still having issue with the "make test" on Cygwin, hence can only do some manual testing:

Output:
>>> info = signal.sigwaitinfo({signal.SIGINT})
^C
>>>
>>> info = signal.struct_siginfo((2, 128, 0, 0, 0, 3))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: signal.struct_siginfo() takes an at least 7-sequence (6-sequence given)
>>> info = signal.struct_siginfo((2, 128, 0, 0, 0, 3, 0))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: signal.struct_siginfo() takes an at most 6-sequence (7-sequence given)
>>> help(signal.struct_siginfo)
 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |
 |  si_code
 |      signal code
 |
 |  si_errno
 |      errno associated with this signal
 |
 |  si_pid
 |      sending process ID
 |
 |  si_signo
 |      signal number
 |
 |  si_status
 |      exit value or signal
 |
 |  si_uid
 |      real user ID of sending process
 |
 |  ----------------------------------------------------------------------

Feel free to let me know if more testing is required.

Br,
Dellair

I wrote improved patch to remove the 'si_band'.  This patch modifies the 'n_in_sequence' to conform to the number of structure members.
And I tested manually for struct_siginfo.  struct_siginfo objects builds well.
That's all for now.

$ python3.4.exe
Python 3.4.3 (default, Mar  2 2015, 22:23:56)
[GCC 4.9.2] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> signal.struct_siginfo([1, 2, 3, 4, 5, 6])
signal.struct_siginfo(si_signo=1, si_code=2, si_errno=3, si_pid=4, si_uid=5, si_status=6)
>>> signal.sigwaitinfo({signal.SIGINT})
^C
signal.struct_siginfo(si_signo=2, si_code=6, si_errno=0, si_pid=3352, si_uid=1000, si_status=0)
>>> signal.alarm(1); signal.sigwaitinfo({signal.SIGALRM})
0
signal.struct_siginfo(si_signo=14, si_code=4, si_errno=0, si_pid=5816, si_uid=1000, si_status=1629189728)

Could you please use a define like SIGINFO_HAS_SI_BAND?

Something like:

#if defined(HAVE_SIGINFO) && !defined(__CYGWIN__)
   /* Issue #21085: In Cygwin, siginfo_t does not have si_band field. */
#  define SIGINFO_HAS_SI_BAND
#endif

And please generate patches not the git format. Otherwise, Rietveld is unable to generated the "review" link.

Victor,

In that case, May I edit configure script to generate the HAVE_* defines?
I'd like to add a statement to check the si_band to configure.ac.

> And please generate patches not the git format. Otherwise, Rietveld is unable to generated the "review" link.
I see.  I use the mercurial repository from next time.

> In that case, May I edit configure script to generate the HAVE_* defines?
> I'd like to add a statement to check the si_band to configure.ac.

Does Cygwin use configure? If yes, go for configure.

You can copy/paste my recent change for dirent.d_type field.

> I see.  I use the mercurial repository from next time.

Are you using git or hg? If you use hg, just change the config to not use
git format. If you use git, don't worry, I can review without the review
button.

New patch uses configure script to set the compile condition for struct_siginfo.si_band. 
The script was generated from configure.ac using autoreconf.

Could you make sure of having the si_band in another platform?

I've run into this recently.  Is there anything I can do to shepherd this issue toward a resolution status?

Review the patch, confirm that it works for you (please indicate what cygwin and OS version, etc you test on).  Also review this issue and make sure all open concerns have been addressed by the current patch.

Hello, I'm writer for past patch.
3.4-issue21085-struct_siginfo.patch removes si_band field from struct_siginfo if the C siginfo_t doesn't have si_band field.
This modification raises a incompatibility between platforms having struct_siginfo.
Now, I wrote another patch that doesn't change fields of struct_siginfo to avoid its incompatibility. 
And I built cpython 3.5.2+ on vista cygwin-x86 using this patch.
Murray, would you be able to tell me your idea?
Many thanks.

New patch changes:
If platform has the C siginfo_t structure, but it doesn't have si_band field, the struct_siginfo.si_band field is always assigned zero at function return value.

Oh, I made a mistake that is checking the si_band field without signal header.
Here is a modified patch adding signal header at checking the si_band field.
I passed tests compiling cpython 3.5.2+ on ubuntu 16.04.1 (x86) using this patch.

Thanks Masayuki for the updated patch.  I agree, the new approach looks better.  I will review the patch more carefully and test it soon.

I've reviewed masamoto's last patch 3.5-issue21085-struct_siginfo-2.patch

It applies cleanly and allows the signals module to compile on Cygwin64 2.5.1 / Windows 10.  I attached versions of the patch that apply cleanly to tip, 3.4, and 3.3 as well.

However, even with this issue resolved it can't be fully tested because there are other open issues preventing a successful build on Cygwin, including issue25658 and issue13756

Would it be ok to commit this even though it doesn't resolve all build issues?  Or should I try to cobble together a meta-issue of current known build issues and make sure they all have working patches first?

I think it would be reasonable to apply it, unless other devs object, given your confirmation that it solves this particular problem (and, looking at the code, it won't break anything...which the buildbots will confirm).

This will only be applied to 3.5 and 3.6, since this is not a security issue.  I've updated the versions accordingly.

New changeset 6874928eae4b by Zachary Ware in branch 'default':
Issue #21085: add configure check for siginfo_t.si_band
https://hg.python.org/cpython/rev/6874928eae4b

Thanks for the patch, masamoto, and thanks for the review and rebase, erik.bray!

I only applied this to 3.7.  It's much more open to experimentation currently, and we have a way to go before Python can even be built on Cygwin.  Once we reach a more stable point (say, the full test suite can be run, even if not everything passes), we can evaluate whether backporting all the changes it took to get there is worthwhile.

New changeset 5673cf852daa by Zachary Ware in branch 'default':
Issue #21085: Fix accidental leading +'s in configure.ac
https://hg.python.org/cpython/rev/5673cf852daa

Thanks for the merge--targeting 3.7 for now and thinking about backporting later sounds fine to me.

I'm also in the process of getting a Cygwin buildbot for Python up and running, but it's been slow going.  That said, having a Cygwin buildbot is also high priority for my own (non-Python-specific) work.  So once I have that up I will happily maintain a buildbot for Python on Cygwin.

When you're ready to get your bot set up, ping me and I'll get you set up on the master side.  Thanks!

In 3.6 and 3.7 The Same Error is back on line 960 with gcc 6.3.0 on cygwin64. This issue is not entirely fixed even with the absolute latest commits.

$ make
gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-pro
totypes    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missin
g-field-initializers   -I. -I./Include    -DPy_BUILD_CORE  -c ./Modules/signalmo
dule.c -o Modules/signalmodule.o
In file included from ./Include/Python.h:85:0,
                 from ./Modules/signalmodule.c:6:
./Modules/signalmodule.c: In function ‘fill_siginfo’:
./Modules/signalmodule.c:960:60: error: ‘siginfo_t {aka struct <anonymous>}’ has
 no member named ‘si_band’; did you mean ‘si_pid’?
     PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
                                                            ^
./Include/tupleobject.h:62:75: note: in definition of macro ‘PyTuple_SET_ITEM’
 #define PyTuple_SET_ITEM(op, i, v) (((PyTupleObject *)(op))->ob_item[i] = v)
                                                                           ^
./Modules/signalmodule.c:960:5: note: in expansion of macro ‘PyStructSequence_SE
T_ITEM’
     PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
     ^~~~~~~~~~~~~~~~~~~~~~~~~
make: *** [Makefile:1741: Modules/signalmodule.o] Error 1

Decorater, since this issue was already closed, could you open a new one?  And when you do, please add me to the nosy list.

I'm still planning to get a Cygwin built bot up for Python, I've just had other various priorities.