Mail Archives: djgpp/1998/11/01/07:03:03
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?
- Raw text -