Mail Archives: djgpp/1999/10/10/15:09:31
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 -