Date: Mon, 7 Dec 1998 12:17:07 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Andris Pavenis cc: DJ Delorie , djgpp-workers AT delorie DOT com Subject: Re: djgpp 2.02 zips - please test In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com On Mon, 7 Dec 1998, Andris Pavenis wrote: > I found '#include ' 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, 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 ;-).