22.22 How about switching to ELF as DJGPP's object file format?

Q: I hear all that stuff about the limitations of the COFF format, and I don't understand why won't DJGPP switch to a modern standard such as ELF?

A: DJGPP uses COFF for historical reasons: at the time it was developed ELF was not available yet. There are several grave reasons why DJGPP didn't switch to ELF yet:

• Changing the binary format requires many changes to several packages that are central to DJGPP:
  • The Binutils should be configured for ELF, which requires that the parts of Binutils that deal with ELF be ported to DJGPP⁴². GCC also needs to be configured differently.
  • The DJGPP stub loader (stub.asm in the library sources) needs to be partially rewritten to be able to load an ELF executable and set it up for execution. Since the stub loader is written in assembly and optimized for size, this is a formidable task.
  • All stub-related programs, like go32-v2, stubify and stubedit, need to be changed as well.
  • The DJGPP debugger support (functions in the src/debug/ directory in the djlsr distribution) need to be changed to support ELF.
  • The ported GDB needs to be built with ELF support instead of COFF. Again, this means that the GDB ELF-specific code needs to be ported to DJGPP.
• Since ELF requires that external symbols have the same name in C and in object files, the DJGPP prepending of underscores to C object names needs to be abandoned. This means that any assembly code that refers to C symbols or calls C functions needs to be rewritten. In particular, this involves rewriting some C library functions and a significant portion of Allegro.
• Because of the above, switching to ELF will totally break back-compatibility with old libraries and object files.

None of the above is a show-stopper, so such a switch is possible. But it is a large project, and without several devoted volunteers, chances are it will never happen.