Mail Archives: djgpp/2001/11/05/18:50:13
> Of what importance is it to the user that one has, for instance,
> ports of BNU 2.7 and GCC 3.x both billed as "ports to DJGPP v2.x",
> when those tools can't be used together?
Funny, I just removed binutils 2.7 from simtel this morning, because
it's not compatible with gcc 3.
> If one buys a commercial compiler, one expects all the tools in a
> given release to be compatible with each other.
With djgpp, that is supposed to hold if you're using the latest
official versions. DJGPP often keeps older versions around in case
someone has a need for them.
> Unfortunately, not all the tools in DJGPP v2.x work together, so
> I'm questioning why they are all billed as "v2.x". Does a new
> version number of DJGPP need to wait for lots of new features in the
> DJGPP-specific code, or does it make sense to increment the version
> number simply on grounds of incompatibility of core components?
DJGPP 2.x indicates that all the programs use the same API for
communicating with each other (long command lines, etc), are built
with the same basic tools (COFF, stub, etc) and use DJGPP's version 2
runtime. Basically, they'll interoperate nicely, even when there are
unmet version dependencies (i.e. gcc can still pass a long command
line to binutils, even though it's the wrong binutils).
The major version number of djgpp itself will be incremented when it's
no longer backwards compatible with the 2.x runtime or if the
development tools are not interoperable with 2.x tools. For example,
if we switched to ELF or PE formats. Or if we decide to rewrite it
from scratch again, as we did for 2.0. The version number of DJGPP
will never change just because of the packages ported to it.
Otherwise, we'd be changing the version number every week.
- Raw text -