On 9 Nov 01, at 12:20, J. David Bryan wrote:
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.
As far as I understand, this is the expected thing. IIRC "make pascal.bindist" is what creates the binary distribution, and it leaves out the C compilers from this process.
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.
As I said in another post, this will not resolve the problem with mismatched compiler versions.
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.
How would one do that without writing a special installation script for GPC? At the moment of building the binary distribution there is no way of knowing what type of configuration the binaries will be installed in (most probably an arbitrary and unpredictable mixture of text and binary mounts). People installing the precompiled binaries only have to untar a tarball.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) Author of: Chief's Installer Pro for Win32 http://www.bigfoot.com/~African_Chief/chief32.htm Email: African_Chief@bigfoot.com