Date: Sun, 1 Nov 1998 14:02:59 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Andris Pavenis cc: djgpp AT delorie DOT com, DJ Delorie Subject: Re: DJGPP 2.02 Beta 981027 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com On Thu, 29 Oct 1998, Andris Pavenis wrote: > Or even better NOT TO HAVE at least specs in %DJDIR%/lib. > This is way that is used in Linux and also other systems because specs > file normally changes together with gcc version The problem with this is that DJGPP's specs also defines important symbols for the preprocessor. The two that make the most problem are __DJGPP__ and __DJGPP_MINOR__. These *must* be consistent with the version of the installed DJGPP library, or all kinds of bad things will happen. The best way to solve this would be to arrange for cpp to read some file inside the include directory which will define these symbols. But I don't see any way to do that without knowing the exact path of $DJDIR: -imacros doesn't search the include path, and the syntax of specs doesn't support environment variables. Can anybody see a way to achieve this with a specs file that doesn't come with djdev? If there's no way to have this, we will need to change the source of cpp if we want to remove lib/specs from djdev. The best way to do that (IMHO) is to introduce a new feature into the syntax of the specs file that would allow to use values of environment variables, because such a change will probably be well-accepted by the GNU maintainers. If specs can refer to environment variables, then we can pass the `-imacros $DJDIR/include/sys/version.h' to cpp, include sys/version.h in djdev, and be done with it. I also think that we need to consider every entry in today's specs and djgpp.djl files for additional possible problems like this and consider solutions, lest we run into a possibility that we break some users' installation. For example: does anything in djgpp.djl depend on the version of Binutils or on djdev?