Re: 000217: status of DJGPP support

[Daniel Berlin <dan at cgsoftware dot com>]

> 
>   - Does any other configuration use `select' rather than `poll'?  It
>     seems to me that the branch with `select' is broken; for starters,
>     fd_mask is not defined anywhere (GCC bails out with parse error
>     while compiling event-loop.c).  Does the distribution assume that
>     fd_mask is defined on some system header?  If so, I think it
>     should test for it, because I don't think it is a standard
>     definition.
> 

I have this problem on BeOS.
I can give you an fd_mask that will work.
Unfortunately, i had to disable the event loop based interface because
our select isn't good enough yet.

We don't have poll, neither.

> Alternatively, I could supply a
definition on xm-go32.h, for >     example.
> 
>     Btw, why doesn't the `select' branch use the standard fd_set type
>     and the FD_* macros instead of memset and memcpy?  Use of fd_set
>     and FD_* would remove the need in all that juggling with
>     bits-per-byte, MASK_SIZE, etc.  Is there any reason not to use
>     those?
> 
>   - The configure scripts cannot be run without some tricks, like
>     setting a few variables in the environment.  So I'm thinking about
>     adding a gdb/djgpp subdirectory with a special script that DJGPP
>     users will need to run (and which in turn will run the top-level
>     configure), and maybe a few small Sed scripts to fix file-name
>     related problems on 8+3 filesystems.  Is this acceptable?
> 
>   - What is the policy for fixing problems in the directories taken
>     from Binutils?  I'd imagine you want me to send patches to
>     Binutils maintainers, but with the next Binutils release nowhere
>     in sight, and some of my patches to Binutils in the queue since
>     August, is this really practical?  How can I make sure these
>     problems are fixed in GDB before GDB 5.0 is released?
>