000217: status of DJGPP support

[Eli Zaretskii <eliz at delorie dot com>]

I fetched the 000217 snapshot yesterday and tried to build it with
DJGPP.  I had only limited success: after some tweaking, everything
compiled, but linker complains about undefined references to several
functions.  In general, the DJGPP native support should be currently
considered broken in several ways; I'm working on repairing it.

Here are some specific comments/questions:

  - There are lots of warnings about comparison of signed with
    unsigned and unused arguments.  I find it hard to believe that
    this is specific to DJGPP: doesn't anyone else see these warnings?
    No doubt they are due to -Wall, but I understand we want to go
    into production with these switches, right?

  - There are also several conflicts between generic i386
    configuration headers and go32-specific ones.

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

    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?