Message-ID: From: "Andris Pavenis" To: Eli Zaretskii Date: Mon, 7 Dec 1998 13:27:00 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: djgpp 2.02 zips - please test CC: djgpp-workers AT delorie DOT com References: In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.01d) Reply-To: djgpp-workers AT delorie DOT com On 7 Dec 98, at 12:17, Eli Zaretskii wrote: > > 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. > I don't think it's possible to get 100% bulletproof version at all. So we must decide how far in that direction we want to go. Unfortunatelly we have used such way as definition of DJGPP_MINOR in specs. If one needs DJGPP_MINOR then he needs to include corresponding header file. For example also in Linux there is no tricks done to get libc version when no header files are included. > > 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. Unfortunatelly it is not fast solution and will be not backward compatible. However it may be good to have it in future. I also think similar tricks should be avoided if possible. > > > 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). Only way how to totally avoid any problems with something is not to touch it at all. I don't think we may have serious libc.a related compatibility problems that should force us to change specs (unless we'll change to ELF or doing some other similar changes) > > 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. Currently at least one Linux distribution (Slackware-3.5 and 3.6) comes with egcs-1.0.3 as default. egcs-1.1.1 also seems stable enough for normal use. > 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 think that if somebody is messing with files in $DJDIR/lib/gcc-lib/... without proper understanding he is playing with fire and can get burned. (similary as with DJGPP.ENV). But we are NOT able to make things 100% foolproff. > 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 ;-). As I said I'm going to modify default specs that comes with compiler only when needed. For example with egcs-1.1.1 one can even delete specs file and all will work (specs file is identical with builtin specs) Andris