Mail Archives: djgpp-workers/1999/04/26/05:27:35
On Mon, 26 Apr 1999, Andris Pavenis wrote:
> Such change will break gcc-2.8.1. Are we really
> going to ask user to mess with specs file?
Are we going to decide that EGCS is now the main compiler? If so, let's
change lib/specs and never look back to 2.8.1. If not, then EGCS is an
experimental software that newbies should not touch; if they do, they are
expected to be able to edit a text file as per instructions.
> - let's look at different example. In Linux libc version is
> defined only in include file that is not included automatically.
> And there are no serious related problems
Linux is not a good example. Linux doesn't care about portability to
other platforms, because everybody else needs to be compatible with them.
Therefore, the only place where version-specific symbols are used in Linux
is inside the library itself, where it is very easy to require to include
that header. We do the same with libc/stubs.h, for example.
In contrast, the DJGPP version-specific symbols are used in the
application code. If we require inclusion of a header to get that,
people will need to revise all those applications to make sure it
will work for them. I submit that this is an antithesis of backward
compatibility.
> So I think that libc version (maybe minor version only) should be defined
> in HEADER FILES ONLY (not in specs).
It doesn't matter (IMHO) where it is defined. What we need is a way to
get it defined automatically, without any special action on the part of
the programmer. If we fail to do so, we will regret it very soon.
- Raw text -