Date:	Mon, 7 Dec 1998 12:17:07 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Andris Pavenis <pavenis AT lanet DOT lv>
cc:	DJ Delorie <dj AT delorie DOT com>, djgpp-workers AT delorie DOT com
Subject:	Re: djgpp 2.02 zips - please test
In-Reply-To:	<B0000053940@stargate.astr.lu.lv>
Message-ID:	<Pine.SUN.3.91.981207120231.7807C-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com

On Mon, 7 Dec 1998, Andris Pavenis wrote:

> I found '#include <sys/version.h>' only in stdio.h and go32.h. I think
> sys/version.h is best way how to define minor version of DJGPP
> (and it should be no more done from specs).

Unfortunately, this cannot be done in a way that's 100% bulletproof.  For 
example, it is allowed for a program to not include any headers and 
still use library functions.  Also, <sys/version.h> didn't exist before 
v2.02, so you cannot use it directly in a program that needs to be 
backwards-compatible.

> However I think it would 
> be best to include from more standard header files (for example stdlib.h,
> stddef.h,...).

IMHO, the more the better.

I still think that a better solution would be to add support for 
environment variables to the syntax of specs, and then have cpp include 
sys/version.h via "-imacros $DJDIR/include/sys/version.h" activated from 
specs.

> specs file is thing that belongs to gcc distribution, therefore
> I think it should be distributed only there.

This is okay, but it means that you will have occasionally to replace
gccNNNb.zip just because some change in the library requires specs to be
changed.  Like the problem with crtf.o, for example (I understand that
Robert says it won't make any trouble, but other similar cases might not
let us get away that easily). 

> For egcs I'm modifying only those parts of specs I have to modify for
> DJGPP. Therefore of course specs file is different.

IMHO egcs is less of a problem, since it's an experimental compiler; 
people who install it are expected to tweak their installation a bit.

I'm much more worried about the mainline compiler installed by clueless 
newbies.

> There should be no problems if crtf.o will be linked (however it is 
> redundant with DJGPP-2.02)

What I fear is that somebody could delete crtf.o (hey, it's redundant, 
right? ;-) and then get linker errors when specs instructs it to look for 
that file.

I also think that the vast difference in the switches set up by two 
versions of specs is not very healthy, to say the least.  We don't need 
any more confusion (well, at least *I* don't need it ;-).

- Raw text -