X-Authentication-Warning: ieva01.lanet.lv: pavenis owned process doing -bs Date: Mon, 26 Apr 1999 10:28:58 +0300 (WET) From: Andris Pavenis To: Eli Zaretskii 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 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