collect2 no PATH override
hebisch at math.uni.wroc.pl
Mon Sep 3 23:57:21 CEST 2012
Jay Michael wrote:
> I think "collect2" should honor all of the "where to find compiler components" switches fed to GPC.
> I think it would be helpful if GPC defaulted to acting as if it were run with "-B <directory containing gpc>" (unless the user provides a "-B" switch).
> The "collect2" in the binary distribution of gpc-2007-09-04 for Windows doesn't seem to make any effort to locate the "ld" it runs -- if there is no "ld" in the PATH, it prints
> ld-orig: No such file or directory
> I have been running GPC without putting GPC\bin in my PATH. It has been working. Then I discovered that when I installed Free Pascal, it took the liberty of updating my system-wide PATH. When I removed it from my PATH, running GPC\bin\gpc resulted in
> gpc: installation problem, cannot exec `as': No such file or directory
> Adding "-B GPC\bin" solves that, but has no effect on "collect2" finding "ld".
What I wirte below is probably not very helpful for your
actual problem, but hopefully will explain at least some
reasons why things are done as they are done.
First using gpc on Windows you actually use several _independent_
software procject. Namely, gpc is build on top of gcc. In
turn gcc use 'as' and 'ld' which are part of binutils. And
there is 'mingw' project which is doing extra work needed
to make it work on Windows.
Concerning search for 'as', 'collect2' and 'ld': this is done
by gcc and gpc policy is to avoid changes to other compilers
in gcc. More precisely, to compile and link Pascal programs
normally you use 'gpc' command. But if you know what you
are doing you can use 'gcc' command (and probably even 'g++').
So is it desirable (maybe even required) that they find the
same 'as', 'collect2' and 'ld'. For "political" reasons
we can not change where 'gcc' command finds 'as', 'collect2'
and 'ld' (people who use both Pascal and C would be very
unhappy if installing Pascal compiler changed way in which
C compiler compiles C programs). So practially in 'gpc'
we must do the same what 'gcc' is doing (and this literally
is the same because we copy relevant code from gcc sources).
On Windows and Linux 'as' and 'ld' come from binutils. Other
systems frequently come with their own 'as' and 'ld'. I am
not sure about Windows, but on other systems normally
'as' and 'ld' are installed independently from gcc and gpc,
in separate place. When building gpc from sources you
can tell gpc (and gcc) where to find 'as' and 'ld'. Also
gpc (and gcc) can use so called 'spec' file -- using it
you can change where 'as' and 'ld' are found.
Concerning 'collect2': AFAIK 'collect2' contained in gcc
reacts on command line switches passed to gcc as appriopriate
(so if it does not react to a switch, then somebody thought that
for some reason this switch does not apply to 'collect2').
IIUC Windows 'collect2' is modified (entirely different?) program...
Coming back to assuming some value of '-B' argument. gpc _almost_
behaves in this way. I assure you that gcc folks (who implemented
this behaviour) deliberatly made differences -- you can try
to convince them that what you propose is better, but do
not think you will succeed.
OTOH in your own copy you can easily get such behaviour: just
rename gpc.exe to something like 'gpc-orig.exe' and create
a little command file named gpc which invokes 'gpc-orig.exe'
adding extra '-B' argument.
And AFAICS your real goal is to fix your gpc installation,
the simplest way is to restore it to original state (which
probably means putting \GPC\bin into PATH). But if you
like tweaking you may try creating spec file with full
path to 'as' and 'ld' (this may fail for modified 'collect2').
Or you may try command file which puts \GPC\bin' into PATH
just for execution of gpc command.
hebisch at math.uni.wroc.pl
More information about the Gpc