Mail Archives: djgpp-workers/1999/04/27/06:38:12
On Tue, 27 Apr 1999, Andris Pavenis wrote:
> > That's what I suggested a year ago when this problem was discussed in
> > the context of GCC 2.8.x. I think using "-imacros" to include
> > sys/version.h will solve this cleanly and reliably.
>
> I don't think so. Imagine if somebody will want to test something with
> DJGPP-2.00 or 2.01 which didn't have sys/version.h.
I don't see how this will cause any trouble: gcc from those old versions
won't use the (yet unknown) way of passing -imacros to the preprocessor,
so cpp won't see -imacros. Those old versions will use lib/specs from
the old DJGPP distributions, which define __DJGPP__ and __DJGPP_MINOR__.
So I don't think old versions will have any problems with this.
> lib/specs). I haven't met any problems with it. Yesterday I tried to look
> at sources of emacs-19.34 and didn't find any problems when building it.
> Grepping sources also shows that all should be Ok.
I don't understand why do you say ``all should be Ok''. In the Emacs
19.34 distribution, the files src/msdos.c and src/dosfns.c check whether
__DJGPP_MINOR__ is 0 (for some bugs in v2.0). Current Emacs 20.3 sources
check for 2.02 or later (for some features missing in v2.01, like
sigprocmask).
This is not limited to Emacs, either. For example, the sources for dvilj
program (from the TeX/Web2c distribution) check for v2.02 or later, to
work around a problem in earlier stubs with inherited file handles; the
next version of Make will check for v2.02 as well, because we now have
sys_siglist[] and psignal.
And this is only off the top of my head. The problem is real, believe
me.
> I myself haven't seen any problems. Binaries of DJGPP port of egcs-1.1.2
> does not define DJGPP_MINOR in specs. Therefore it would be easy to test
> this with this version.
It is not easy at all to test this. How do you test whether anything is
broken in large and complex programs like Make or Emacs? Most probably,
you won't see any trouble until you create some very special situation;
and to do that, you need a thorough understanding what exactly do those
#ifdef's try to solve and under what conditions are these solutions
needed, and then analyze the source files and the headers they include to
see if maybe they include stdio.h at the right time.
Alternatively, you need to remember what were the problems which caused
that special code to be written, and how to recreate those problems. I
don't know how much time will it take me to recall the problems I solved
years ago.
Like I said: it's a maintainer's nightmare.
Is it really that hard to add a few lines to GCC so that it expands
%C_INCLUDE_PATH% and passes -imacros to cpp? Maybe we should do that
instead of arguing.
- Raw text -