cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1999/10/10/15:09:31

Date: Sun, 10 Oct 1999 13:07:06 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Joel Hunsberger <jhunsberger AT i2k DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: gcc version control question
In-Reply-To: <37fddfdc.0@speedtrap.i2k.com>
Message-ID: <Pine.SUN.3.91.991010130636.19886D-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Fri, 8 Oct 1999, Joel Hunsberger wrote:

> 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.

Bad idea.  It is almost certain that the binaries belong to different
GCC versions, and mixing GCC versions will break your installation.
DO NOT DO THAT!

It is much better to keep the two installations apart, and prepare a
bunch of batch files to switch between the two configurations (by
changing setting of PATH and DJGPP environment variables).

On Windows, you can define two different shortcuts that open a DOS box
suitable for each one of the environments.

> 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 ??  :-))

The size doesn't mean anything.  For example, someone could compress
the executable.  The GNAT GDB probably includes some special support
for debugging Ada, but other than that, you'd be much better off
looking at the version (reported by GNU tools when invoked with the
"--version" option) than judging by size and timestamp.

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

This isn't even a DJGPP port, or so it seems!  It looks like a Mingw32
port.  You should NEVER mix the Mingw32 ports with DJGPP ports, it
will never work.

This also explains the size differences: Mingw32 executables use
Windows DLLs to run, so the library functions aren't linked into the
executable.

- Raw text -


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