Date:	Mon, 7 Nov 94 02:45:30 JST
From:	Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
To:	DJGPP AT Sun DOT SOE DOT Clarkson DOT edu, (DJGPP, mailing, list)
Subject:	GCC search paths

This is pretty clearly a GCC, not a DJGPP problem.  If you're in a bad
mood, go ahead and flame away!

But if you're in a generous mood, consider (1) that my news-feed makes
round trips in about 8 days, and (2) mail to gcc-bug AT prep DOT ai DOT mit DOT edu
takes longer than that.  I'll send them mail tomorrow.

In order to fix a problem with compiling Ghostscript under DJGPP 1.12
and maint revs 1 and 2, I'd like to put a copy of an old ld (v 2.2) in
a directory by itself under the Ghostscript directory.

So, what I'd like to do is add something like this to the makefile:

# Some versions of DJGPP (in particular, v 1.12, 1.12.maint1, and
# 1.12.maint2) choke at the link stage.  This can be fixed by using an
# earlier version of the linker (provided with this distribution of
# Ghostscript).  Preferable, of course, would be a later version of
# the linker but it's not available yet :-(.  To do so uncomment the
# following line:
#
# COMPILER_PATH=./djgpp.bin

(This presumes the use of the 'set GO32=djgpp.env' technique, although
it apparently wouldn't make any difference---see the discussion of the
COMPILER_PATH variable, below.)  Now, when I did this with an
incorrect syntax (I actually did "make COMPILER_PATH=.\\djgpp.bin")
gcc complained about being unable to make sense of the path (I'm not
multitasked at the moment, so I can't replicate the exact error
message, sorry).  So apparently make does set the COMPILER_PATH
environment variable and send it to gcc correctly.
    When I do this correctly, however, even if I set it from DOS using
"set COMPILER_PATH=.\djgpp.bin", gcc does *not* find
./djgpp.bin/ld.exe, but rather /djgpp/bin/ld.exe.  According to the
docs for GCC (install.tex), GCC checks in the following places:

(1) it prepends GCC_EXEC_PREFIX to the subprogram, and if not found IT
LOOKS IN THE USUAL PLACES.
(2) it looks down the path specified by COMPILER_PATH.

Apparently "the usual places" means on the global PATH, and this takes
precedence over COMPILER_PATH.  Anybody know what's right?

TIA, 
    --Steve

P.S.  I'm aware of the potential copyleft issues in distributing
ld.exe with Ghostscript, Peter Deutsch & I will work them out before
doing such a thing.

- Raw text -