On Mon, 23 Nov 2020 at 17:08, Reuben Thomas wrote:
> Good question! Looks like the code is relying on the definitions matching.
> (I used one of the sample debugger stubs, which seems not to have been
> changed for many years; meanwhile, gdb seems to have introduced its own
> enumeration. I
On Mon, 23 Nov 2020 at 16:47, Eli Zaretskii wrote:
> > From: Reuben Thomas
> > Date: Mon, 23 Nov 2020 16:38:22 +
> > Cc: Bruno Haible , bug-gnulib
> >
> > Can you elaborate what are you using this module for in the MinGW
> > build? AFAIK, Posix signals can never work well enough on
> From: Reuben Thomas
> Date: Mon, 23 Nov 2020 16:38:22 +
> Cc: Bruno Haible , bug-gnulib
>
> Can you elaborate what are you using this module for in the MinGW
> build? AFAIK, Posix signals can never work well enough on Windows to
> care about them. Maybe I'm missing something.
>
>
On Mon, 23 Nov 2020 at 16:09, Eli Zaretskii wrote:
>
> Can you elaborate what are you using this module for in the MinGW
> build? AFAIK, Posix signals can never work well enough on Windows to
> care about them. Maybe I'm missing something.
>
Signal numbers for use in a GDB debugger stub:
> From: Reuben Thomas
> Date: Sun, 22 Nov 2020 23:46:37 +
> Cc: bug-gnulib
>
>- Is it useful to have these signal names defined at all? If they can never
> occur on native Windows, it does not necessarily make sense to define
> them.
>
> If I wanted native (non-POSIX)
On Sun, 22 Nov 2020 at 22:47, Bruno Haible wrote:
>
> Two questions to consider:
>
> - What other effects would it have to define '_POSIX' ? In which other
> places
> is this macro being referenced?
>
It is used to define modes for read/write in fcntl.h (O_RDONLY and
friends), getlogin
Hi Reuben,
> I find that it is necessary to #define _POSIX to get a full set of POSIX
> signal names defined in mingw's signal.h. I'm slightly surprised to find
> this is not implemented in gnulib: is there a reason?
>
> If not, it would be straightforward to add
>
> #ifdef __MINGW32__
>
