Date: Mon, 26 Apr 1999 12:25:18 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Andris Pavenis cc: djgpp-workers AT delorie DOT com Subject: Re: v2.03: wrapping up In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.