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 printsld-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 ingpc: 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.