Re: 000217: status of DJGPP support

[Elena Zannoni <ezannoni at cygnus dot com>]

Eli Zaretskii writes:
 > 
 > 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?
 > 

Yes, I can see those too. I am not sure we can clean all of them before 
we go out with gdb 5 though, but it's up to Andrew.

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

select is used under cygwin, and it currently works for that. Just out
of curiosity, when did you last built for DJGPP? The event-loop.c file
has been like that for several months. (I am just trying to determine
if something else broke it). In any case, go ahead and submit a patch.

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

Not really, if you have a patch, send it along.

Thanks
Elena

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