Mail Archives: djgpp-workers/1999/04/26/06:04:19
On 26 Apr 99, at 12:11, Eli Zaretskii wrote:
>
> On Mon, 26 Apr 1999, Andris Pavenis wrote:
>
> > I think where __DJGPP_MINOR__ is needed one should include stdio.h or
> > sys/version.h.
>
> Sorry, the more I think about this solution, the less I like it. It
> introduces a subtle dependence on the order in which headers are
> included. A naive user won't expect the order of inclusion to be
> important; an experienced user will have hard time to debug such
> problems, and will probably be infuriated to find out the reason.
>
> This solution is a maintainer's nightmare. For example, most GNU
> packages include config.h *before* any other header files (because
> config.h says #define HAVE_UNISTD_H etc.). Do I now need to revisit all
> the version-specific solutions that I devised over the years and try to
> figure out whether they might now break and whether I need to include
> stdio.h to solve that? sys/version.h is a non-solution for application
> code, since using it will break the port if it is compiled with versions
> before 2.02. (And yes, old versions are still supported; Emacs even
> supports v1.x to this day.)
>
> Since it depends on specific headers to be included, this solution is
> simply too fragile; when it does break, it will cause subtle bugs and
> mysterious behavior that will take a lot of effort to find and debug.
> If we will be lucky, during compilation some compiler error will pop up
> about some missing functionality; if we are less lucky, the code will
> mysteriously break at run time, because some fragment condintioned upon
> __DJGPP_MINOR__ didn't get compiled.
>
> Please, PLEASE let's not adopt this ``solution''!
Let's imagine that upcomming egcs-1.2 will need modified version of lib/specs
(I think it's very likely). Of course we can put it in gcc binary archive, but user
may run in problems if he upgrades libc after installing gcc. I'm afraid this will be
source of large number of problems and questions from novices we'll have to
answer. The previous libstdcxx.a related questions have became boring.
I don't know why, but currently C++ compiler in egcs snapshots "secretly"
without saying anything defaults to -fpedantic-errors unless -fpermissive
is specified. I can imagine number of questions from many users why
C++ comping fails when warnings are found. I don't know whether this "feature"
will be in egcs-1.2 release but it's in snapshots for at least 3 months now (I have
sent some related messages to egcs mailing list, but there are no results)
I understand that problems for developers also is not nice. But at least
developers can solve them (unfortunatelly it requires time). Also novice user
moustly does not write program that depends on libc version.
>
> When this issue was discussed about a year ago, I suggested an
> alternative solution. All we need is a transparent way for the compiler
> to add "-imacros %DJDIR%/include/sys/version.h" to the switches passed to
> the preprocessor. This is all it takes to make the version-specific
> symbols to be defined seamlessly and reliably. I could think about two
> ways of making this happen:
I see one serious problem with that:
I can have another version of DJGPP (lib and include directories only)
located somewhere else (eg. current CVS version with different version
number). We'll get wrong version number in such situation that potentially
can break things (against for developers as novices will not mess with related
things)
> 1) add DJGPP-specific code to gcc to do this (after all, it
> already expands %DJDIR%);
>
> 2) invent a new specs magic to expand an environment variable,
> and use that in the specs file to add -imacros to the cpp section.
>
> I think the second way is better, since it defines a general-purpose
> feature that we could use in the future for similar problems, and it might
> be more welcome by maintainers and users on other platforms. But even the
> first alternative is much, much better than to rely on stdio.h to be
> included.
>
> It is IMHO highly unfortunate that during all the time that passed since
> that discussion, nobody has done anything to solve this problem in the
> new ports of the compiler. I suggest that we do that now, instead of
> relying on header inclusion.
>
One more way here is to bind compiler binaries with each version of DJGPP
for example:
directory v203 could contain not only djdev203.zip, djlsr203.zip and related
files but also compiler binaries for that version (and the same about next
versions). Perhaps there is no need to move more there.
But I don't like all these suggested solutions. Forcing to get minor version
number from include files which is not included automatically perhaps will cause
some problems mostly for developers. But I still think that these are temporary
problems and we should go through them.
Andris
- Raw text -