Date:	Wed, 19 Jan 2000 16:35:08 +0200 (WET)
From:	Andris Pavenis <pavenis AT lanet DOT lv>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	djgpp AT delorie DOT com
Subject:	Re: make depend
In-Reply-To:	<Pine.SUN.3.91.1000119122713.9609i-100000@is>
Message-ID:	<Pine.A41.4.05.10001191549180.72182-100000@ieva01.lanet.lv>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 19 Jan 2000, Eli Zaretskii wrote:

> 
> On Wed, 19 Jan 2000 pavenis AT lanet DOT lv wrote:
> 
> > Of course it would be complicated for novices, but I think novices are likely
> > not to use definition of DJGPP_MINOR anyway.
> 
> Actually, they could use __DJGPP_MINOR__, if they read the FAQ ;-).
> 

But in this case FAQ should recommend not to define __DJGPP_MINOR__
in user code (even as default version if nothing is defined). 

Or one can put something like

#ifndef __DJGPP_MINOR__
#error __DJGPP_MINOR__ not defined. You should have at least DJGPP v2.02\
and include stdio.h up to this point
#endif

I think that changing library version some problems with existing 
software. I saw it very well when upgraded Linux from libc-5 to glibc-2.1
almost a year ago. 

For example if I run under Linux
	echo '' >foo.c
	gcc -v -c foo.c

I'm getting:

Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
 /usr/lib/gcc-lib/i386-slackware-linux/2.95.2/cpp -lang-c -v -D__GNUC__=2
-D__GNUC_MINOR__=95 -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__
-D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix)
-Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ foo.c
/tmp/ccGWBc6w.i
GNU CPP version 2.95.2 19991024 (release) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc-lib/i386-slackware-linux/2.95.2/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:
 /usr/lib/gcc-lib/i386-slackware-linux/2.95.2/../../../../include/g++-3

/usr/lib/gcc-lib/i386-slackware-linux/2.95.2/../../../../i386-slackware-linux/include
End of omitted list.
 /usr/lib/gcc-lib/i386-slackware-linux/2.95.2/cc1 /tmp/ccGWBc6w.i -quiet
-dumpbase foo.c -version -o /tmp/ccMJSbzV.s
GNU C version 2.95.2 19991024 (release) (i386-slackware-linux) compiled by
GNU C version 2.95.2 19991024 (release).
 /usr/i386-slackware-linux/bin/as -V -Qy -o foo.o /tmp/ccMJSbzV.s
GNU assembler version 2.9.1 (i386-slackware-linux), using BFD version
2.9.1.0.25

As You see there is no definitions of libc version I have. But differences
between for example libc-5.4.46 and glibc-2.1.2 are big. You can't even
tell from this which library version I have. 

macros __GLIBC__ and __GLIBC_MINOR__ are defined in
/usr/include/features.h  (at least in glibc-2.1.X)

It's of course hard to say whether none of system uses similar hacks
as we did for DJGPP, but I think it's unlikely. Perhaps similar tests
as I did can be repeated with different systems.

Our current hack we're using to get DJGPP_MINOR defined is incompatible
with DJGPP v2.00 and v2.01. If we'll avoid this hack and avoid 
defining this macro in user code, we should not get too serious problems.

I think currently such thing could be done by poeple releasing ports
of different packages for DJGPP to provide that we'll not break
additional things (simply by removing this hack from specs).
After some time we could drop this hack at all.

Andris

- Raw text -