On 9 Nov 2001, at 4:52, Frank Heckenbach wrote:
The problem with GPC_EXEC_PREFIX and GCC_EXEC_PREFIX is that only one directory can be given (even if both are set, the former takes precedence)....
I will investigate more thoroughly over the weekend, but as far as I can see, the "problem" is that GPC is being installed only with a partial set of tools (e.g., no C compiler) and is depending on a prior installation of GCC for the missing parts. This should not cause a problem, except that GPC attempts to locate, for example, the C compiler (cc1) in the same location as GPC was installed. This will not necessarily be correct in the case of separate installations of GCC and GPC. Nor should it be necessary to force these two to reside in the same location.
It would seem to me, therefore, that instead of GPC_EXEC_PREFIX and GCC_EXEC_PREFIX being mutually exclusive, GPC should first search using GPC_EXEC_PREFIX (to locate tools from the GPC installation, e.g., gpc1) and, if the needed tool is not found, then search the GCC_EXEC_PREFIX for tools from the GCC installation, e.g., cc1.
However, I just found that it also recognizes the variables COMPILER_PATH (for cpp and cc1) and LIBRARY_PATH (for libgcc.a), so if both are set to the GCC lib directory, it should work (I hope).
I believe it will, but doesn't this workaround simply fix the existing "improper" implementation of GCC/GPC_EXEC_PREFIX? (I put "improper" in quotes because there may be a good rationale for the existing method that I do not immediately see.)
I don't know if it's a real issue, but if it helps we could just ignore CRs in the specs file.
I believe the situation arises because Cygwin provides user-selected "text" and "binary" mounts for various parts of the emulated Unix directory hierarchy. The mount type defines how Cygwin should handle file reads and writes, i.e., whether files should contain CR-LF or only LF line ends; this is to accommodate file exchange with Windows programs.
The specific problem occurs when "specs" is built in a directory mounted in "text" mode (so the file is generated with CR-LF line ends) but then is copied during the GPC installation process to a directory mounted in "binary" mode. The CR-LF line ends remain in the file (because the file is an exact copy and is not translated when moving between mount types -- "bug" or "feature" is debatable :-), and GPC chokes when it encounters the CRs.
The problem should not occur if only binary mounts are used in Cygwin. Also, it could be solved during GPC installation by copying "specs" in such a way that the source and destination directory mount types are considered.
(If so, you might want to submit the same patch to the GCC developers for gcc.c ...)
I believe that it's only a problem for Cygwin, and then only a problem if the particular directories involved are mounted in different modes, but I'll investigate this a little more and report back later.
-- Dave