Message-ID:	<B0000084855@stargate.astr.lu.lv>
From:	"Andris Pavenis" <pavenis AT lanet DOT lv>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date:	Mon, 26 Apr 1999 13:28:43 +0300
MIME-Version:	1.0
Subject:	Re: v2.03: wrapping up
CC:	djgpp-workers AT delorie DOT com
References:	<Pine DOT A41 DOT 4 DOT 05 DOT 9904261012250 DOT 91294-100000 AT ieva01 DOT lanet DOT lv>
In-reply-to:	<Pine.SUN.3.91.990426121708.15084Z-100000@is>
X-mailer:	Pegasus Mail for Win32 (v3.02b14)
Reply-To:	djgpp-workers AT delorie DOT com

On 26 Apr 99, at 12:25, Eli Zaretskii wrote:

> 
> 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.

Sorry I thought development snapshot of egcs. Such change in specs I mentioned
perhaps would break all previous versions as there is no option -fpermissive
even in egcs-1.1.2

> > 	- 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.

I don't agree. I have met references to libc version for example in sources of 
DOSEMU-0.99.X and had to submit patch as there were glibc2 related bug and
glibc-2.1 I'm using were not supported at all

> 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.

Perhaps for some time only while we fix related problems. 

Andris

- Raw text -