delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/10/08/14:15:20

From: "Joel Hunsberger" <jhunsberger AT i2k DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: gcc version control question
Date: Fri, 8 Oct 1999 08:12:15 -0400
Lines: 66
X-Newsreader: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Message-ID: <37fddfdc.0@speedtrap.i2k.com>
NNTP-Posting-Host: speedtrap.i2k.com
X-Trace: 8 Oct 1999 08:13:22 +0400, speedtrap.i2k.com
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

I have had gcc 2.8.1 from the DJGPP collection installed for about 8
months...  and my configuration was set up as a standard installation, with
C:\DJGPP\BIN and C:\DJGPP\RSXNTDJ\BIN in the path.  All is well.

More recently, I obtained a CD of the GNAT Ada installation, supposedly
produced under the GNU license procedures... etc..  (I am not an expert in
all the GNU family heritage.)

After the GNAT installation, I ended up with C:\GNAT\BIN in my path also
(later in the path).

Now, here is the question...
I noticed that both the \DJGPP\BIN and the \GNAT\BIN had copies of  gcc.exe
and most of the other gcc supporting binaries.  Supposing them to all be
2.8.1 versions, I conceived the idea of creating ONE large master bin
(C:\GBIN) where all these various executables could reside without
multiplicity across my hard drive, and allowing me to greatly shorten my DOS
PATH.

On doing the merger, I found that many of the DJGPP binaries have a LARGER
SIZE, but an EARLIER DATE than most of the GNAT binaries.  In almost every
case, I opted to keep the DJGPP binary active in the path.  (I opted to let
the GNAT gdb.exe live in the path, because it is bigger ??  :-))

Here is some example data to illustrate this issue:

From the DJGPP version of gcc.exe:

GCC      EXE       130,560  10-22-98  4:31p gcc.exe

> gcc -v
Reading specs from C:/DJGPP/RSXNTDJ/lib/specs
gcc version 2.8.1

Now, from the GNAT distribution of gcc.exe:

GCC      EXE        52,736  01-21-99  5:37p gcc.exe

> gcc -v
Reading specs from C:\GNAT\lib\gcc-lib\pentium-mingw32msv\2.8.1\specs
gcc version 2.8.1


So, you see, they both claim to be version 2.8.1, yet (in a totally isolated
environment... gcc executed in a temp directory, with the path only pointing
to my new \GBIN) these executables, when run from the command line, SAY THEY
ARE THE SAME VERSION, but come up with specs from DIFFERENT paths.

I can see that these binaries have to be different, but I am at a loss as to
how to underrstand what GNU supporters mean when they say that (e.g.) gcc is
at version 2.8.1, yet two similarly named binaries obviously have different
contents.

Secondly, I see that to host both these environments (which I may not want
to do), I will have to keep the distributions in different directories, and
if I want to run DJGPP gcc, that will have to come first in the path, but if
I want to run the GNAT package (reliably ??) then GNAT will have to come
first in the path.

Does anyone have any suggestions, or observations on this point?

J. Hunsberger
jhunsberger AT i2k DOT com



- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019