Date: Wed, 19 Jan 2000 16:35:08 +0200 (WET) From: Andris Pavenis To: Eli Zaretskii cc: djgpp AT delorie DOT com Subject: Re: make depend In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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