X-Authentication-Warning:	ieva01.lanet.lv: pavenis owned process doing -bs
Date:	Mon, 26 Apr 1999 10:28:58 +0300 (WET)
From:	Andris Pavenis <pavenis AT lanet DOT lv>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: v2.03: wrapping up
In-Reply-To:	<Pine.SUN.3.91.990425114027.9117O-100000@is>
Message-ID:	<Pine.A41.4.05.9904261012250.91294-100000@ieva01.lanet.lv>
MIME-Version:	1.0
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

On Sun, 25 Apr 1999, Eli Zaretskii wrote:

> 
> On Thu, 22 Apr 1999, Andris Pavenis wrote:
> 
> > specs file belongs to compiler. Therefore the place it should be is compiler
> > version specific directory instead of $DJDIR/lib
> 
> We have problems both ways.  The problem with way you suggest is that
> __DJGPP_MINOR__ isn't updated when a new version of djdev is released.
> I don't think we found a solution to this.
> 

gcc or egcs distribution doesn't have any info about libc version
of course. Perhaps we can only expect that major versions will not be
mixed. Therefore I didn't put definition of DJGPP_MINOR in specs and
also builtin specs for egcs-1.1.2 (it was only in specs file for
gcc-2.8.1 but not in builtin specs). I think only reasonable solution
is to force user to include corresponding include file to get library
version. I don't think specs is best place where to define it. I agree
that this can cause some problems now but they perhaps will not so
serious in future. But another way is going to cause problems in future.

It looks that when egcs-1.2 will be released (source release currently
scheduled to July AFAIK) modification of specs will be needed.
So some questions:
	- currently I have to add %{!fno-permissive:-fpermissive} to
	  CPLUSPLUS_SPECS to avoid having problems with C++. I average
	  12 April snapshot is working generaly Ok, no serious problems.
	  At least I have done some testing and tried to use it for my
          own work. Such change will break gcc-2.8.1. Are we really 
          going to ask user to mess with specs file? I don't think
    	  it's nice idea. But it will be needed if we'll leave specs
          in $DJDIR/lib

	- 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

So I think that libc version (maybe minor version only) should be defined
in HEADER FILES ONLY (not in specs). It could cause some problems now with
existing packages but I still think we should go through this or otherwise
we are going to have often problems in future when version of gcc or libc
will change.

Andris 	

- Raw text -