Node:ELF vs COFF,
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
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 DJGPP42. GCC also needs to be
- 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
stubedit, need to be changed as well.
- The DJGPP debugger support (functions 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
- 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.